Re: Fairly serious bug induced by latest guc enum changes

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:06:00
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> Tom Lane wrote:
>>> No, my point was that there are three possible states of sync_bit and
>>> your patch only accounted for transitions between two of 'em.
>> Did this every get addressed? I don't see a commit for it.
> I thought it got fixed here:
> 2008-05-14 10:02 mha
> * src/backend/access/transam/xlog.c: Remove the special variable
> for open_sync_bit used in O_SYNC and O_DSYNC modes, replacing it
> with a call to a function that derives it from the sync_method
> variable, now that it has distinct values for these two cases.
> This means that assign_xlog_sync_method() no longer changes any
> settings, thus fixing the bug introduced in the change to use a guc
> enum for wal_sync_method.
> 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? 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?


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-07-01 18:09:28 Re: [PATCHES] TRUNCATE TABLE with IDENTITY
Previous Message David E. Wheeler 2008-07-01 17:45:30 Re: Access to localized_str_tolower()