Re: 011_crash_recovery.pl intermittently fails

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:30:58
Message-ID: CA+hUKGK50B4soLLa=Vjt58m=GcYtTve7uSGbEEa6dj6GRExAFQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 5, 2021 at 5:10 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
> > I'd be kind of inclined to remove this test script altogether, on the
> > grounds that it's wasting cycles on a function that doesn't really
> > do what is claimed (and we should remove the documentation claim, too).
>
> 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-03-05 04:40:34 Re: 011_crash_recovery.pl intermittently fails
Previous Message Fujii Masao 2021-03-05 04:30:11 Re: [PATCH] pgbench: Bug fix for the -d option