On Sun, Aug 2, 2015 at 11:37 PM, Rajeev rastogi <rajeev.rast...@huawei.com> wrote: > On 31 July 2015 23:10, Robert Haas Wrote: >>I think we're going entirely down the wrong path here. Why is it ever useful >>for a backend's lock requests to conflict with themselves, even with >>autonomous transactions? That seems like an artifact of somebody else's >>implementation that we should be happy we don't need to copy. > > IMHO, since most of the locking are managed at transaction level not backend > level and we consider main & autonomous transaction to be independent > transaction, then practically they may conflict right. > It is also right as you said that there is no as such useful use-cases where > autonomous transaction conflicts with main (parent) transaction. But we > cannot take it for granted as user might make a mistake. So at-least we > should have some mechanism to handle this rare case, for which as of now I > think throwing error from autonomous transaction as one of the solution. Once > error thrown from autonomous transaction, main transaction may continue as it > is (or abort main transaction also??).
hm. OK, what's the behavior of: BEGIN UPDATE foo SET x = x + 1 WHERE foo_id = 1; BEGIN WITH AUTONOMOUS TRANSACTION UPDATE foo SET x = x + 1 WHERE foo_id = 1; END; RAISE EXCEPTION ...; EXCEPTION ... END; Also, *) What do the other candidate implementations do? IMO, compatibility should be the underlying design principle. *) What will the "SQL only" feature look like? *) Is the SPI interface going to be extended to expose AT? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers