| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | pgsql-bugs(at)postgresql(dot)org |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, Lee McKeeman <lmckeeman(at)opushealthcare(dot)com> |
| Subject: | Re: Status of issue 4593 |
| Date: | 2009-01-06 14:31:09 |
| Message-ID: | 200901061631.09522.peter_e@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
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 evidently a bit more user-visible than
> I'd realized.
Well, if the effect of ORDER BY + FOR UPDATE is "it might in fact not be
ordered", then it's pretty broken IMO. It would be pretty silly by analogy
for example, if the effect of GROUP BY + FOR UPDATE were "depending on
concurrent events, it may or may not be fully grouped".
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua Tolley | 2009-01-06 14:37:11 | Re: BUG #4601: Data saving and opening problem |
| Previous Message | val | 2009-01-06 14:00:06 | Re: PANIC: failed to re-find parent key in "100924" for split pages 1606/1673 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-01-06 14:44:48 | Re: Bugs during ProcessCatchupEvent() |
| Previous Message | Heikki Linnakangas | 2009-01-06 14:24:55 | Re: Some more function-default issues |