From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Debian mips: Failed test 'Check expected t_009_tbl data on standby' |
Date: | 2018-10-12 00:25:20 |
Message-ID: | 20181012002520.GB26424@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-10-12 00:56:14 | Re: pgsql: Add TAP tests for pg_verify_checksums |
Previous Message | Michael Paquier | 2018-10-12 00:21:39 | Re: TAP tests for pg_verify_checksums |