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

From Christoph Berg
Subject Re: Debian mips: Failed test 'Check expected t_009_tbl data onstandby'
Date
Msg-id 20181011194927.GA31931@msg.df7cb.de
Whole thread Raw
In response to Re: Debian mips: Failed test 'Check expected t_009_tbl data on standby'  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Debian mips: Failed test 'Check expected t_009_tbl data onstandby'  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Re: Tom Lane 2018-10-11 <28384.1539266025@sss.pgh.pa.us>
> Christoph Berg <myon@debian.org> writes:
> > The 11rc1 build was failing on Debian mips:
> > ...
> > The diff is that "14|issued to london" was expected, but "|" was
> > received.
> > The build succeeded when I retried it manually on a different box.
> 
> Was it repeatable on the original box?

I asked for a rebuild on the buildd network, which succeeded. It wasn't
the very same machine, though. The processor information says
"EdgeRouter Pro" both for the failing build and the manual build, the
3rd (good) build now is "Rhino Labs UTM8".

> My gut feeling is that this is probably a test-case instability
> (eg timing dependency) rather than an actual bug, but of course
> it's hard to be sure.

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.

Christoph


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Soon-to-be-broken regression test case
Next
From: Tom Lane
Date:
Subject: Re: Soon-to-be-broken regression test case