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.
This commit is contained in:
Tom Lane 2010-08-16 17:33:17 +00:00
parent 7ded6d69d5
commit e521b3e9b5
1 changed files with 24 additions and 3 deletions

View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/utils/init/miscinit.c,v 1.150.2.3 2009/12/09 21:58:43 tgl Exp $
* $PostgreSQL: pgsql/src/backend/utils/init/miscinit.c,v 1.150.2.4 2010/08/16 17:33:17 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -899,6 +899,9 @@ CreateLockFile(const char *filename, bool amPostmaster,
* admin) but has left orphan backends behind. Check for this by
* looking to see if there is an associated shmem segment that is
* still in use.
*
* Note: because postmaster.pid is written in two steps, we might not
* find the shmem ID values in it; we can't treat that as an error.
*/
if (isDDLock)
{
@ -963,7 +966,18 @@ CreateLockFile(const char *filename, bool amPostmaster,
(errcode_for_file_access(),
errmsg("could not write lock file \"%s\": %m", filename)));
}
if (close(fd))
if (pg_fsync(fd) != 0)
{
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) != 0)
{
int save_errno = errno;
@ -1124,7 +1138,14 @@ RecordSharedMemoryInLockFile(unsigned long id1, unsigned long id2)
close(fd);
return;
}
if (close(fd))
if (pg_fsync(fd) != 0)
{
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not write to file \"%s\": %m",
DIRECTORY_LOCK_FILE)));
}
if (close(fd) != 0)
{
ereport(LOG,
(errcode_for_file_access(),