Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc. - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.
Date
Msg-id CAMsr+YERsJzCnO_SDAGWvTgYT5g4oQQTgGG4EKe+FrvwCEpnSA@mail.gmail.com
Whole thread Raw
In response to Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.
List pgsql-hackers
On 26 February 2016 at 13:43, Michael Paquier <michael.paquier@gmail.com> wrote:
 
> my $caughtup_query = "SELECT '$current_lsn'::pg_lsn <=
> pg_last_xlog_replay_location()";
> use
> my $caughtup_query = "SELECT pg_xlog_location_diff('$current_lsn',
> pg_last_xlog_replay_location()) <= 0";
> so it doesn't care if we replay past the expected LSN on the master due to
> autovacuum activity. That's what's done in the real world and what should be
> covered by the tests IMO.

Those two statements have the same meaning. pg_xlog_location_diff does
exactly the same thing as the pg_lsn data type in terms of LSN
comparisons.

Ah. Whoops. I meant to write '=' in the first, to reflect what the code does.

You're quite right that casting to pg_lsn has the same effect and looks cleaner.

I think this looks good as of the last version. I'm not keen on disabling autovacuum but that can be addressed in a followup that makes it easier to configure params, as discussed. I definitely don't want to complicate this patch with it.

Should be committed ASAP IMO.

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

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH v5] GSSAPI encryption support
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: PATCH: index-only scans with partial indexes