lock_timeout GUC patch
in [PgSql]
|
From: Boszormenyi Zoltan on 15 Jan 2010 02:53 Jaime Casanova írta: > 2010/1/13 Boszormenyi Zoltan <zb(a)cybertec.at>: > >>> Your smaller patch is attached, with the above strangeness. :-) >>> >>> > > you still had to add this parameter to the postgresql.conf.sample in > the section about lock management > Attached with the required change. Thanks, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
From: Jaime Casanova on 19 Jan 2010 14:56 2010/1/15 Boszormenyi Zoltan <zb(a)cybertec.at>: > Jaime Casanova Ãrta: >> 2010/1/13 Boszormenyi Zoltan <zb(a)cybertec.at>: >> >>>> Your smaller patch is attached, with the above strangeness. :-) >>>> >>>> ok, the patch is more simpler than before and seems to be doing things right... it passes regression tests and my own tests... i think is ready for a commiter to look at it -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL AsesorÃa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Boszormenyi Zoltan on 19 Jan 2010 15:15 Jaime Casanova írta: > 2010/1/15 Boszormenyi Zoltan <zb(a)cybertec.at>: > >> Jaime Casanova írta: >> >>> 2010/1/13 Boszormenyi Zoltan <zb(a)cybertec.at>: >>> >>> >>>>> Your smaller patch is attached, with the above strangeness. :-) >>>>> >>>>> >>>>> > > ok, the patch is more simpler than before and seems to be doing things right... > it passes regression tests and my own tests... > > i think is ready for a commiter to look at it > Thanks very much for your review. :) -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 19 Jan 2010 15:19 Boszormenyi Zoltan escribi�: > May I change the interface of XactLockTableWait() > and MultiXactIdWait()? Not the return value, only the number > of parameters. E.g. with the relation name, like in the attached > patch. This solves the problem of bad error messages... > What do you think? We already present such locks as being on transaction id such-and-such, not on relations. IMHO the original wording (waiting on transaction NNN) is okay; you don't need to fool around with passing around a relation name (which is misleading anyway). If you want to provide a friendlier way to display tuple locks, that's okay but it's a separate patch. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 19 Jan 2010 18:40
Boszormenyi Zoltan <zb(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |