Re: Statement-level Triggers For Uniqueness Checks

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Statement-level Triggers For Uniqueness Checks
Date: 2019-01-11 09:22:41
Message-ID: 6ce0ee3f-434c-6286-56b2-45ceed0c7dbf@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/01/2019 23:26, Corey Huinker wrote:
> On Fri, Jan 4, 2019 at 7:49 AM Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>>
>> On 25/12/2018 00:56, Corey Huinker wrote:
>>> The regression diff (attached) seems to imply that the triggers simply
>>> are not firing, though.
>>
>> The reason for this was explained by Dean. If you take out the check
>> that he mentioned, then your trigger fires but crashes. In your changed
>> unique_key_recheck(), "slot" is not initialized before use (or ever).
>
> Thanks. I'll be revisiting this shortly. Dean's information made me
> think the potential for a gain is smaller than initially imagined.

I think those are independent considerations. The "recheckIndexes"
logic just tracks what indexes have potential conflicts to check later.
Whether that checking later happens in a row or statement trigger should
not matter. What you need to do is adapt the "recheckIndexes" logic
from row triggers to statement triggers, e.g., expand
ExecASInsertTriggers() to look more like ExecARInsertTriggers().

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-01-11 10:17:48 Re: could recovery_target_timeline=latest be the default in standby mode?
Previous Message Dmitry Dolgov 2019-01-11 09:18:35 Re: Displaying and dumping of table access methods