Re: Fairly serious bug induced by latest guc enum changes
От | Bruce Momjian |
---|---|
Тема | Re: Fairly serious bug induced by latest guc enum changes |
Дата | |
Msg-id | 200806302029.m5UKTmk28172@momjian.us обсуждение исходный текст |
Ответ на | Re: Fairly serious bug induced by latest guc enum changes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Fairly serious bug induced by latest guc enum changes
|
Список | pgsql-hackers |
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > > Right, but I still need the other part of the check, right? This one > > still fails the same check as my patch, no? Because I assume the hole > > you found there was that get_sync_bit() will return 0 for two different > > sync methods as long as none of them are O_SYNC or O_DSYNC... > > No, my point was that there are three possible states of sync_bit and > your patch only accounted for transitions between two of 'em. For > instance, if sync_bit goes to 0 we must close and reopen the file, > else we'll be doing both O_SYNC flush and whatever flush method > is supposed to be getting used. Did this every get addressed? I don't see a commit for it. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: