Re: Concurrency bug in UPDATE of partition-key

On Mon, Jun 18, 2018 at 11:28 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> 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?
>

I am not sure how much value we will add by having such a test. In
general, it is good to have tests that cover various aspects of
functionality, but OTOH, we have to be careful to not overdo it.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com