pgsql: Load relcache entries' partitioning data on-demand, not immediat - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Load relcache entries' partitioning data on-demand, not immediat
Date
Msg-id E1ikCbh-00018p-9I@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Load relcache entries' partitioning data on-demand, not immediately.

Formerly the rd_partkey and rd_partdesc data structures were always
populated immediately when a relcache entry was built or rebuilt.
This patch changes things so that they are populated only when they
are first requested.  (Hence, callers *must* now always use
RelationGetPartitionKey or RelationGetPartitionDesc; just fetching
the pointer directly is no longer acceptable.)

This seems to have some performance benefits, but the main reason to do
it is that it eliminates a recursive-reload failure that occurs if the
partkey or partdesc expressions contain any references to the relation's
rowtype (as discovered by Amit Langote).  In retrospect, since loading
these data structures might result in execution of nearly-arbitrary code
via eval_const_expressions, it was a dumb idea to require that to happen
during relcache entry rebuild.

Also, fix things so that old copies of a relcache partition descriptor
will be dropped when the cache entry's refcount goes to zero.  In the
previous coding it was possible for such copies to survive for the
lifetime of the session, as I'd complained of in a previous discussion.
(This management technique still isn't perfect, but it's better than
before.)  Improve the commentary explaining how that works and why
it's safe to hand out direct pointers to these relcache substructures.

In passing, improve RelationBuildPartitionDesc by using the same
memory-context-parent-swap approach used by RelationBuildPartitionKey,
thereby making it less dependent on strong assumptions about what
partition_bounds_copy does.  Avoid doing get_rel_relkind in the
critical section, too.

Patch by Amit Langote and Tom Lane; Robert Haas deserves some credit
for prior work in the area, too.  Although this is a pre-existing
problem, no back-patch: the patch seems too invasive to be safe to
back-patch, and the bug it fixes is a corner case that seems
relatively unlikely to cause problems in the field.

Discussion: https://postgr.es/m/CA+HiwqFUzjfj9HEsJtYWcr1SgQ_=iCAvQ=O2Sx6aQxoDu4OiHw@mail.gmail.com
Discussion: https://postgr.es/m/CA+TgmoY3bRmGB6-DUnoVy5fJoreiBJ43rwMrQRCdPXuKt4Ykaw@mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/5b9312378e2f8fb35ef4584aea351c3319a10422

Modified Files
--------------
src/backend/catalog/heap.c                 |   1 -
src/backend/commands/indexcmds.c           |   2 +-
src/backend/executor/execPartition.c       |   1 -
src/backend/partitioning/partbounds.c      |   6 +-
src/backend/partitioning/partdesc.c        | 112 ++++++++++++++++++++---------
src/backend/utils/cache/partcache.c        |  32 +++++++--
src/backend/utils/cache/relcache.c         | 101 +++++++++++---------------
src/include/partitioning/partdesc.h        |   3 +-
src/include/utils/partcache.h              |   3 +-
src/include/utils/rel.h                    |  19 ++---
src/test/regress/expected/create_table.out |  16 +++++
src/test/regress/sql/create_table.sql      |  11 +++
12 files changed, 186 insertions(+), 121 deletions(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Fix compiler warning for ppoll() on Cygwin
Next
From: Tom Lane
Date:
Subject: pgsql: Allow whole-row Vars to be used in partitioning expressions.