Re: pgsql: Fix CommandCounterIncrement in partition-related DDL
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2018-03-20T18:55:29Z
Lists: 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
Commits
-
Fix relcache handling of the 'default' partition
- 56163004b8b2 11.0 landed
-
Fix CommandCounterIncrement in partition-related DDL
- 4dba331cb3dc 11.0 cited