| From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
|---|---|
| To: | Yury Bokhoncovich <byg(at)center-f1(dot)ru> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)atentus(dot)com>, "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl>, <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: Implementation of LIMIT on DELETE and UPDATE statements |
| Date: | 2002-09-25 15:21:51 |
| Message-ID: | 20020925080434.E8681-100000@megazone23.bigpanda.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
On Wed, 25 Sep 2002, Yury Bokhoncovich wrote:
> Hello!
>
> On Mon, 23 Sep 2002, Tom Lane wrote:
>
> > The above is really a perfect example of why this feature isn't safe:
> > it would lead people to make unwarranted assumptions. The fact that
> > such-and-such a tuple appeared second in the output of LIMIT 10 OFFSET
> > 20 does *not* mean that it would be selected by LIMIT 1 OFFSET 21. The
>
> Agreed. But if records are inserted by INSERT (times) values (now()) and
> those are selected ORDER BY times - the result is probably well
> determined.;)
Only if you're in serializable isolation mode or if there's never more
than one concurrent update transaction. Otherwise concurrent updates that
have committed between the select and delete could change the set of rows
you see and therefore the rows you delete. TANSTAAFL unfortunately.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steven Singer | 2002-09-25 23:25:41 | contrib/dbmirror bug + doc fix. |
| Previous Message | Yury Bokhoncovich | 2002-09-25 13:18:13 | Re: Implementation of LIMIT on DELETE and UPDATE statements |