Re: pre-commit triggers

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pre-commit triggers
Date: 2013-11-19 13:54:49
Message-ID: 528B6DA9.8000100@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 11/19/2013 12:45 AM, Noah Misch wrote:
> On Fri, Nov 15, 2013 at 01:01:48PM -0500, Andrew Dunstan wrote:
>> The triggers don't fire if there is no real XID, so only actual data
>> changes should cause the trigger to fire.
> What's the advantage of this provision? Without it, an individual trigger
> could make the same check and drop out quickly. A trigger not wanting it
> can't so easily work around its presence, though. Heretofore, skipping XID
> assignment has been an implementation detail that improves performance without
> otherwise calling user attention to itself. This provision would make the
> decision to acquire an XID (where optional) affect application behavior.
>

Mainly speed. How is the trigger (especially if not written in C) going
to check the same thing?

Conventional triggers don't fire except on data changing events, so this
seemed consistent with that.

Perhaps my understanding of when XIDs are acquired is insufficient. When
exactly is it optional?

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-11-19 14:12:42 Re: better atomics - v0.2
Previous Message Fujii Masao 2013-11-19 13:41:39 Re: New option for pg_basebackup, to specify a different directory for pg_xlog