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
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 |