Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order
Date: 2009-10-26 17:58:14
Message-ID: 407d949e0910261058v476ac5f4id4c84724af0dc89e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 25, 2009 at 7:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> All that we have to do to fix the first one is to put the LockRows node
> below the Limit node instead of above it.  The solution for the second
> one is to also put LockRows underneath the Sort node, and to regard its
> output as unsorted so that a Sort node will certainly be generated.
> (This in turn implies that we should prefer the cheapest-total plan
> for the rest of the query.)

I'm not following how this would work. Would it mean that every record
would end up being locked?

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-10-26 18:01:57 Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order
Previous Message Robert Haas 2009-10-26 17:42:52 Re: Scaling up deferred unique checks and the after trigger queue