Re: Debian mips: Failed test 'Check expected t_009_tbl data onstandby' - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Debian mips: Failed test 'Check expected t_009_tbl data onstandby'
Date
Msg-id 20181012002520.GB26424@paquier.xyz
Whole thread Raw
In response to Re: Debian mips: Failed test 'Check expected t_009_tbl data onstandby'  (Christoph Berg <myon@debian.org>)
Responses Re: Debian mips: Failed test 'Check expected t_009_tbl data onstandby'  (Christoph Berg <myon@debian.org>)
List pgsql-hackers
On Thu, Oct 11, 2018 at 09:49:27PM +0200, Christoph Berg wrote:
> Looking at src/test/recovery/t/009_twophase.pl, this is testing 2PC,
> and the missing row is from:
>
> $cur_master->psql(
>     'postgres', "
>     BEGIN;
>     INSERT INTO t_009_tbl VALUES (13, 'issued to ${cur_master_name}');
>     SAVEPOINT s1;
>     INSERT INTO t_009_tbl VALUES (14, 'issued to ${cur_master_name}');
>     PREPARE TRANSACTION 'xact_009_6';
>     COMMIT PREPARED 'xact_009_6';");
> $cur_master->teardown_node;
>
> So it is very strange that the "13" came through, but "14" did not.
> Doesn't look like a test that could be unstable, at least not in that
> way.

Do you still have the logs of the previous run for the standby?  I am
wondering if you could have seen this issue caused by duplicated XIDs
found in XLOG_RUNNING_XACTS:
https://www.postgresql.org/message-id/0c96b653-4696-d4b4-6b5d-78143175d113@postgrespro.ru
That's hard to reproduce, still that could be possible if a standby
snapshot was taken in parallel of this transaction running on the
primary.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: TAP tests for pg_verify_checksums
Next
From: Michael Paquier
Date:
Subject: Re: pgsql: Add TAP tests for pg_verify_checksums