Re: Fairly serious bug induced by latest guc enum changes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Fairly serious bug induced by latest guc enum changes
Date: 2008-05-13 13:44:14
Message-ID: 24060.1210686254@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-05-13 13:50:29 Re: Fairly serious bug induced by latest guc enum changes
Previous Message Andrew Dunstan 2008-05-13 12:26:35 Re: odd output in restore mode