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

Re: Standalone backends run StartupXLOG in an incorrect environment

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Standalone backends run StartupXLOG in an incorrect environment
Date: 2010-04-19 20:18:38
Message-ID: 5628.1271708318@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
BTW, just for the archives' sake: it took a good long time to develop a
reproducible test case for this.  It seems that 99% of the WAL replay
code does *not* depend on the missing state.  I was eventually able to
reproduce the case originally reported, namely a crash during
btree_xlog_cleanup; but to get that you need (a) WAL to end between a
btree page split and insertion of the new parent record, and (b) have
the resulting insertion need to obtain a new btree page, ie there's
another split or newroot forced then, and (c) not have any available
pages in the index's FSM, so that we have to LockRelationForExtension,
which is what crashes for lack of a PGPROC.

So that probably explains why we went so long without recognizing the
bug.

This again points up the fact that WAL recovery isn't as well tested
as one could wish.  Koichi-san's efforts to create a test with 100%
coverage of all types of WAL records are good, but that'd not have
helped us to find this.  We should think about ways to provide better
test coverage of end-of-WAL cleanup.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-04-19 20:30:21
Subject: Re: Thoughts on pg_hba.conf rejection
Previous:From: Simon RiggsDate: 2010-04-19 19:14:44
Subject: Re: Standalone backends run StartupXLOG in an incorrect environment

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