From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Thomas Munro <munro(at)ip9(dot)org> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SKIP LOCKED DATA (work in progress) |
Date: | 2014-09-10 13:47:28 |
Message-ID: | 20140910134728.GB4701@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro wrote:
> @@ -2022,7 +2030,7 @@ EvalPlanQualFetch(EState *estate, Relation relation, int lockmode, bool noWait,
> */
> test = heap_lock_tuple(relation, &tuple,
> estate->es_output_cid,
> - lockmode, noWait,
> + lockmode, wait_policy,
> false, &buffer, &hufd);
> /* We now have two pins on the buffer, get rid of one */
> ReleaseBuffer(buffer);
Doesn't this heap_lock_tuple() need to check for a WouldBlock result?
Not sure that this is the same case that you were trying to test in
heap_lock_updated_tuple; I think this requires an update chain (so that
EPQFetch is invoked) and some tuple later in the chain is locked by a
third transaction.
I attach some additional minor suggestions to your patch. Please feel
free to reword comments differently if you think my wording isn't an
improvements (or I've maked an english mistakes).
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-09-10 14:34:09 | Re: pgbench throttling latency limit |
Previous Message | Alvaro Herrera | 2014-09-10 13:37:42 | Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index |