Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
От | Alvaro Herrera |
---|---|
Тема | Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED |
Дата | |
Msg-id | 20200913145512.GA22876@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED (David Rowley <dgrowleyml@gmail.com>) |
Список | pgsql-performance |
On 2020-Sep-14, David Rowley wrote: > On Tue, 8 Sep 2020 at 06:05, Raj <raj@gusw.net> wrote: > > > > > This would not exactly look like a bug, because the message says "to > > > be locked", so at least it's not allowing two workers to lock the same > > > tuple. But it seems that the skip-locked mode should not make an error > > > out of this, but treat it as the tuple was already locked. Why would > > > it want to lock the tuple (representing the job) if another worker has > > > already finished his UPDATE of the job to mark it as "done" (which is > > > what makes the tuple move to the "completed" partition.) > > (It's not very clear who wrote the above text since the quote does not > mention who the author is and the original email didn't appear to have > made it to the list) Same person. https://postgr.es/m/4f379a07-c49b-14dd-ddba-e0aaf37235d5@pragmaticdata.com -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-performance по дате отправления: