Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.
| От | Craig Ringer |
|---|---|
| Тема | Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc. |
| Дата | |
| Msg-id | CAMsr+YERsJzCnO_SDAGWvTgYT5g4oQQTgGG4EKe+FrvwCEpnSA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc. (Michael Paquier <michael.paquier@gmail.com>) |
| Ответы |
Re: [REVIEW] In-core regression tests for replication,
cascading, archiving, PITR, etc.
|
| Список | 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.
В списке pgsql-hackers по дате отправления: