Re: BUG #17141: SELECT LIMIT WITH TIES FOR UPDATE SKIP LOCKED returns wrong number of rows
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #17141: SELECT LIMIT WITH TIES FOR UPDATE SKIP LOCKED returns wrong number of rows |
Дата | |
Msg-id | 202108112007.evylbmzueapg@alvherre.pgsql обсуждение исходный текст |
Ответ на | BUG #17141: SELECT LIMIT WITH TIES FOR UPDATE SKIP LOCKED returns wrong number of rows (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #17141: SELECT LIMIT WITH TIES FOR UPDATE SKIP LOCKED returns wrong number of rows
Re: BUG #17141: SELECT LIMIT WITH TIES FOR UPDATE SKIP LOCKED returns wrong number of rows |
Список | pgsql-bugs |
On 2021-Aug-11, PG Bug reporting form wrote: > BEGIN; > SELECT * FROM queue > ORDER BY task DESC > FETCH FIRST 1 ROWS WITH TIES > FOR UPDATE SKIP LOCKED; > /* Some work to be done here */ > COMMIT; > > select version(); > PostgreSQL 13.3, compiled by Visual C++ build 1914, 64-bit > > Expected result Worker 1: (580), (580), Actual result Worker 1: (580), (580) > Expected result Worker 2: (480), (480), Actual result Worker 2: (480) Ouch, we already saw this actually: https://postgr.es/m/16676-fd62c3c835880da6@postgresql.org The problem is that the first worker locks the first (480) row (even though it does not return it), so the second worker skips it due to SKIP LOCKED. I have this on my list of things to look at, but it's not at the top yet sadly ... -- Álvaro Herrera
В списке pgsql-bugs по дате отправления: