Re: Tuple-routing for certain partitioned tables not working as expected

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Tuple-routing for certain partitioned tables not working as expected
Date: 2017-08-07 06:22:30
Message-ID: d5797ceb-627b-ee68-06c2-79247b89e573@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017/08/07 13:11, Amit Langote wrote:> The patch looks good too.
Although, looking at the following hunk:
>
> + Assert(partrel->rd_rel->relkind == RELKIND_RELATION ||
> + partrel->rd_rel->relkind == RELKIND_FOREIGN_TABLE);
> +
> /*
> * Verify result relation is a valid target for the current operation.
> */
> ! if (partrel->rd_rel->relkind == RELKIND_RELATION)
> ! CheckValidResultRel(partrel, CMD_INSERT);
>
> makes me now wonder if we need the CheckValidResultRel check at all. The
> only check currently in place for RELKIND_RELATION is
> CheckCmdReplicaIdentity(), which is a noop (returns true) for inserts anyway.

Good point! I left the verification for a plain table because that is
harmless but as you mentioned, that is nothing but an overhead. So,
here is a new version which removes the verification at all from
ExecSetupPartitionTupleRouting.

Best regards,
Etsuro Fujita

Attachment Content-Type Size
ExecSetupPartitionTupleRouting-v2.patch text/plain 5.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rajkumar Raghuwanshi 2017-08-07 06:24:40 Re: UPDATE of partition key
Previous Message Craig Ringer 2017-08-07 06:06:14 Re: [TRAP: FailedAssertion] causing server to crash