Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?

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(at)entrata(dot)com> wrote:

>
> https://www.postgresql-archive.org/CPU-hogged-by-concurrent-SELECT-FOR-UPDATE-SKIP-LOCKED-td6150480.html
>
> David Rowley on 20 Aug 2020-
> "When updates occur in a non-partitioned table we can follow item
> pointer 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 current
> design."
>
> Moving data between partitions is supported, but maybe another
> partitioning design is better suited for high concurrency use cases.
>