On Sun, Aug 2, 2015 at 11:37 PM, Rajeev rastogi
<[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
