Re: lock_timeout GUC patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Cc: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: lock_timeout GUC patch
Date: 2010-01-19 23:40:05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2010-01-19 23:41:29 Re: Listen / Notify - what to do when the queue is full
Previous Message Devrim GÜNDÜZ 2010-01-19 23:00:16 Re: Missing docs for SR