Re: Fairly serious bug induced by latest guc enum changes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fairly serious bug induced by latest guc enum changes
Дата
Msg-id 5030.1214858472@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fairly serious bug induced by latest guc enum changes  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Fairly serious bug induced by latest guc enum changes
Список pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> No, my point was that there are three possible states of sync_bit and
>> your patch only accounted for transitions between two of 'em.

> Did this every get addressed?  I don't see a commit for it.

I thought it got fixed here:

2008-05-14 10:02  mha
* src/backend/access/transam/xlog.c: Remove the special variablefor open_sync_bit used in O_SYNC and O_DSYNC modes,
replacingitwith a call to a function that derives it from the sync_methodvariable, now that it has distinct values for
thesetwo cases.This means that assign_xlog_sync_method() no longer changes anysettings, thus fixing the bug introduced
inthe change to use a gucenum for wal_sync_method.
 

Hmm ... or at least more or less fixed.  Seems like there's no provision
to close and reopen the file if enableFsync changes.  Not sure if that's
worth worrying about.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Fairly serious bug induced by latest guc enum changes
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: odd output in restore mode