| From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
|---|---|
| To: | "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Langote <amitlangote09(at)gmail(dot)com>, Ahsan Hadi <ahsan(dot)hadi(at)gmail(dot)com> |
| Subject: | Re: Small doubt on update a partition when some rows need to move among partition |
| Date: | 2020-08-20 12:57:50 |
| Message-ID: | CAExHW5uoMPuT33KPknoabNR16RXEM+fP7CYbx-coECzjWGJQ6A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 20, 2020 at 5:22 PM movead(dot)li(at)highgo(dot)ca <movead(dot)li(at)highgo(dot)ca> wrote:
>
> Hello,
>
> I am trying to handle the limit that we can't do a tuple move caused by BEFORE TRIGGER,
> during which I get two doubt points:
>
> The first issue:
> In ExecBRUpdateTriggers() or ExecBRInsertTriggers() function why we need to check the
> result slot after every trigger call. If we should check the result slot after all triggers are
> called.
>
> For example, we have a table t1(i int, j int), and a BEFORE INSERT TRIGGER on t1 make i - 1,
> and another BEFORE INSERT TRIGGER on t1 make i + 1. If the first trigger causes a partition
> move, then the insert query will be interrupted. However, it will not change partition after
> all triggers are called.
This was discussed at
https://www.postgresql.org/message-id/20200318210213.GA9781@alvherre.pgsql.
--
Best Wishes,
Ashutosh Bapat
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2020-08-20 13:34:33 | Re: [PG13] Planning (time + buffers) data structure in explain plan (format text) |
| Previous Message | Dilip Kumar | 2020-08-20 12:12:40 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |