Re: problems with table corruption continued
От | Tom Lane |
---|---|
Тема | Re: problems with table corruption continued |
Дата | |
Msg-id | 17894.1008703925@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: problems with table corruption continued ("Brian Hirt" <bhirt@mobygames.com>) |
Список | 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 по дате отправления: