Horton

Re: Failed Assert in pgstat_assoc_relation

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: vignesh C <vignesh21@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-12-02T04:46:35Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. Prevent pgstats from getting confused when relkind of a relation changes

  2. Remove logic for converting a table to a view.