Re: lock_timeout GUC patch

Boszormenyi Zoltan <zb@cybertec.at> writes:
> [ 5-pg85-locktimeout-14-ctxdiff.patch ]

I took a quick look at this.  I am not qualified to review the Win32
implementation of PGSemaphoreTimedLock, but I am afraid that both of
the other ones are nonstarters on portability grounds.  sem_timedwait()
and semtimedop() do not appear in the Single Unix Spec, which is our
usual reference for what is portable.  In particular I don't see either
of them on OS X or HPUX.  I suspect that applying this patch would
immediately break every platform except Linux.

I also concur with Alvaro's feeling that the changes to XactLockTableWait()
and MultiXactIdWait() are inappropriate.  There is no reason to assume
that there is always a relevant relation for waits performed with those
functions.  (In the same line, not all of the added error reports are
careful about what happens if get_rel_name fails.)

A larger question, which I think has been raised before but I have not
seen a satisfactory answer for, is whether the system will behave sanely
at all with this type of patch in place.  I don't really think that a
single lock timeout applicable to every possible reason to wait is going
to be nice to use; and I'm afraid in some contexts it could render
things completely nonfunctional.  (In particular I think that Hot
Standby is fragile enough already without this.)  It seems particularly
imprudent to make such a thing USERSET, implying that any clueless or
malicious user could set it in a way that would cause problems, if there
are any to cause.
        regards, tom lane