Re: Fairly serious bug induced by latest guc enum changes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fairly serious bug induced by latest guc enum changes
Date
Msg-id 24060.1210686254@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fairly serious bug induced by latest guc enum changes  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Fairly serious bug induced by latest guc enum changes  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: odd output in restore mode
Next
From: Tom Lane
Date:
Subject: Re: Fairly serious bug induced by latest guc enum changes