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 по дате отправления: