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 20221202044635.xmart6puax5bige5@awork3.anarazel.de
Whole thread Raw
In response to Re: Failed Assert in pgstat_assoc_relation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Failed Assert in pgstat_assoc_relation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2022-11-28 16:33:20 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > 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.
>
> Ugh.  I don't know what pgstat_unlink_relation does, but assuming
> that it can never throw an error seems like a pretty bad idea,

I don't think it'd be an issue - it just resets the pointer from a pgstat
entry to the relcache entry.

But you're right:

> Can't that part be done outside the critical section?

we can do that. See the attached.


Do we have any cases of relcache entries changing their relkind?

Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Failed Assert while pgstat_unlink_relation
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] Add native windows on arm64 support