Re: recovering from "found xmin ... from before relfrozenxid ..."

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, MBeena Emerson <mbeena(dot)emerson(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: recovering from "found xmin ... from before relfrozenxid ..."
Date: 2020-10-29 04:57:22
Message-ID: 20201029045722.6cj6pur377rngvn2@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-10-28 21:00:30 -0700, Andres Freund wrote:
> On 2020-10-28 19:09:14 -0700, Andres Freund wrote:
> > On 2020-10-28 18:13:44 -0700, Andres Freund wrote:
> > > Just pushed this. Let's see what the BF says...
> >
> > It says that apparently something is unstable about my new test. It
> > first passed on a few animals, but then failed a lot in a row. Looking.
>
> The differentiating factor is force_parallel_mode=regress.
>
> Ugh, this is nasty: The problem is that we can end up computing the
> horizons the first time before MyDatabaseId is even set. Which leads us
> to compute a too aggressive horizon for plain tables, because we skip
> over them, as MyDatabaseId still is InvalidOid:
>
> /*
> * Normally queries in other databases are ignored for anything but
> * the shared horizon. But in recovery we cannot compute an accurate
> * per-database horizon as all xids are managed via the
> * KnownAssignedXids machinery.
> */
> if (in_recovery ||
> proc->databaseId == MyDatabaseId ||
> proc->databaseId == 0) /* always include WalSender */
> h->data_oldest_nonremovable =
> TransactionIdOlder(h->data_oldest_nonremovable, xmin);
>
> That then subsequently leads us consider a row fully dead in
> heap_hot_search_buffers(). Triggering the killtuples logic. Causing the
> test to fail.
>
> With force_parallel_mode=regress we constantly start parallel workers,
> which makes it much more likely that this case is hit.
>
> It's trivial to fix luckily...

Pushed that fix, hopefully that calms the BF.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2020-10-29 05:13:57 Re: A new function to wait for the backend exit after termination
Previous Message vignesh C 2020-10-29 04:34:56 Re: Log message for GSS connection is missing once connection authorization is successful.