Re: can we add SKIP LOCKED to UPDATE?

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 德哥 <digoal(at)126(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: can we add SKIP LOCKED to UPDATE?
Date: 2015-11-10 06:23:26
Message-ID: CAMsr+YG3+-97DinPKxFNH46u56hXgoyHDX-3SqxZogQtoc7VaA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10 November 2015 at 01:38, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> this would be handy in conjunction with LIMIT
> (which also doesn't exist for UPDATE right now).

... and, in turn, UPDATE ... ORDER BY ..., since LIMIT without ORDER
BY is usually not a great choice.

I'd quite like to see UPDATE ... ORDER BY for deadlock avoidance
anyway. Right now doing it really reliably seems to require a SELECT
... FOR UPDATE, then an UPDATE on the SELECTed tuples only. If you're
in READ COMMITTED you can't assume the UPDATE won't see new tuples
since the SELECT so you need to supply a key-list to the UPDATE
directly or via a wCTE.

I'm constantly surprised that people don't seem to hit deadlocks
between updates more often. I guess the number of cases where
multi-row updates on overlapping but non-identical sets of rows occur
concurrently must be fairly limited in practice.

Using SKIP LOCKED in a wCTE with an UPDATE is clunkier but not that
bad. So I don't think it's drastically important, but it would be
nice.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2015-11-10 06:35:29 Re: pg_receivexlog: spurious error message connecting to 9.3
Previous Message Amit Langote 2015-11-10 05:44:23 Re: [PROPOSAL] VACUUM Progress Checker.