Re: 011_crash_recovery.pl intermittently fails

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: 011_crash_recovery.pl intermittently fails
Date: 2021-03-05 04:40:34
Message-ID: 1439485.1614919234@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Fri, Mar 5, 2021 at 5:10 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Alternatively, maybe we can salvage the function's usefulness by making it
>> flush WAL before returning?

> To make pg_xact_status()'s result reliable, don't you need to make
> pg_current_xact_id() flush? In other words, isn't it at the point
> that you *observe* the transaction that you have to make sure that
> this transaction ID won't be reused after crash recovery. Before
> that, it's simultaneously allocated and unallocated, like the cat.

We need to be sure that the XID is written out to WAL before we
let the client see it, yeah. I've not looked to see exactly
where in the code would be the best place.

BTW, I tried simply removing the "allows_streaming" option from
the test, and it failed ten times out of ten tries for me.
So Andres is right that that makes it pretty reproducible in
a stock build.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2021-03-05 04:44:09 Re: n_mod_since_analyze isn't reset at table truncation
Previous Message Thomas Munro 2021-03-05 04:30:58 Re: 011_crash_recovery.pl intermittently fails