Robert Haas wrote: > On Fri, Apr 23, 2010 at 4:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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?
I'll give it a shot. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
