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

From Alvaro Herrera
Subject Re: pgsql: Fix CommandCounterIncrement in partition-related DDL
Date
Msg-id 20180320185529.sf3wym5gdfnczd4m@alvherre.pgsql
Whole thread Raw
In response to Re: pgsql: Fix CommandCounterIncrement in partition-related DDL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> 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.

Actually, the current code uses CacheInvalidateRelcache() already and it
seems to work; I was looking for a better way that did not require us to
remember it for every update in that catalog, but it seems there isn't
one.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: configure's checks for --enable-tap-tests are insufficient
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] plpgsql - additional extra checks