Re: Statement-level Triggers For Uniqueness Checks

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Statement-level Triggers For Uniqueness Checks
Дата
Msg-id 6ce0ee3f-434c-6286-56b2-45ceed0c7dbf@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Statement-level Triggers For Uniqueness Checks  (Corey Huinker <corey.huinker@gmail.com>)
Список pgsql-hackers
On 08/01/2019 23:26, Corey Huinker wrote:
> On Fri, Jan 4, 2019 at 7:49 AM Peter Eisentraut
> <peter.eisentraut@2ndquadrant.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dmitry Dolgov
Дата:
Сообщение: Re: Displaying and dumping of table access methods
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: could recovery_target_timeline=latest be the default in standbymode?