Re: problems with table corruption continued

Well, when my application starts, about 100 backend database connections
start up at the same time so this fits in with the circumstance you
describe.  However, I'm just using a standard ext2 filesystem on 2.2 linux
kernel.

It's good to know that this error should be harmless.

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Brian Hirt" <bhirt@mobygames.com>
Cc: "Postgres Hackers" <pgsql-hackers@postgresql.org>; "Brian A Hirt"
<bhirt@berkhirt.com>
Sent: Tuesday, December 18, 2001 12:32 PM
Subject: Re: [HACKERS] problems with table corruption continued


> "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 on the 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
>