From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Raj <raj(at)gusw(dot)net>, Pgsql Performance <pgsql-performance(at)lists(dot)postgresql(dot)org> |
Subject: | Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED |
Date: | 2020-09-13 14:55:12 |
Message-ID: | 20200913145512.GA22876@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 2020-Sep-14, David Rowley wrote:
> On Tue, 8 Sep 2020 at 06:05, Raj <raj(at)gusw(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gopisetty, Ramesh | 2020-09-13 14:58:15 | Performance Issue (Not using Index when joining two tables). |
Previous Message | David Rowley | 2020-09-13 13:52:23 | Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED |