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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> As to #1, personally, I think it's quite useful. The arguments that
> have been made that lock_timeout is redundant with statement_timeout
> don't seem to me to have much merit.
> ...
> As to #2, I was initially thinking dedicated syntax would be better
> because I hate "SET guc = value; do thing; SET guc = previous_value;".
> But now I'm realizing that there's every reason to suppose that
> SELECT FOR UPDATE will not be the only case where we want to do this -
> so I think a GUC is the only reasonable choice.

Yeah. I believe that a reasonable argument can be made for being able
to limit lock waits separately from total execution time, but it is
*not* clear to me why SELECT FOR UPDATE per-tuple waits should be the
one single solitary place where that is useful. IIRC I was against the
SELECT FOR UPDATE NOWAIT syntax to begin with, because of exactly this
same reasoning.

> But that having been
> said, I think some kind of syntax to set a GUC for just one statement
> would be way useful, per discussions downthread. However, that seems
> like it can and should be a separate pach.

Worth looking at. We do already have SET LOCAL, and the per-function
GUC settings, but that may not be sufficient.

regards, tom lane