Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Date
Msg-id 20210609184506.rqm5rikoikm47csf@alap3.anarazel.de
Whole thread Raw
In response to Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
List pgsql-hackers
Hi,

Good find!

On 2021-06-09 17:42:34 +0200, Matthias van de Meent wrote:
> I believe that I've found the culprit:
> GetOldestNonRemovableTransactionId(rel) does not use the exact same
> conditions for returning OldestXmin as GlobalVisTestFor(rel) does.
> This results in different minimal XIDs, and subsequently this failure.

Specifically, the issue is that it uses the innocuous looking

    else if (RelationIsAccessibleInLogicalDecoding(rel))
        return horizons.catalog_oldest_nonremovable;

but that's not sufficient, because

#define RelationIsAccessibleInLogicalDecoding(relation) \
    (XLogLogicalInfoActive() && \
     RelationNeedsWAL(relation) && \
     (IsCatalogRelation(relation) || RelationIsUsedAsCatalogTable(relation)))

it is never true if wal_level < logical. So what it is missing is the
IsCatalogRelation(rel) || bit.


> The attached patch fixes this inconsistency

I think I prefer applying the fix and the larger changes separately.


> Another approach might be changing GlobalVisTestFor(rel) instead to
> reflect the conditions in GetOldestNonRemovableTransactionId.

No, that'd not be correct, afaict.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: unnesting multirange data types
Next
From: Tom Lane
Date:
Subject: Re: Add PortalDrop in exec_execute_message