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

Hi,

On 2020-10-27 20:51:10 -0700, Andres Freund wrote:
> On 2020-10-15 01:37:35 -0700, Andres Freund wrote:
> > Attached is a *prototype* implemention of this concept, which clearly is
> > lacking some comment work (and is intentionally lacking some
> > re-indentation).
> > 
> > I described my thoughts about how to limit the horizons for temp tables in
> > https://www.postgresql.org/message-id/20201014203103.72oke6hqywcyhx7s%40alap3.anarazel.de
> 
> Attached is an updated version of this patch. Quite a bit of polish,
> added removal of the isTopLevel arguments added a7212be8b9e that are now
> unnecessary, and changed the initialization of the temp table horizons
> to be latestCompletedXid + 1 instead of just latestCompletedXid when no
> xid is assigned.
> 
> 
> > Besides comments this probably mainly needs a bit more tests around temp
> > table vacuuming. Should have at least an isolation test that verifies
> > that temp table rows can be a) vacuumed b) pruned away in the presence
> > of other sessions with xids.
> 
> I added an isolationtester test for this. It verifies that dead rows in
> temp tables get vacuumed and pruned despite concurrent sessions having
> older snapshots. It does so by forcing an IOS and checking the number of
> heap fetches reported by EXPLAIN. I also added a companion test for
> permanent relations, ensuring that such rows do not get removed.
> 
> 
> Any comments? Otherwise I'll push that patch tomorrow.

Just pushed this. Let's see what the BF says...

It's kinda cool how much more aggressive hot pruning / killtuples now is
for temp tables.

Greetings,

Andres Freund