Re: [BUGS] Status of issue 4593

2009-01-06 Thread Peter Eisentraut
On Tuesday 06 January 2009 02:03:14 Tom Lane wrote: > I don't think there's a bug here, at least not in the sense that it > isn't Operating As Designed.  But it does seem like we could do with > some more/better documentation about exactly how FOR UPDATE works. > The sequence of operations is evide

Re: [BUGS] Status of issue 4593

2009-01-05 Thread Tom Lane
Jeff Davis writes: > On Mon, 2009-01-05 at 15:42 -0500, Tom Lane wrote: >> The only way to avoid this would be to lock before the sort, which could >> have the effect of locking more rows than are returned (if you also use >> LIMIT); > How would that work in the case of an index scan sort? It wo

Re: [BUGS] Status of issue 4593

2009-01-05 Thread Jeff Davis
On Mon, 2009-01-05 at 15:42 -0500, Tom Lane wrote: > The only way to avoid this would be to lock before the sort, which could > have the effect of locking more rows than are returned (if you also use > LIMIT); How would that work in the case of an index scan sort? Regards, Jeff Davis -

Re: [BUGS] Status of issue 4593

2009-01-05 Thread Lee McKeeman
m Lane [mailto:t...@sss.pgh.pa.us] Sent: Monday, January 05, 2009 2:42 PM To: Lee McKeeman Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] Status of issue 4593 "Lee McKeeman" writes: > Description:order by is not honored after select ... for update The reason for this behavio

Re: [BUGS] Status of issue 4593

2009-01-05 Thread Tom Lane
"Lee McKeeman" writes: > Description:order by is not honored after select ... for update The reason for this behavior is that SELECT FOR UPDATE substitutes the latest version of the row at the time the row lock is acquired, which is the very last step after the selection and ordering have

Re: [BUGS] Status of issue 4593

2009-01-05 Thread Jeff Davis
On Mon, 2009-01-05 at 09:03 -0600, Lee McKeeman wrote: > I did not see anything that indicated to me that order by may not be > handled properly at the read committed isolation level, so I do believe > this to be erroneous behavior, and therefore a bug. I have attempted > this in 8.3.4 and > 8.2.6

Re: [BUGS] Status of issue 4593

2009-01-05 Thread Lee McKeeman
ld be helpful. -Lee -Original Message- From: Dave Page [mailto:dp...@pgadmin.org] Sent: Monday, January 05, 2009 8:57 AM To: Lee McKeeman Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] Status of issue 4593 On Mon, Jan 5, 2009 at 2:47 PM, Lee McKeeman wrote: > I got a "stalled post&

Re: [BUGS] Status of issue 4593

2009-01-05 Thread Dave Page
On Mon, Jan 5, 2009 at 2:47 PM, Lee McKeeman wrote: > I got a "stalled post" message because at the time of filing I was not > on this list. I don't know when moderators would look at it, and if > perhaps they deemed that it should not be posted, so it was discarded > without me being notified. W

Re: [BUGS] Status of issue 4593

2009-01-05 Thread Lee McKeeman
ee -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Monday, January 05, 2009 8:39 AM To: Lee McKeeman Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] Status of issue 4593 "Lee McKeeman" writes: > This may not be the appropriate place to check this, but

Re: [BUGS] Status of issue 4593

2009-01-05 Thread Tom Lane
"Lee McKeeman" writes: > This may not be the appropriate place to check this, but when I filed > the bug with the tracking number 4593, in relation to some sort order > behavior which seemed erroneous to me. That bug number never came by here --- might've gotten eaten by spam filters? Anyway, we

[BUGS] Status of issue 4593

2009-01-04 Thread Lee McKeeman
This may not be the appropriate place to check this, but when I filed the bug with the tracking number 4593, in relation to some sort order behavior which seemed erroneous to me. I didn't know how I would be notified if this was actually considered a bug, etc. so I thought I'd post here and see wha