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

Re: [HACKERS] Re: pgsql: Make CheckRequiredParameterValues() depend upon correct

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-committers(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: pgsql: Make CheckRequiredParameterValues() depend upon correct
Date: 2010-04-23 20:44:41
Message-ID: 16333.1272055481@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Simon Riggs <simon(at)2ndQuadrant(dot)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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2010-04-23 20:50:29
Subject: Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Previous:From: Simon RiggsDate: 2010-04-23 20:31:50
Subject: Re: recovery_connections cannot start (was Re: master in standby mode croaks)

pgsql-committers by date

Next:From: Robert HaasDate: 2010-04-23 21:27:21
Subject: Re: [HACKERS] Re: pgsql: Make CheckRequiredParameterValues() depend upon correct
Previous:From: Simon RiggsDate: 2010-04-23 20:22:00
Subject: Re: pgsql: Make CheckRequiredParameterValues() depend upon correct

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