| From: | "P(dot) Christeas" <xrg(at)linux(dot)gr> |
|---|---|
| To: | Marko Tiikkaja <marko(at)joh(dot)to> |
| Cc: | pgsql-docs(at)postgresql(dot)org |
| Subject: | Re: Row locking within a SELECT statement |
| Date: | 2016-08-16 10:30:06 |
| Message-ID: | 23360955.XyY9xrDyAl@xorhgos3.pefnos |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs |
Στις Τρι 16 Αυγ 2016 11:23:59 π.μ. Marko Tiikkaja έγραψε:
> On 2016-08-16 08:19, xrg(at)linux(dot)gr wrote:
> > In order to avoid concurrent manipulation of rows, I do issue a
> > "SELECT .. FOR UPDATE" on the sets of rows, before UPDATEing
> > them (because UPDATEs cannot be ordered).
>
> Yeah, but FOR UPDATEs are not ordered either unless you use ORDER BY,
> which you didn't.
So, the case is that these two statements:
SELECT id FROM alerts ORDER BY id FOR UPDATE;
and
SELECT id FROM alerts ORDER BY id DESC FOR UPDATE;
are guarranteed to deadlock [1], right?
Well, in my opinion, this anti-pattern deserves to be documented.
Thank you for the quick response.
[1] because each of those statements will begin locking rows, one at a time,
and then reach the ones of the other statement and wait.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-08-16 14:59:55 | Re: Outdated sentence in the pg_am description |
| Previous Message | Marko Tiikkaja | 2016-08-16 09:23:59 | Re: Row locking within a SELECT statement |