pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Craig Ringer <craig@2ndquadrant.com>
To: Thomas Munro <munro@ip9.org>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch
Date: Wed, 27 Aug 2014 19:22:24 -0400
Message-ID: <20140827232224.GL7046@eldon.alvh.no-ip.org> (raw)
In-Reply-To: <20140827195218.GJ7046@eldon.alvh.no-ip.org> <51FB6703.9090801@2ndquadrant.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

Craig Ringer wrote:
> FOR SHARE|UPDATE NOWAIT will still block if they have to follow a ctid
> chain because the call to EvalPlanQualFetch doesn't take a param for
> noWait, so it doesn't know not to block if the updated row can't be locked.

Applied with some further editorialization.


In another thread, I wrote in response to Thomas Munro:

> I tried Craig's patch with your test case and found that it stalls in
> XactLockTableWait inside EPQFetch because it doesn't throw an error in
> the noWait case before waiting.  I think I will fix that and push,
> including both test cases.

Done.  I also made the noWait case try a ConditionalXactLockTableWait
before raising an error, because there's a small chance that the
updating transaction aborts just before we check; in this case there is
no need to raise an error.

> I am wondering about backpatching Craig's fix.  It looks to me like it
> should be backpatched as far back as NOWAIT exists, but that was in 8.1
> and we haven't ever gotten a complaint until Craig's report AFAIK, which
> I understand wasn't coming from a user finding a problem but rather some
> new development.  So I hesitate.

On further reflection, the reason users don't complain is that it's
quite difficult to notice that there is an issue.  And on the other
hand, since they are already specifying NOWAIT in the query, surely they
must already be expecting an error to be raised; it's not like this
introduces a new failure mode.  My inclination would be to backpatch the
fix all the way back.

However, due to time constraints (because it fails to apply cleanly
to older branches) and due to lack of user complaints, I only
backpatched to 9.4.  We can always revisit that, if there's demand.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (5+ messages)

Message-ID: <20140827232224.GL7046@eldon.alvh.no-ip.org>
Permalink:  ../20140827232224.GL7046@eldon.alvh.no-ip.org/
Also on:    postgresql.org/message-id/20140827232224.GL7046@eldon.alvh.no-ip.org

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: alvherre@2ndquadrant.com, craig@2ndquadrant.com, munro@ip9.org
  Subject: Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch
  In-Reply-To: <20140827232224.GL7046@eldon.alvh.no-ip.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox