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