Re: fsync-pgdata-on-recovery tries to write to more files than previously
От | Abhijit Menon-Sen |
---|---|
Тема | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
Дата | |
Msg-id | 20150528030536.GA22230@toroid.org обсуждение исходный текст |
Ответ на | Re: fsync-pgdata-on-recovery tries to write to more files than previously (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
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 |
At 2015-05-27 20:22:18 -0400, tgl@sss.pgh.pa.us wrote: > > I doubt that that (not using AllocateDir) […] (Disregarding per your followup.) > What I think is a reasonable compromise is to treat AllocateDir > failure as nonfatal, but to continue using ReadDir etc which means > that any post-open failure in reading a successfully-opened directory > would be fatal. OK, that's halfway between the two patches I posted. Will do. > Meanwhile, it seems like you have copied a couple of very dubious > decisions in initdb's walktblspc_links(): […] > > Now, we don't really have to do anything about these things in order > to fix the immediate problem, but I wonder if we shouldn't try to > clean up initdb's behavior while we're at it. OK, I'll fix that in both. > Independently of that, I thought the plan was to complain about any > problems at LOG message level, not DEBUG1, and definitely not WARNING > (which is lower than LOG for this purpose). I'll change the level to LOG for fsync_fname_ext, but I think DEBUG1 is more appropriate for the pre_sync_fname run. Or do you think I should use LOG for that too? > And why would you use a different message level for pg_xlog/ than for > other files anyway? That was just a mistake, I forgot to change it after copying. Thanks for having a look. I'll post a revised patch shortly. -- Abhijit
В списке pgsql-hackers по дате отправления: