Bootstrap WAL to begin at segment logid=0 logseg=1 (000000010000000000000001)
rather than 0/0, so that we can safely use 0/0 as an invalid value. This is a
more future-proof fix for the corner-case bug in streaming replication that
was fixed yesterday. We had a similar corner-case bug with log/seg 0/0 back in
February as well. Avoiding 0/0 as a valid value should prevent bugs like that
in the future. Per Tom Lane's idea.

Back-patch to 9.0. Since this only affects bootstrapping, it makes no
difference to existing installations. We don't need to worry about the
bug in existing installations, because if you've managed to get past the
initial base backup already, you won't hit the bug in the future either.

Branch
------
master

Details
-------
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=8c843fff2d8db7889b81782ab4f3324cbda4ed2a

Modified Files
--------------
src/backend/access/transam/xlog.c   |   21 ++++++++++++---------
src/backend/replication/walsender.c |    2 +-
2 files changed, 13 insertions(+), 10 deletions(-)

On Tue, Nov 2, 2010 at 2:40 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)iki(dot)fi> wrote:
> Back-patch to 9.0. Since this only affects bootstrapping, it makes no
> difference to existing installations. We don't need to worry about the
> bug in existing installations, because if you've managed to get past the
> initial base backup already, you won't hit the bug in the future either.

I'm actually not nearly so sanguine about this not affecting existing
installations. It means, for example, that anyone who has written
monitoring scripts that watch the wal position will see behaviour
they're not familiar with.


-- 
greg

On 03.11.2010 11:34, Greg Stark wrote:
> On Tue, Nov 2, 2010 at 2:40 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)iki(dot)fi>  wrote:
>> Back-patch to 9.0. Since this only affects bootstrapping, it makes no
>> difference to existing installations. We don't need to worry about the
>> bug in existing installations, because if you've managed to get past the
>> initial base backup already, you won't hit the bug in the future either.
>
> I'm actually not nearly so sanguine about this not affecting existing
> installations. It means, for example, that anyone who has written
> monitoring scripts that watch the wal position will see behaviour
> they're not familiar with.

You mean, they will see an unfamiliar wal position right after initdb? I 
guess, but who runs monitoring scripts on a freshly initdb'd database 
before doing anything on it?

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> On 03.11.2010 11:34, Greg Stark wrote:
>> I'm actually not nearly so sanguine about this not affecting existing
>> installations. It means, for example, that anyone who has written
>> monitoring scripts that watch the wal position will see behaviour
>> they're not familiar with.

> You mean, they will see an unfamiliar wal position right after initdb? I 
> guess, but who runs monitoring scripts on a freshly initdb'd database 
> before doing anything on it?

The WAL position immediately after initdb is unspecified, and definitely
NOT 0/0, in any case.  From this perspective initdb will merely seem to
have emitted more WAL than it used to.

A possibly more realistic objection is that a slave freshly initdb'd
with 9.0.2 might have trouble syncing up with a master using 9.0.1,
if the master is so new it hasn't chewed a segment's worth of WAL yet.
Not sure if this is actually a problem.

			regards, tom lane