Horton

Thread

Commits

  1. Fix relcache handling of the 'default' partition

  2. Fix CommandCounterIncrement in partition-related DDL

  1. pgsql: Fix CommandCounterIncrement in partition-related DDL

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2018-03-20T14:37:36Z

    Fix CommandCounterIncrement in partition-related DDL

It makes sense to do the CCIs in the places that do catalog updates,
rather than before the places that error out because the former ones
fail to do it.  In particular, it looks like StorePartitionBound() and
IndexSetParentIndex() ought to make their own CCIs.

Per review comments from Peter Eisentraut for row-level triggers on
partitioned tables.

Discussion: https://postgr.es/m/20171229225319.ajltgss2ojkfd3kp@alvherre.pgsql

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/4dba331cb3dc1b5ffb0680ed8efae847de216796

Modified Files
--------------
src/backend/catalog/heap.c       | 3 +++
src/backend/commands/indexcmds.c | 3 +++
src/backend/commands/tablecmds.c | 9 ---------
3 files changed, 6 insertions(+), 9 deletions(-)

  2. Re: pgsql: Fix CommandCounterIncrement in partition-related DDL

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2018-03-20T14:54:50Z

    Alvaro Herrera wrote:
> Fix CommandCounterIncrement in partition-related DDL

Hmm, Prion seems unhappy about this.  Looking

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

  3. Re: pgsql: Fix CommandCounterIncrement in partition-related DDL

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2018-03-20T18:26:59Z

    Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Fix CommandCounterIncrement in partition-related DDL
> 
> Hmm, Prion seems unhappy about this.  Looking

Here's a patch that seems to fix the problem, and generally looks sane
to me.

The previous arrangements to avoid CCI seem brittle: apparently we were
forced to do StorePartitionBounds() and immediately
update_default_partition_oid() without CCI in between, or various things
went nuts ("unexpected partdefid").  With this patch, what we do is we
call update_default_partition_oid *within* StorePartitionBounds without
an intervening CCI, which seems to achieve the same result -- namely
that when the relcache entry is rebuilt, it doesn't end up incomplete.

The two places that previously called update_default_partition_oid with
a non-zero default partition OID no longer call it, since they were
storing bounds.  The only places that remain outside of
StorePartitionBounds call it with InvalidOid (during relation drop, and
during partition detach).

I also remove a crock in RelationBuildPartitionDesc to return empty when
"key is null" (i.e. pg_class entry was there but not
pg_partitioned_table), which makes no sense -- except if you're building
the cache untimely, which apparently is what was happening.  If you make
sure the pg_partitioned_table entry is present before making the
pg_class entry visible, then this should not be necessary.

heap_drop_with_catalog contains a copy-paste failure, fixed also in this
patch.

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.

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

  4. Re: pgsql: Fix CommandCounterIncrement in partition-related DDL

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-03-20T18:37:46Z

    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

  5. Re: pgsql: Fix CommandCounterIncrement in partition-related DDL

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2018-03-20T18:55:29Z

    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

  6. Re: pgsql: Fix CommandCounterIncrement in partition-related DDL

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2018-03-21T15:07:57Z

    Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Alvaro Herrera wrote:
> > > Fix CommandCounterIncrement in partition-related DDL
> > 
> > Hmm, Prion seems unhappy about this.  Looking
> 
> Here's a patch that seems to fix the problem, and generally looks sane
> to me.

Pushed, after editing a couple of other comments here and there.

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