Date: Sun, 13 Sep 2020 11:55:12 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Raj <raj@gusw.net>,
	Pgsql Performance <pgsql-performance@lists.postgresql.org>
Subject: Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
Message-ID: <20200913145512.GA22876@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAApHDvpGWVrbxmXng91wDGascsYKgFXtrtBTGVDKRkSumj_Etg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

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