Re: FOR SHARE vs FOR UPDATE locks

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