Re: problems with table corruption continued - Mailing list pgsql-hackers

From Tom Lane
Subject Re: problems with table corruption continued
Date
Msg-id 17894.1008703925@sss.pgh.pa.us
Whole thread Raw
In response to Re: problems with table corruption continued  ("Brian Hirt" <bhirt@mobygames.com>)
List pgsql-hackers
"Brian Hirt" <bhirt@mobygames.com> writes:
> Do you think this might also explain the following errors i was seeing?

> NOTICE:  Cannot rename init file
> /moby/pgsql/base/156130/pg_internal.init.19833 to
> /moby/pgsql/base/156130/pg_internal.init: No such file or directory

No, that error is not coming from anywhere near VACUUM; it's from
relcache startup (see write_irels in src/backend/utils/cache/relcache.c).
The rename source file has just been created in the very same routine,
so it's difficult to see how one would get a "No such file" failure from
rename().

It is possible that several backends create temp init files at the
same time and all try to rename their own temp files into place as
the pg_internal.init file.  However, that should work: the rename
man page says
    The rename() system call causes the source file to be renamed to    target.  If target exists, it is first removed.
Both source and    target must be of the same type (that is, either directories or    nondirectories), and must reside
onthe same file system.
 
    If target can be created or if it existed before the call, rename()    guarantees that an instance of target will
exist,even if the system    crashes in the midst of the operation.
 

so we should end up with the extra copies deleted and just one init file
remaining after the slowest backend renames its copy into place.

Do you by chance have your database directory mounted via NFS, or some
other strange filesystem where the normal semantics of concurrent rename
might not work quite right?

FWIW, I believe this condition is pretty harmless, but it would be nice
to understand exactly why you're seeing the message.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: Re: problems with table corruption continued
Next
From: Tom Lane
Date:
Subject: Re: problems with table corruption continued