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-21 11:45:55 |
Message-ID: | 949dd1ed-c2db-026c-6ca6-89026e750b8a@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017/08/07 15:45, Etsuro Fujita wrote:
> On 2017/08/07 15:33, Amit Langote wrote:
>> On 2017/08/07 15:22, Etsuro Fujita wrote:
>>> 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.
>>
>> The updated patch looks good to me, thanks.
>
> Thanks for the review!
If there are no objections, I'll add this to the open item list for v10.
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-08-21 12:30:51 | Re: Regressions failures with libxml2 on ArchLinux |
Previous Message | Etsuro Fujita | 2017-08-21 11:37:02 | Re: postgres_fdw bug in 9.6 |