Skip site navigation (1) Skip section navigation (2)

Re: Fairly serious bug induced by latest guc enum changes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fairly serious bug induced by latest guc enum changes
Date: 2008-06-30 20:41:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2008-06-30 22:11:02
Subject: Re: odd output in restore mode
Previous:From: Simon RiggsDate: 2008-06-30 20:34:16
Subject: Re: [HACKERS] get_relation_stats_hook()

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group