Re: lock_timeout GUC patch

Boszormenyi Zoltan <zb(at)cybertec(dot)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