Subject: About upgrading a (tuple?) lock in a rollback'd sub-transaction

From: Amit Langote <[email-masked]>
Date: Thu, 10 Apr 2014 11:41:04 +0900

Hi,

Currently there is a warning against the following in manual:

BEGIN;
SELECT * FROM mytable WHERE key = 1 FOR UPDATE;
SAVEPOINT s;
UPDATE mytable SET ... WHERE key = 1;
ROLLBACK TO s;

here: http://www.postgresql.org/docs/9.2/static/sql-select.html

IIUC, it says if the lock-upgrading sub-transaction is rollback'd, as
an undesirable effect, any lock held by the parent transaction is
effectively lost.

A few tests suggest that the lock is still effective for a concurrent
transaction started before the lock-upgrading operation (UPDATE) in
the later savepoint. The lock is forgotten, though, if a concurrent
transaction acquired the lock after the UPDATE on the tuple in the
later savepoint. As soon as the UPDATE is rollback'd, the concurrent
transaction, blind to any lock the parent transaction had on the
tuple, gets the lock.

--------------------------------------------------
1] -- session-1

$ BEGIN;
$ SELECT * FROM mytable WHERE Key = 1 FOR UPDATE

2] -- session-1

$ SAVEPOINT s;
$ UPDATE mytable SET ... WHERE key = 1;

3] -- session-2

$ SELECT * FROM mytable WHERE Key = 1 FOR UPDATE

4] -- session-1

$ ROLLBACK TO s;

5] -- session-2

-- gets the lock and free to modify the tuple (inconistently, off course)
------------------------------------------------------

Although, if [3] were before [2], this wouldn't happen

I know it is still a warned-against usage; but, is it useful to
clarify this nuance of the behavior?

--
Amit

-- 
Sent via pgsql-general mailing list ([email-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

---

From: Rob Sargent <[email-masked]>
Date: Thu, 10 Apr 2014 07:25:50 -0600

And it also tells you how to stop it --bibtex iirc

Sent from my iPhone

> On Apr 9, 2014, at 8:41 PM, Amit Langote <[email-masked]> wrote:
> 
> Hi,
>

---

From: Amit Langote <[email-masked]>
Date: Fri, 11 Apr 2014 09:45:52 +0900

> And it also tells you how to stop it --bibtex iirc

Yeah, it's a caution against a potentially harmful usage anyway. Users
should not use it at all.

I was just wondering if the description of the behavior, that is,
potential disappearance of certain locks is complete enough.

--
Amit

-- 
Sent via pgsql-docs mailing list ([email-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

---

From: Alvaro Herrera <[email-masked]>
Date: Thu, 10 Apr 2014 23:52:47 -0300

> potential disappearance of certain locks is complete enough.

You do realize that this is no longer the case in 9.3, right?
I don't see a point in changing old releases' documentation.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

---

From: Amit Langote <[email-masked]>
Date: Fri, 11 Apr 2014 12:40:53 +0900

> I don't see a point in changing old releases' documentation.

I see, okay.
And yes, I'm aware that this's no longer an issue in 9.3.

Thanks,
Amit