Re: Adding a TAP test checking data consistency on standby with minRecoveryPoint

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, Georgios Kokolatos <gkokolatos(at)pm(dot)me>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Adding a TAP test checking data consistency on standby with minRecoveryPoint
Date: 2019-04-16 06:45:12
Message-ID: 20190416064512.GJ2673@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 24, 2019 at 09:47:58PM +0900, Michael Paquier wrote:
> The failure is a bit weird, as I would expect all those three actions
> to be sequential. piculet is the only failure happening on the
> buildfarm and it uses --disable-atomics, so I am wondering if that is
> related and if 0dfe3d0 is part of that. With a primary/standby set,
> it could be possible to test that scenario pretty easily. I'll give
> it a shot.

The buildfarm has just failed with a similar failure, for another
test aka 009_twophase.pl:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dragonet&dt=2019-04-16%2006%3A14%3A01

I think that we have race conditions with checkpointing and shutdown
on HEAD.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2019-04-16 06:47:27 Re: Commit message / hash in commitfest page.
Previous Message Michael Paquier 2019-04-16 06:19:00 Re: REINDEX CONCURRENTLY 2.0