From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: FOR SHARE vs FOR UPDATE locks |
Date: | 2006-12-01 16:55:56 |
Message-ID: | 45705E9C.2060003@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> I'm not sure we can use the simple "raise an ERROR" answer though,
>> because for users that would be a regression.
>
> I've reconsidered the idea of upgrading the outer xact's shared lock to
> exclusive: at first I thought that would be hard to implement correctly,
> but now I realize it's easy. Just re-use the XID that's in the multixact
> as the one to store as the exclusive locker, instead of storing our
> current subxact XID. In some cases this will be a subcommitted XID of
> the current subxact or a parent, but the locking semantics are the same,
> and even though we think such an XID is finished everyone else will see
> it as still live so the appearance of its XID in an XMAX field shouldn't
> be an issue.
That way, the lock won't be downgraded back to a shared lock on
"rollback to savepoint", right? Though it's still better than throwing
an error, I think.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-12-01 17:18:58 | Re: FOR SHARE vs FOR UPDATE locks |
Previous Message | Zeugswetter Andreas ADI SD | 2006-12-01 15:45:00 | Re: FOR SHARE vs FOR UPDATE locks |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-12-01 17:18:58 | Re: FOR SHARE vs FOR UPDATE locks |
Previous Message | Zeugswetter Andreas ADI SD | 2006-12-01 15:45:00 | Re: FOR SHARE vs FOR UPDATE locks |