| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Langote <amitlangote09(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: BEFORE trigger can cause undetected partition constraint violation |
| Date: | 2017-06-05 05:02:40 |
| Message-ID: | b8fb90d4-b369-31b2-5628-3a099fad739d@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2017/06/03 1:56, Robert Haas wrote:
> On Fri, Jun 2, 2017 at 12:51 AM, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> Attached patch makes InitResultRelInfo() *always* initialize the
>> partition's constraint, that is, regardless of whether insert/copy is
>> through the parent or directly on the partition. I'm wondering if
>> ExecInsert() and CopyFrom() should check if it actually needs to execute
>> the constraint? I mean it's needed if there exists BR insert triggers
>> which may change the row, but not otherwise. The patch currently does not
>> implement that check.
>
> I think it should. I mean, otherwise we're leaving a
> probably-material amount of performance on the table.
I agree. Updated the patch to implement the check.
Thanks,
Amit
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Check-the-partition-constraint-even-after-tuple-rout.patch | text/plain | 7.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2017-06-05 05:55:37 | Re: proposal psql \gdesc |
| Previous Message | Jing Wang | 2017-06-05 04:20:04 | Re: Support to COMMENT ON DATABASE CURRENT_DATABASE |