Re: SKIP LOCKED DATA (work in progress)

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

In response to

Browse pgsql-hackers by date

  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