Arrange to fsync the contents of lockfiles (both postmaster.pid and the

socket lockfile) when writing them.  The lack of an fsync here may well
explain two different reports we've seen of corrupted lockfile contents,
which doesn't particularly bother the running server but can prevent a
new server from starting if the old one crashes.  Per suggestion from
Alvaro.

Back-patch to all supported versions.

src/backend/utils/init/miscinit.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/utils/init/miscinit.c,v 1.137.4.3 2009/12/09 21:58:55 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/utils/init/miscinit.c,v 1.137.4.4 2010/08/16 17:33:22 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -787,6 +787,17 @@ CreateLockFile(const char *filename, bool amPostmaster,
 				(errcode_for_file_access(),
 			  errmsg("could not write lock file \"%s\": %m", filename)));
 	}
+	if (pg_fsync(fd))
+	{
+		int			save_errno = errno;
+
+		close(fd);
+		unlink(filename);
+		errno = save_errno;
+		ereport(FATAL,
+				(errcode_for_file_access(),
+			  errmsg("could not write lock file \"%s\": %m", filename)));
+	}
 	if (close(fd))
 	{
 		int			save_errno = errno;
@@ -950,6 +961,13 @@ RecordSharedMemoryInLockFile(unsigned long id1, unsigned long id2)
 		close(fd);
 		return;
 	}
+	if (pg_fsync(fd))
+	{
+		ereport(LOG,
+				(errcode_for_file_access(),
+				 errmsg("could not write to file \"%s\": %m",
+						directoryLockFile)));
+	}
 	if (close(fd))
 	{
 		ereport(LOG,