From: Joshua D. Drake <jd@commandprompt.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki@enterprisedb.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-core@postgresql.org
Subject: Re: FOR SHARE vs FOR UPDATE locks
Date: Fri, 01 Dec 2006 10:54:38 -0800
Message-ID: <1164999278.29643.46.camel@localhost.localdomain> (raw)
In-Reply-To: <1128.1164998817@sss.pgh.pa.us>
References: <1144.1164924373@sss.pgh.pa.us>
<1164962544.3778.847.camel@silverbirch.site>
<20061201113711.GC30441@alvh.no-ip.org>
<15834.1164985926@sss.pgh.pa.us>
<45705E9C.2060003@enterprisedb.com>
<534.1164994846@sss.pgh.pa.us>
<45706A77.8030503@enterprisedb.com>
<1128.1164998817@sss.pgh.pa.us>
On Fri, 2006-12-01 at 13:46 -0500, Tom Lane wrote:
> "Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> > Let's throw an error for now. We have to come back to this in 8.3, I think.
>
> After further thought I think we should also seriously consider plan C:
> do nothing for now. We now realize that there have been related bugs
> since 8.0, namely that
>
> begin;
> select some rows for update;
> savepoint x;
> update the same rows;
> rollback to x;
>
> leaves the tuple(s) not locked. The lack of complaints about this from
> the field suggests that this isn't a huge problem in practice. If we
> do make it throw an error I'm afraid that we will break applications
> that aren't having a problem at the moment.
>
> I'm also realizing that a fix along the throw-an-error line is
> nontrivial, eg, HeapTupleSatisfiesUpdate would need another return code.
>
> So at this point we are facing three options:
> - throw in a large and poorly tested "fix" at the last moment;
> - postpone 8.2 until we can think of a real fix, which might
> be a major undertaking;
> - ship 8.2 with the same behavior 8.0 and 8.1 had.
> None of these are very attractive, but I'm starting to think the last
> is the least bad.
/me struggles...
IMHO:
option 2 is the correct option, but the least favorable.
option 1 is probably bad
option 3 is the lesser of the evils if we document it loudly.
Joshua D. Drake
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: jd@commandprompt.com, tgl@sss.pgh.pa.us, heikki@enterprisedb.com, alvherre@commandprompt.com, simon@2ndquadrant.com, pgsql-hackers@postgresql.org, pgsql-core@postgresql.org
Subject: Re: FOR SHARE vs FOR UPDATE locks
In-Reply-To: <1164999278.29643.46.camel@localhost.localdomain>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox