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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
