lock_timeout GUC patch
in [PgSql]
|
From: Robert Haas on 20 Jan 2010 10:42 2010/1/20 Boszormenyi Zoltan <zb(a)cybertec.at>: > Attached with the proposed modification to lift the portability concerns. > Fixed the missing check for get_rel_name() and one typo ("transation") > Introduced checks for semtimedop() and sem_timedwait() in configure.in > and USE_LOCK_TIMEOUT in port.h depending on > HAVE_DECL_SEMTIMEDOP || HAVE_DECL_SEM_TIMEDWAIT || WIN32 > Introduced assign_lock_timeout() GUC validator function that allows > setting the value only from the wired-in-default (0) or from SET statements. > > Comments? I think that it is a very bad idea to implement this feature in a way that is not 100% portable. ....Robert -- 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 20 Jan 2010 11:03 Robert Haas <robertmhaas(a)gmail.com> writes: > 2010/1/20 Boszormenyi Zoltan <zb(a)cybertec.at>: >> Attached with the proposed modification to lift the portability concerns. > I think that it is a very bad idea to implement this feature in a way > that is not 100% portable. Agreed, this is not acceptable. If there were no possible way to implement the feature portably, we *might* consider doing it like this. But I think more likely it'd get rejected anyway. When there is a clear path to a portable solution, it's definitely not going to fly to submit a nonportable one. 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
From: Boszormenyi Zoltan on 21 Jan 2010 02:53 Tom Lane �rta: > Robert Haas <robertmhaas(a)gmail.com> writes: > >> 2010/1/20 Boszormenyi Zoltan <zb(a)cybertec.at>: >> >>> Attached with the proposed modification to lift the portability concerns. >>> > > >> I think that it is a very bad idea to implement this feature in a way >> that is not 100% portable. >> > > Agreed, this is not acceptable. If there were no possible way to > implement the feature portably, we *might* consider doing it like this. > But I think more likely it'd get rejected anyway. When there is a > clear path to a portable solution, it's definitely not going to fly > to submit a nonportable one. > > regards, tom lane > OK, I will implement it using setitimer(). It may not reach 8.5 though, when will this last Commitfest end? 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/ -- 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: Robert Haas on 21 Jan 2010 09:17 2010/1/21 Boszormenyi Zoltan <zb(a)cybertec.at>: > Tom Lane írta: >> Robert Haas <robertmhaas(a)gmail.com> writes: >>> I think that it is a very bad idea to implement this feature in a way >>> that is not 100% portable. >> >> Agreed, this is not acceptable. If there were no possible way to >> implement the feature portably, we *might* consider doing it like this. >> But I think more likely it'd get rejected anyway. When there is a >> clear path to a portable solution, it's definitely not going to fly >> to submit a nonportable one. > > OK, I will implement it using setitimer(). > It may not reach 8.5 though, when will this last Commitfest end? The CommitFest ends 2/15, but that's not really the relevant metric. Patches will be marked Returned with Feedback if they are not updated within 4-5 days of the time they were last reviewed, or more aggressively as we get towards the end. Also, if a patch needs a major rewrite, it should be marked Returned with Feedback and resubmitted for this CommitFest. It sounds like this patch meets that criterion; in addition, Tom has expressed concerns that this might be something that should be committed early in the release cycle rather than at the very end. ....Robert -- 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 21 Jan 2010 09:41
Hi, Robert Haas �rta: > 2010/1/21 Boszormenyi Zoltan <zb(a)cybertec.at>: > >> Tom Lane �rta: >> >>> Robert Haas <robertmhaas(a)gmail.com> writes: >>> >>>> I think that it is a very bad idea to implement this feature in a way >>>> that is not 100% portable. >>>> >>> Agreed, this is not acceptable. If there were no possible way to >>> implement the feature portably, we *might* consider doing it like this. >>> But I think more likely it'd get rejected anyway. When there is a >>> clear path to a portable solution, it's definitely not going to fly >>> to submit a nonportable one. >>> >> OK, I will implement it using setitimer(). >> It may not reach 8.5 though, when will this last Commitfest end? >> > > The CommitFest ends 2/15, but that's not really the relevant metric. > Patches will be marked Returned with Feedback if they are not updated > within 4-5 days of the time they were last reviewed, or more > aggressively as we get towards the end. Also, if a patch needs a > major rewrite, it should be marked Returned with Feedback and > resubmitted for this CommitFest. It sounds like this patch meets that > criterion; in addition, Tom has expressed concerns that this might be > something that should be committed early in the release cycle rather > than at the very end. > > ...Robert > Thanks. So it means that this patch will considered for 9.1. I would like a mini-review on the change I made in the latest patch by introducing the validator function. Is it enough to check for (source == PGC_S_DEFAULT || source == PGC_S_SESSION) to ensure only interactive sessions can get lock timeouts? This way autovacuum, replication and any other internal processes get proper behaviour, i.e. the setting from postgresql.conf is ignored and locks don't timeout for them. Which other PGC_S_* settings can or must be enabled? Best regards, 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |