Re: fsync-pgdata-on-recovery tries to write to more files than previously
| От | Tom Lane |
|---|---|
| Тема | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
| Дата | |
| Msg-id | 5740.1432849036@sss.pgh.pa.us обсуждение |
| Ответ на | Re: fsync-pgdata-on-recovery tries to write to more files than previously (Abhijit Menon-Sen <ams@2ndQuadrant.com>) |
| Ответы |
Re: fsync-pgdata-on-recovery tries to write to more files
than previously
Re: fsync-pgdata-on-recovery tries to write to more files than previously |
| Список | pgsql-hackers |
Abhijit Menon-Sen <ams@2ndQuadrant.com> writes:
> Here's an updated patch for the fsync problem(s).
I've committed this after some mostly-cosmetic rearrangements.
> 4. As a partial aside, why does fsync_fname use OpenTransientFile? It
> looks like it should use BasicOpenFile as pre_sync_fname does. We
> close the fd immediately after calling fsync anyway. Or is there
> some reason I'm missing that we should use OpenTransientFile in
> pre_sync_fname too?
pre_sync_fname is the one that is wrong IMO. Using BasicOpenFile just
creates an opportunity for problems; that function should get called
from as few places as possible.
> 5. I made walktblspc_entries use stat() instead of lstat(), so that we
> can handle symlinks and directories the same way. Note that we won't
> continue to follow links inside the sub-directories because we use
> walkdir instead of recursing.
Given that, walktblspc_entries was 99% duplicate, so I folded it into
walkdir with a process_symlinks boolean.
I have to leave shortly, so I'll look at the initdb cleanup tomorrow.
regards, tom lane
В списке pgsql-hackers по дате отправления: