Re: Fairly serious bug induced by latest guc enum changes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fairly serious bug induced by latest guc enum changes
Дата
Msg-id 24060.1210686254@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fairly serious bug induced by latest guc enum changes  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: Fairly serious bug induced by latest guc enum changes  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> Since it didn't really sound like a nice option, here's a third one I 
> came up with later. Basically, this one splits things apart so we only 
> use one variable, which is sync_method. Instead of using a macro to get 
> the open sync bit, it uses a function. This makes the assign hook only 
> responsible for flushing and closing the old file.

Okay, but you failed to correctly reproduce the conditions for closing
the old file.

> Thoughts? And if you like it, is it enough to expect the compiler to 
> figure out to inline it or should we explicitly inline it?

I don't think we care that much, since it's only invoked when we're
about to do a moderately expensive kernel call.
        regards, tom lane


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

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