On Sun, Aug 2, 2015 at 11:37 PM, Rajeev rastogi
<rajeev.rastogi@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
conflictwith themselves, even with autonomous transactions? That seems like an artifact of somebody else's
implementationthat 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
transactionto 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
somemechanism to handle this rare case, for which as of now I think throwing error from autonomous transaction as one
ofthe solution. Once error thrown from autonomous transaction, main transaction may continue as it is (or abort main
transactionalso??).
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
