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 20210621122919.2qhu3pfugxxp3cji@alap3.anarazel.de
Whole thread Raw
In response to Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic  (Andres Freund <andres@anarazel.de>)
Responses Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
List pgsql-hackers
Hi,

On 2021-06-16 12:12:23 -0700, Andres Freund wrote:
> Could you share your testcase? I've been working on a series of patches
> to address this (I'll share in a bit), and I've run quite a few tests,
> and didn't hit any infinite loops.

Sorry for not yet doing that. Unfortunately I have an ongoing family
health issue (& associated travel) claiming time and energy :(.

I've pushed the minimal fix due to beta 2.

Beyond beta 2 I am thinking of the below to unify the horizon
determination:

static inline GlobalVisHorizonKind
GlobalVisHorizonKindForRel(Relation rel)
{
   if (!rel)
       return VISHORIZON_SHARED;

   /*
    * Other relkkinds currently don't contain xids, nor always the necessary
    * logical decoding markers.
    */
   Assert(rel->rd_rel->relkind == RELKIND_RELATION ||
          rel->rd_rel->relkind == RELKIND_MATVIEW ||
          rel->rd_rel->relkind == RELKIND_TOASTVALUE);

   if (rel->rd_rel->relisshared || RecoveryInProgress())
       return VISHORIZON_SHARED;
   else if (IsCatalogRelation(rel) ||
            RelationIsAccessibleInLogicalDecoding(rel))
       return VISHORIZON_CATALOG;
   else if (!RELATION_IS_LOCAL(rel))
       return VISHORIZON_DATA;
   else
       return VISHORIZON_TEMP;
}

That's then used in GetOldestNonRemovableTransactionId(),
GlobalVisTestFor(). Makes sense?

Regards,

Andres



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: Add index OID macro argument to DECLARE_INDEX
Next
From: Simon Riggs
Date:
Subject: Using indexUnchanged with nbtree