Re: Debian mips: Failed test 'Check expected t_009_tbl data on standby'

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

In response to

Responses

Browse pgsql-hackers by date

  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