On Tue, Nov 19, 2013 at 08:54:49AM -0500, Andrew Dunstan wrote:
>
> 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?
Probably through a thin C function calling GetCurrentTransactionIdIfAny(). If
using C is not an option, one could query pg_locks.
> Conventional triggers don't fire except on data changing events, so
> this seemed consistent with that.
The definitions of "data changing event" differ, though. An UPDATE that finds
no rows to change will fire statement-level triggers, but this commit trigger
would not fire.
> Perhaps my understanding of when XIDs are acquired is insufficient.
> When exactly is it optional?
The following commands force XID assignment, but I think that's an
implementation detail rather than a consequence of their identity as
data-changing events:
SELECT ... FOR <lockmode>
NOTIFY
PREPARE TRANSACTION (gets an XID even if nothing else had done so)
Also, parents of XID-bearing subtransactions always have XIDs, even if all
subtransactions that modified data have aborted. This, too, is an
implementation artifact.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com