Small doubt on update a partition when some rows need to move among partition

From: "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: "Amit Langote" <amitlangote09(at)gmail(dot)com>, "Ahsan Hadi" <ahsan(dot)hadi(at)gmail(dot)com>
Subject: Small doubt on update a partition when some rows need to move among partition
Date: 2020-08-20 09:23:05
Message-ID: 2020082017164661079648@highgo.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

The second issue:
I read the code for partition move caused by an update, it deletes tuple in an old partition
and inserts a new tuple in a partition. But during the insert, it triggers the trigger on the new
partition, so the result value may be changed again, I want to know if it's intended way? In
my mind, if an insert produced by partition move should not trigger before trigger again.

I make an initial patch as my thought, sorry if I missing some of the historical discussion.

Regards,
Highgo Software (Canada/China/Pakistan)
URL : www.highgo.ca
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

Attachment Content-Type Size
partition_move_issues.patch application/octet-stream 5.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2020-08-20 10:19:49 Fix a couple of typos in JIT
Previous Message Amit Kapila 2020-08-20 08:59:42 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions