Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Дата
Msg-id 20210609184506.rqm5rikoikm47csf@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Ответы Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic  (Peter Geoghegan <pg@bowt.ie>)
Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Jonathan S. Katz"
Дата:
Сообщение: unnesting multirange data types
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Add PortalDrop in exec_execute_message