Re: PostGreSQL (7.3?) recovery, Mac OS X (10.3.8)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: "Eric D(dot) Nielsen" <nielsene(at)mit(dot)edu>, pgsql-general(at)postgresql(dot)org
Subject: Re: PostGreSQL (7.3?) recovery, Mac OS X (10.3.8)
Date: 2005-04-13 02:36:26
Message-ID: 2197.1113359786@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> What version is this exactly? IIRC there was a version of 7.3 that
> would refuse to start if the last XLog record fell at the edge of a
> segment. I may be misremembering though (i.e. maybe it was one of the
> 7.4 series), plus I can't find the relevant entry in the release notes.

If I'm reading the CVS history correctly, the bug existed only in the
7.3.3 release; here's the CVS log entry for the fix:

2003-07-17 12:45 tgl

* src/backend/access/transam/xlog.c (REL7_3_STABLE): Repair
boundary-case bug introduced by patch of two months ago that fixed
incorrect initial setting of StartUpID. The logic in XLogWrite()
expects that Write->curridx is advanced to the next page as soon as
LogwrtResult points to the end of the current page, but
StartupXLOG() failed to make that happen when the old WAL ended
exactly on a page boundary. Per trouble report from Hannu Krosing.

and this seems to be what Bruce boiled it down to in the 7.3.4 release
notes:

* Prevent rare possibility of server startup failure (Tom)

Personally I always look at the CVS history when searching for bug
histories. cvs2cl.pl is a wonderful tool ...

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jinane Haddad 2005-04-13 05:21:30 Re: What are the consequences of a bad database design (never seen
Previous Message Tom Lane 2005-04-13 02:09:16 Re: PostGreSQL (7.3?) recovery, Mac OS X (10.3.8)