Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers@postgresql.org, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Date: 2010-04-26T13:19:58Z
Lists: pgsql-hackers
On Fri, Apr 23, 2010 at 4:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: >> No intention of doing that. This change allows people to see what the >> dependency actually is once the bug has been fixed. Change needs to >> start from here, not from where we were before. > > Well, actually, now that I've looked at the patch I think it's starting > from a fundamentally wrong position anyway. Checkpoint records are a > completely wrong mechanism for transmitting this data to slaves, because > a checkpoint is emitted *after* we do something, not *before* we do it. > In particular it's ludicrous to be looking at shutdown checkpoints to > try to determine whether the subsequent WAL will meet the slave's > requirements. There's no connection at all between what the GUC state > was at shutdown and what it might be after starting again. > > A design that might work is > (1) store the active value of wal_mode in pg_control (but NOT as part of > the last-checkpoint-record image). > (2) invent a new WAL record type that is transmitted when we change > wal_mode. > > Then, slaves could check whether the master's wal_mode is high enough > by looking at pg_control when they start plus any wal_mode_change > records they come across. > > If we did this then we could get rid of those WAL record types that were > added to signify that information had been omitted from WAL at specific > times. <dons project manager hat> I notice that Heikki's patch doesn't include doing the above. Should we? If so, who's going to do it? ...Robert