pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: pointless check in RelationBuildPartitionDesc
Date: Mon, 3 Sep 2018 18:39:16 -0300
Message-ID: <20180903213916.hh6wasnrdg6xv2ud@alvherre.pgsql> (raw)

I noticed this strange hack in RelationBuildPartitionDesc:

       /*
        * It is possible that the pg_class tuple of a partition has not been
        * updated yet to set its relpartbound field.  The only case where
        * this happens is when we open the parent relation to check using its
        * partition descriptor that a new partition's bound does not overlap
        * some existing partition.
        */
       if (!((Form_pg_class) GETSTRUCT(tuple))->relispartition)
       {
           ReleaseSysCache(tuple);
           continue;
       }

After looking, it seems that this is just self-inflicted pain: for some
reason, we store the pg_inherits row for a partition, and immediately
afterwards compute and store its partition bound, which requires the
above hack.  But if we do things in the opposite order, this is no
longer needed.  I propose to remove it, as in the attached patch.

-- 
Álvaro Herrera                         Developer, https://www.PostgreSQL.org/

Attachments:

ispartition.patch (text/plain, 1.8K) download diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c index f46af41b56..089e9f1b20 100644 --- a/src/backend/commands/tablecmds.c +++ b/src/backend/commands/tablecmds.c @@ -773,9 +773,6 @@ DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId, InvalidOid, typaddress); - /* Store inheritance information for new rel. */ - StoreCatalogInheritance(relationId, inheritOids, stmt->partbound != NULL); - /* * We must bump the command counter to make the newly-created relation * tuple visible for opening. @@ -869,6 +866,9 @@ DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId, heap_close(parent, NoLock); } + /* Store inheritance information for new rel. */ + StoreCatalogInheritance(relationId, inheritOids, stmt->partbound != NULL); + /* * Process the partitioning specification (if any) and store the partition * key information into the catalog. diff --git a/src/backend/utils/cache/partcache.c b/src/backend/utils/cache/partcache.c index 115a9fe78f..e3cd65b33a 100644 --- a/src/backend/utils/cache/partcache.c +++ b/src/backend/utils/cache/partcache.c @@ -302,19 +302,6 @@ RelationBuildPartitionDesc(Relation rel) if (!HeapTupleIsValid(tuple)) elog(ERROR, "cache lookup failed for relation %u", inhrelid); - /* - * It is possible that the pg_class tuple of a partition has not been - * updated yet to set its relpartbound field. The only case where - * this happens is when we open the parent relation to check using its - * partition descriptor that a new partition's bound does not overlap - * some existing partition. - */ - if (!((Form_pg_class) GETSTRUCT(tuple))->relispartition) - { - ReleaseSysCache(tuple); - continue; - } - datum = SysCacheGetAttr(RELOID, tuple, Anum_pg_class_relpartbound, &isnull);

view thread (11+ messages)  latest in thread

Message-ID: <20180903213916.hh6wasnrdg6xv2ud@alvherre.pgsql>
Permalink:  ../20180903213916.hh6wasnrdg6xv2ud@alvherre.pgsql/
Also on:    postgresql.org/message-id/20180903213916.hh6wasnrdg6xv2ud@alvherre.pgsql

 ·  · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: alvherre@alvh.no-ip.org
  Subject: Re: pointless check in RelationBuildPartitionDesc
  In-Reply-To: <20180903213916.hh6wasnrdg6xv2ud@alvherre.pgsql>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox