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: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fairly serious bug induced by latest guc enum changes
Date: 2008-07-01 18:51:21
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Tom Lane wrote:
>> 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.

> We didn't have that before either, did we?

No, so I think it's a pre-existing bug.

> We close it when the sync bit
> changes, but not just if we change say between fsync() and fdatasync().
> Is there any actual reason we'd want to close it?

The point is that if you turn the fsync GUC on or off while using a wal
sync mode that requires supplying an option flag to open(), then really
you ought to close the WAL file and re-open it with the new correct
option flags. The fact that we're not doing that implies that the
effects of a change in fsync might not fully take effect until the next
WAL segment is started. Whether this is worth fixing isn't real clear.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-07-01 18:56:02 Re: Location for pgstat.stat
Previous Message Magnus Hagander 2008-07-01 18:48:41 Location for pgstat.stat