Re: [BUGS] Status of issue 4593

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Lee McKeeman <lmckeeman(at)opushealthcare(dot)com>
Subject: Re: [BUGS] Status of issue 4593
Date: 2009-01-12 19:11:53
Message-ID: 1231787513.27085.30.camel@dell.linuxdev.us.dell.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Mon, 2009-01-12 at 13:35 -0500, Tom Lane wrote:
> I think the behavior Lee is expecting is only implementable with a
> full-table write lock, which is exactly what FOR UPDATE is designed
> to avoid. There are certain properties you don't get with a partial
> lock, and in the end I think we can't do much except document them.
> We have LOCK TABLE for those who need the other behavior.
>

Lee said specifically that he's not using LIMIT, and there's already a
pretty visible warning in the docs for using LIMIT with FOR UPDATE.
Also, using LIMIT + FOR UPDATE has a dangerous-looking quality to it (at
least to me) that would cause me to do a little more investigation
before relying on its behavior.

I'm not pushing for FOR UPDATE + ORDER BY to be blocked outright, but I
think it's strange enough that it should be considered some kind of
defect worse than the cases involving LIMIT that you mention.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2009-01-12 19:21:08 Re: [BUGS] Status of issue 4593
Previous Message Kevin Grittner 2009-01-12 19:01:49 Re: [BUGS] Status of issue 4593

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2009-01-12 19:17:26 Re: Recovery Test Framework
Previous Message Heikki Linnakangas 2009-01-12 19:05:57 Re: Recovery Test Framework