Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Andres Freund <andres@2ndquadrant.com>

From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael.paquier@gmail.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2013-12-02T18:19:10Z
Lists: pgsql-hackers
On 2013-12-02 09:59:12 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > I think we also needs support for testing xid/multixid wraparound. It
> > currently isn't realistically testable because of the timeframes
> > involved.
> 
> When I've wanted to do that in the past, I've used pg_resetxlog to
> adjust a cluster's counters.

I've done that as well, but it's painful and not neccessarily testing
the right thing. E.g. I am far from sure we handle setting the
anti-wraparound limits correctly when promoting a standby - a restart to
adapt pg_control changes things and it might get rolled back because of
a already logged checkpoints.

What I'd love is a function that gives me the opportunity to
*efficiently* move forward pg_clog, pg_multixact/offset,members by large
chunks. So e.g. I could run a normal pgbench alongside another pgbench
moving clog forward in 500k chunks, but so it creates the necessary
files I could possibly need to access.

If you do it naivly you get into quite some fun with hot standby btw. I
can tell you that from experience :P

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Commits

  1. Add a test framework for recovery