| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Emil Iggland <emil(at)iggland(dot)com> |
| Cc: | David Christensen <david(dot)christensen(at)crunchydata(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Surafel Temesgen <surafel3000(at)gmail(dot)com> |
| Subject: | Re: BUG #17141: SELECT LIMIT WITH TIES FOR UPDATE SKIP LOCKED returns wrong number of rows |
| Date: | 2021-10-02 22:05:14 |
| Message-ID: | 202110022205.jwz6b5bdyja5@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 2021-Aug-25, Emil Iggland wrote:
> I see a lot of thought being put into how this issue can be worked
> around, but very little discussion on if this behaviour is correct or
> not. Without having thought about it much deeper, this seems to only be
> a problem with the "WITH TIES" clause which provokes this extra row
> being locked. Perhaps that is where the problem should be attacked.
The problem is that when the WITH TIES clause is added, we need to read
one extra row after the one that reaches the LIMIT count, in order to
verify whether it (the next one) should be included due to a tie. With
the executor structure that we currently have, there is no way to read
that row and not lock it. So a good fix would be to separate the act of
locking the row from the act of reading it.
--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-10-02 22:30:44 | Re: BUG #17141: SELECT LIMIT WITH TIES FOR UPDATE SKIP LOCKED returns wrong number of rows |
| Previous Message | Peter Geoghegan | 2021-10-02 17:32:57 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |