On 07/23/2015 11:39 AM, Robert Haas wrote: > On Thu, Jul 23, 2015 at 2:33 PM, Josh Berkus <j...@agliodbs.com> wrote: >>> Requesting for everyone's opinion regarding this based on which we can >>> proceed to enhance/tune/re-write our design. >> >> So, one of the things which came up during the discussion was advancing >> XMIN, which is not important to the audit logging use case, but is very >> important for the batch job use case. What have you concluded regarding >> this item? > > Could you explain more specifically what you are talking about here? >
Yeah, my notes are kinda incoherent, no? There's two core use-cases for Autonomous Transactions (hereafter ATX): * audit logging * batch jobs Audit Logging: triggers or other statements which should leave a record even when a transaction aborts. While audit logging is the main example of this use case, any kind of logging of failures is applicable. Batch Jobs: large data-manipulation tasks which need to be broken up into segments, with each segment committing separately. Example: updating 1 million records in batches of 1000. Unlike the Audit Logging case, Batch Jobs generally want XMIN to advance so that updated/imported/deleted rows can be vacuumed or HOT updated. Thus the need to allow XMIN to advance. One of the things we kind of concluded from our discussion was that the two core use-cases are probably different features: Audit Logging: * requires 2-way data interaction with outer transaction * no parallelism * XMIN does not need to advance * master transaction should still commit/fail * needs to support nesting Batch Jobs: * 1-way data interaction sufficient (master-->child) * parallelism desired * XMIN should advance * master process could be transactionless * does not need to support nesting Of these two, the Audit Logging case is the more important one to implement because there is no real workaround for it. Batch Jobs can, and are, handled by external scripting, and having ATX for them is more of a convenience than anything else. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
