Re: recovering from "found xmin ... from before relfrozenxid ..." - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: recovering from "found xmin ... from before relfrozenxid ..."
Date
Msg-id CAA4eK1LF8fVFHFdJiBm-FV8+Wza0Wha+jCahxsvnRDwZKmJugg@mail.gmail.com
Whole thread Raw
In response to Re: recovering from "found xmin ... from before relfrozenxid ..."  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: recovering from "found xmin ... from before relfrozenxid ..."  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Sep 19, 2020 at 4:03 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.com> writes:
> > Cool, thanks to both of you for looking. Committed.
>
> Hmph, according to whelk this is worse not better:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=whelk&dt=2020-09-18%2017%3A42%3A11
>
> I'm at a loss to understand what's going on there.
>

I think our assumption that changing the tests to have temp tables
will make them safe w.r.t concurrent activity doesn't seem to be
correct. We do set OldestXmin for temp tables aggressive enough that
it allows us to remove all dead tuples but the test case behavior lies
on whether we are able to prune the chain. AFAICS, we are using
different cut-offs in heap_page_prune when it is called via
lazy_scan_heap. So that seems to be causing both the failures.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: XversionUpgrade tests broken by postfix operator removal
Next
From: Justin Pryzby
Date:
Subject: Re: should INSERT SELECT use a BulkInsertState?