From: | Thomas Munro <munro(at)ip9(dot)org> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
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-06 10:40:00 |
Message-ID: | CADLWmXWxCBV4dnW6eOyiSt=7hRvnxpgfDLy+TFRLPuOEWxKpeA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 31 August 2014 01:36, Thomas Munro <munro(at)ip9(dot)org> wrote:
> On 28 August 2014 00:25, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>> Thomas Munro wrote:
>>> I haven't yet figured out how to get get into a situation where
>>> heap_lock_updated_tuple_rec waits.
>>
>> Well, as I think I said in the first post I mentioned this, maybe there
>> is no such situation. In any case, like the EvalPlanQualFetch issue, we
>> can fix it later if we find it.
>
> I finally came up with a NOWAIT spec that reaches
> heap_lock_updated_rec and then blocks. I can't explain why exactly...
> but please see attached. The fix seems fairly straightforward. Do
> you think I should submit an independent patch to fix this case (well
> there are really two cases, since there is a separate multixact path)
> for the existing NOWAIT support and then tackle the SKIP LOCKED
> equivalent separately?
Oops, that isolation wasn't right, please disregard. Unless you think
this obscure case needs to be addressed before the SKIP LOCKED patch
can be committed, I will investigate it separately and maybe submit
something to a future commitfest.
Best regards,
Thomas Munro
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2014-09-06 13:12:43 | Re: PL/pgSQL 1.2 |
Previous Message | Marko Tiikkaja | 2014-09-06 09:12:43 | Re: PL/pgSQL 1.2 |