To me it seems like bug because it clearly states it tries to lock on non existing row:
"tuple to be locked was already moved to another partition due to concurrent update"
But there is SKIP LOCKED clause so why throw an error that it can't lock if we explicitly ask to not bother if you can't lock and just skip it.
Best, Saludos, Kamil Dziedzic
On Fri, Mar 12, 2021, 17:22 Michael Lewis <mlewis@xxxxxxxxxxx> wrote:
https://www.postgresql-archive.org/CPU-hogged-by-concurrent-SELECT-FOR-UPDATE-SKIP-LOCKED-td6150480.htmlDavid Rowley on 20 Aug 2020-"When updates occur in a non-partitioned table we can follow itempointer chains to find the live row and check if the WHERE clause
still matches to determine if the row should be updated, or in this
case just locked since it's a SELECT FOR UPDATE. However, with
partitioned table, a concurrent UPDATE may have caused the row to have
been moved off to another partition, in which case the tuple's item
pointer cannot point to it since we don't have enough address space,
we only have 6 bytes for a TID. To get around the fact that we can't
follow these update chains, we just throw the serialization error,
which is what you're getting. Ideally, we'd figure out where the live
version of the tuple is and check if it matches the WHERE clause and
lock it if it does, but we've no means to do that with the currentdesign."Moving data between partitions is supported, but maybe another partitioning design is better suited for high concurrency use cases.
