| Lists: | pgsql-hackers |
|---|
| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch |
| Date: | 2013-08-02 08:00:03 |
| Message-ID: | 51FB6703.9090801@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
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.
The attached patch against master includes an isolationtester spec to
demonstrate this issue and a proposed fix. Builds with the fix applied
pass "make check" and isolationtester "make installcheck".
To reach this point you need to apply the patch in
http://www.postgresql.org/message-id/51FB4305.3070600@2ndquadrant.com
first, otherwise you'll get stuck there and won't touch the code changed
in this patch.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Add-noWait-param-to-EvalPlanQualFetch.patch | text/x-patch | 7.2 KB |
| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch |
| Date: | 2014-01-31 21:28:08 |
| Message-ID: | 20140131212808.GR19957@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
On Fri, Aug 2, 2013 at 04:00:03PM +0800, 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.
>
> The attached patch against master includes an isolationtester spec to
> demonstrate this issue and a proposed fix. Builds with the fix applied
> pass "make check" and isolationtester "make installcheck".
>
> To reach this point you need to apply the patch in
> http://www.postgresql.org/message-id/51FB4305.3070600@2ndquadrant.com
> first, otherwise you'll get stuck there and won't touch the code changed
> in this patch.
The above looks like a legitimate patch that was not applied:
http://www.postgresql.org/message-id/51FB6703.9090801@2ndquadrant.com
The patch mentioned in the text above was applied, I think.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch |
| Date: | 2014-02-03 06:31:11 |
| Message-ID: | 52EF37AF.10308@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
On 02/01/2014 05:28 AM, Bruce Momjian wrote:
> On Fri, Aug 2, 2013 at 04:00:03PM +0800, 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.
>>
>> The attached patch against master includes an isolationtester spec to
>> demonstrate this issue and a proposed fix. Builds with the fix applied
>> pass "make check" and isolationtester "make installcheck".
>>
>> To reach this point you need to apply the patch in
>> http://www.postgresql.org/message-id/51FB4305.3070600@2ndquadrant.com
>> first, otherwise you'll get stuck there and won't touch the code changed
>> in this patch.
>
> The above looks like a legitimate patch that was not applied:
>
> http://www.postgresql.org/message-id/51FB6703.9090801@2ndquadrant.com
>
> The patch mentioned in the text above was applied, I think.
The first patch, linked to in text, was commited as
706f9dd914c64a41e06b5fbfd62d6d6dab43eeb8.
I can't see the second in the history either. It'd be good to get it
committed, though the issue is obviously not causing any great outcry.
It was detected when testing a high-rate queueing system in PostgreSQL.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch |
| Date: | 2014-05-31 14:09:36 |
| Message-ID: | 20140531140936.GC4286@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
Hi,
On 2014-01-31 16:28:08 -0500, Bruce Momjian wrote:
> On Fri, Aug 2, 2013 at 04:00:03PM +0800, 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.
> >
> > The attached patch against master includes an isolationtester spec to
> > demonstrate this issue and a proposed fix. Builds with the fix applied
> > pass "make check" and isolationtester "make installcheck".
> >
> > To reach this point you need to apply the patch in
> > http://www.postgresql.org/message-id/51FB4305.3070600@2ndquadrant.com
> > first, otherwise you'll get stuck there and won't touch the code changed
> > in this patch.
>
> The above looks like a legitimate patch that was not applied:
>
> http://www.postgresql.org/message-id/51FB6703.9090801@2ndquadrant.com
>
> The patch mentioned in the text above was applied, I think.
Craig: I think you should add this to the next CF. Seems like something
we should fix, but which isn't super urgent. But when the skip locked
stuff comes in it'll be more relevant.
Might also need a rebase.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services