Re: Failed Assert in pgstat_assoc_relation - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Failed Assert in pgstat_assoc_relation
Date
Msg-id 20221128210908.hyffmljjylj447nu@awork3.anarazel.de
Whole thread Raw
In response to Re: Failed Assert in pgstat_assoc_relation  (Andres Freund <andres@anarazel.de>)
Responses Re: Failed Assert in pgstat_assoc_relation
List pgsql-hackers
Hi,

On 2022-11-28 10:50:13 -0800, Andres Freund wrote:
> On 2022-11-28 13:37:16 -0500, Tom Lane wrote:
> > Uh-huh.  I've not bothered to trace this in detail, but presumably
> > what is happening is that the first CREATE RULE converts the table
> > to a view, and then the ROLLBACK undoes that so far as the catalogs
> > are concerned, but probably doesn't undo related pg_stats state
> > changes fully.  Then we're in a bad state that will cause problems.
> > (It still crashes if you replace the second CREATE RULE with
> > "select * from t".)
> 
> Yea. I haven't yet fully traced through this, but presumably relcache inval
> doesn't fix this because we don't want to loose pending stats after DDL.
> 
> Perhaps we need to add a rule about not swapping pgstat* in
> RelationClearRelation() when relkind changes?

Something like the attached. Still needs a bit of polish, e.g. adding the test
case from above.

I'm a bit uncomfortable adding a function call below
         * Perform swapping of the relcache entry contents.  Within this
         * process the old entry is momentarily invalid, so there *must* be no
         * possibility of CHECK_FOR_INTERRUPTS within this sequence. Do it in
         * all-in-line code for safety.
but it's not the first, see MemoryContextSetParent().


Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Infinite loop while acquiring new TOAST Oid
Next
From: Peter Geoghegan
Date:
Subject: Re: Add 64-bit XIDs into PostgreSQL 15