Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sándor Miglécz <sandor(at)cybertec(dot)at>
Subject: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Date: 2009-10-04 00:51:33
Message-ID: 603c8f070910031751v49e2195fub702dde095a97b86@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Sep 27, 2009 at 1:31 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> As to #3, that's obviously gotta be fixed.  If we're to further
> consider this patch for this CommitFest, that fixing needs to happen
> pretty soon.

Since it has been 6 days since I posted this and more than 2 weeks
since the problem was found, I am moving this patch to returned with
feedback.

If it is resubmitted for the next CommitFest, please change the
subject line to something like "lock_timeout GUC" so that it will
match what the patch actually does. I think we have consensus that a
GUC is the way to go here, and the feature seems to have enough
support. Investigating a set-GUC-for-this-statement-only feature also
seems to have some support, but that would be a separate patch and not
necessary to satisfy the OP's use case.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-10-04 00:54:50 Re: CommitFest 2009-09, two weeks on
Previous Message Mark Kirkwood 2009-10-03 23:22:03 Re: Lock Wait Statistics (next commitfest)