Re: Concurrency bug in UPDATE of partition-key

On Mon, Jun 18, 2018 at 10:21 AM, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
> Attached is v2 version of the patch. It contains the above
> trigger-related issue fixed.
>
> The updated tuple is passed back using the existing newslot parameter
> of GetTupleForTrigger(). When ExecBRDeleteTriggers() is called using a
> new epqslot parameter, it means caller wants to skip the trigger
> execution, because the updated tuple needs to be again checked for
> constraints. I have added comments of this behaviour in the
> ExecBRDeleteTriggers() function header.
>

Thanks for the updated patch. I have verified the BR trigger
behaviour, its working fine with the patch.

+ CREATE FUNCTION func_footrg() RETURNS TRIGGER AS $$
+ BEGIN
+ RETURN OLD;
+ END $$ LANGUAGE PLPGSQL;
+ CREATE TRIGGER footrg_ondel BEFORE DELETE ON footrg1
+ FOR EACH ROW EXECUTE PROCEDURE func_footrg();

Should we also create a test case where we can verify that some
unnecessary or duplicate triggers are not executed? For example, in
the above trigger function, we can maintain a count in some table (e.g
how many time delete trigger got executed) and after test over we can
verify the same.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com