lock_timeout GUC patch
in [PgSql]
|
From: Robert Haas on 21 Jan 2010 10:07 On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan <zb(a)cybertec.at> wrote: > Thanks. So it means that this patch will considered for 9.1. Yeah, I think that's best. > 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? I'm not sure that I know how this should work, but that approach seems a little strange to me. Why would we not allow PGC_S_USER, for example? Also, does this mean that if the setting is present in postgresql.conf, autovacuum will fail to start? It seems to me that rather than trying to restrict the PGC_S_* types for which this can be set, we should be trying to make the "internal processes" ignore the GUC altogether. I'm not sure if there's a clean way to do that, though. ....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 21 Jan 2010 10:59 Robert Haas <robertmhaas(a)gmail.com> writes: > On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan <zb(a)cybertec.at> wrote: >> 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? > I'm not sure that I know how this should work, but that approach seems > a little strange to me. Why would we not allow PGC_S_USER, for > example? Why is this a good idea at all? I can easily see somebody feeling that he'd like autovacuums to fail rather than block on locks for a long time, for example. 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: Robert Haas on 21 Jan 2010 11:00 On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan <zb(a)cybertec.at> wrote: >>> 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? > >> I'm not sure that I know how this should work, but that approach seems >> a little strange to me. Why would we not allow PGC_S_USER, for >> example? > > Why is this a good idea at all? I can easily see somebody feeling that > he'd like autovacuums to fail rather than block on locks for a long > time, for example. What I can see happening is someone setting this GUC in postgresql.conf and then being surprised that it applied to thinks like walreceiver and autovacuum, in addition to user queries. Are we even sure that that code would all behave sanely with this behavior? ....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 21 Jan 2010 11:08 Robert Haas <robertmhaas(a)gmail.com> writes: > On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Why is this a good idea at all? �I can easily see somebody feeling that >> he'd like autovacuums to fail rather than block on locks for a long >> time, for example. > What I can see happening is someone setting this GUC in > postgresql.conf and then being surprised that it applied to thinks > like walreceiver and autovacuum, in addition to user queries. Are we > even sure that that code would all behave sanely with this behavior? No, I'm not sure, as I said before ;-). But a 100%-arbitrary restriction like "it doesn't apply to background processes" will not make it noticeably safer. There is very damn little code that only executes in background and never anywhere else. 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 11:09
Tom Lane �rta: > Robert Haas <robertmhaas(a)gmail.com> writes: > >> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan <zb(a)cybertec.at> wrote: >> >>> 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? >>> > > >> I'm not sure that I know how this should work, but that approach seems >> a little strange to me. Why would we not allow PGC_S_USER, for >> example? >> > > Why is this a good idea at all? I can easily see somebody feeling that > he'd like autovacuums to fail rather than block on locks for a long > time, for example. > You expressed stability concerns coming from this patch. Were these concerns because of locks timing out making things fragile or because of general feelings about introducing such a patch at the end of the release cycle? I was thinking about the former, hence this modification. 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 |