SKIP LOCKED assert triggered

From: Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: SKIP LOCKED assert triggered
Date: 2021-11-12 16:55:17
Message-ID: CANbhV-FeEwMnN8yuMyss7if1ZKjOKfjcgqB26n8pqu1e=q0ebg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The combination of these two statements in a transaction hits an
Assert in heapam.c at line 4770 on REL_14_STABLE

BEGIN;
SELECT * FROM queue LIMIT 1 FOR UPDATE SKIP LOCKED;
...
UPDATE queue SET status = 'UPDATED' WHERE id = :id;
COMMIT;

pgbench reliably finds this, running from inside a PL/pgSQL function.

Alvaro suggests we just ignore the Assert, which on testing appears to
be the right approach. Patch attached, which solves it for me.

There is no formal test that does lock then update, so I have
attempted to create one, but this has not successfully reproduced it
(attached anyway), but this code is different from the pgbench test.

--
Simon Riggs http://www.EnterpriseDB.com/

Attachment Content-Type Size
skip_locked_assert.v1.patch application/octet-stream 629 bytes
skip_locked_then_update_test.v1.patch application/octet-stream 54.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabrice Chapuis 2021-11-12 16:57:41 Re: Logical replication timeout problem
Previous Message Tom Lane 2021-11-12 16:54:20 Re: [PATCH] postgres_fdw: suppress explicit casts in text:text comparisons (was: column option to override foreign types)