Remove useless whitespace at end of lines

5 files changed, 6 insertions, 6 deletions

diff --git a/src/backend/storage/buffer/README b/src/backend/storage/buffer/README
index 3b46094623..38e67c1c90 100644
--- a/src/backend/storage/buffer/README
+++ b/src/backend/storage/buffer/README
@@ -264,7 +264,7 @@ while scanning the buffers.  (This is a very substantial improvement in
 the contention cost of the writer compared to PG 8.0.)
 
 During a checkpoint, the writer's strategy must be to write every dirty
-buffer (pinned or not!).  We may as well make it start this scan from 
+buffer (pinned or not!).  We may as well make it start this scan from
 NextVictimBuffer, however, so that the first-to-be-written pages are the
 ones that backends might otherwise have to write for themselves soon.
 
diff --git a/src/backend/storage/freespace/README b/src/backend/storage/freespace/README
index b3b0e3a680..d591cbb585 100644
--- a/src/backend/storage/freespace/README
+++ b/src/backend/storage/freespace/README
@@ -84,7 +84,7 @@ backends are concurrently inserting into a relation, contention can be avoided
 by having them insert into different pages.  But it is also desirable to fill
 up pages in sequential order, to get the benefit of OS prefetching and batched
 writes.  The FSM is responsible for making that happen, and the next slot
-pointer helps provide the desired behavior. 
+pointer helps provide the desired behavior.
 
 Higher-level structure
 ----------------------
diff --git a/src/backend/storage/ipc/README b/src/backend/storage/ipc/README
index a56729db1a..913a4dab2b 100644
--- a/src/backend/storage/ipc/README
+++ b/src/backend/storage/ipc/README
@@ -7,7 +7,7 @@ Mon Jul 18 11:09:22 PDT 1988  W.KLAS
 
 The cache synchronization is done using a message queue. Every
 backend can register a message which then has to be read by
-all backends. A message read by all backends is removed from the 
+all backends. A message read by all backends is removed from the
 queue automatically. If a message has been lost because the buffer
 was full, all backends that haven't read this message will be
 told that they have to reset their cache state. This is done
diff --git a/src/backend/storage/lmgr/Makefile b/src/backend/storage/lmgr/Makefile
index b0bfe66fe6..9aa9a5c086 100644
--- a/src/backend/storage/lmgr/Makefile
+++ b/src/backend/storage/lmgr/Makefile
@@ -27,5 +27,5 @@ s_lock_test: s_lock.c $(top_builddir)/src/port/libpgport.a
 check: s_lock_test
 	./s_lock_test
 
-clean distclean maintainer-clean: 
+clean distclean maintainer-clean:
 	rm -f s_lock_test
diff --git a/src/backend/storage/lmgr/README b/src/backend/storage/lmgr/README
index 0358594bad..87cae18cb6 100644
--- a/src/backend/storage/lmgr/README
+++ b/src/backend/storage/lmgr/README
@@ -31,7 +31,7 @@ arrival order.  There is no timeout.
 
 * Regular locks (a/k/a heavyweight locks).  The regular lock manager
 supports a variety of lock modes with table-driven semantics, and it has
-full deadlock detection and automatic release at transaction end. 
+full deadlock detection and automatic release at transaction end.
 Regular locks should be used for all user-driven lock requests.
 
 Acquisition of either a spinlock or a lightweight lock causes query
@@ -260,7 +260,7 @@ A key design consideration is that we want to make routine operations
 (lock grant and release) run quickly when there is no deadlock, and
 avoid the overhead of deadlock handling as much as possible.  We do this
 using an "optimistic waiting" approach: if a process cannot acquire the
-lock it wants immediately, it goes to sleep without any deadlock check. 
+lock it wants immediately, it goes to sleep without any deadlock check.
 But it also sets a delay timer, with a delay of DeadlockTimeout
 milliseconds (typically set to one second).  If the delay expires before
 the process is granted the lock it wants, it runs the deadlock