From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: unsupportable composite type partition keys
Date: Mon, 23 Dec 2019 09:49:16 -0500
Message-ID: <25383.1577112556@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+HiwqGug69_zhRCzENJPg_Ynpx_Eb-2-=N1u2Zw3X6T1S3wbQ@mail.gmail.com>
References: <CA+HiwqFUzjfj9HEsJtYWcr1SgQ_=iCAvQ=O2Sx6aQxoDu4OiHw@mail.gmail.com>
<5361.1576602769@sss.pgh.pa.us>
<CA+HiwqGiGBgFFcL6YGKRqfX1-gYKmuLLG_JwU_UaSaX2J+jehQ@mail.gmail.com>
<28160.1576676326@sss.pgh.pa.us>
<CA+HiwqENLY2ta0goA0jcfk4cWdj2W0r6Ywjf=PQiMpJkyXygmg@mail.gmail.com>
<26766.1576947735@sss.pgh.pa.us>
<24653.1576962784@sss.pgh.pa.us>
<CA+HiwqGug69_zhRCzENJPg_Ynpx_Eb-2-=N1u2Zw3X6T1S3wbQ@mail.gmail.com>
Amit Langote <amitlangote09@gmail.com> writes:
> On Sun, Dec 22, 2019 at 6:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> + * To ensure that it's not leaked completely, re-attach it to the
> + * new reldesc, or make it a child of the new reldesc's rd_pdcxt
> + * in the unlikely event that there is one already. (See hack in
> + * RelationBuildPartitionDesc.)
> While I can imagine that RelationBuildPartitionDesc() might encounter
> an old partition descriptor making the re-parenting hack necessary
> there, I don't see why it's needed here, because a freshly built
> relation descriptor would not contain the partition descriptor after
> this patch.
Well, as the comment says, that's probably unreachable today. But
I could see it happening in the future, particularly if we ever allow
partitioned system catalogs. There are a lot of paths through this
code that are not obvious to the naked eye, and some of them can cause
relcache entries to get populated behind-your-back. Most of relcache.c
is careful about this; I do not see an excuse for the partition-data
code to be less so, even if we think it can't happen today.
(I notice that RelationBuildPartitionKey is making a similar assumption
that the partkey couldn't magically appear while it's working, and I
don't like it much there either.)
>> * It'd be better to declare RelationGetPartitionKey and
>> RelationGetPartitionDesc in relcache.h and get their callers out of the
>> business of including rel.h, where possible.
> Although I agree to declare them in relcache.h, that doesn't reduce
> the need to include rel.h in their callers much, because anyplace that
> uses RelationGetPartitionDesc() is also very likely to use
> RelationGetRelid() which is in rel.h.
Hm. Well, we can try anyway.
> [1] https://www.postgresql.org/message-id/CA%2BHiwqFucUh7hYkfZ6x1MVcs_R24eUfNVuRwdE_FwuwK8XpSZg%40mail.g...
Oh, interesting --- I hadn't been paying much attention to that thread.
I'll compare your PoC there to what I did.
regards, tom lane
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: tgl@sss.pgh.pa.us, amitlangote09@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: unsupportable composite type partition keys
In-Reply-To: <25383.1577112556@sss.pgh.pa.us>
* 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