Re: pgsql: Fix CommandCounterIncrement in partition-related DDL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgsql: Fix CommandCounterIncrement in partition-related DDL
Date
Msg-id 21120.1521571066@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Fix CommandCounterIncrement in partition-related DDL  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: pgsql: Fix CommandCounterIncrement in partition-related DDL  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> I wonder about adding a syscache callback so that when an item in
> pg_partitioned_table is invalidated, the relcache entry for partrelid
> entry in pg_class is invalidated also.  I can't find any precedent for
> anything similar, though, and there doesn't seem to be any convenient
> place to do it, either.

In principle you could do it by adding logic to CacheInvalidateHeapTuple
in inval.c, similar to the existing logic for pg_class, pg_attribute
and pg_index entries.  Not sure it's worthwhile though.  That's very
ancient code; of late our practice has been to insist that the code
modifying other catalogs that feed into relcache entries should issue
a relcache inval explicitly.  If there's a reason why it's not convenient
to do that, then maybe making CacheInvalidateHeapTuple do it is a
good way.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pgsql: Fix CommandCounterIncrement in partition-related DDL
Next
From: Justin Pryzby
Date:
Subject: Re: [HACKERS] per-sesson errors after interrupting CLUSTERpg_attribute (not attrdef)