Re: lock_timeout GUC patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Subject: Re: lock_timeout GUC patch
Date: 2010-01-21 15:07:23
Message-ID: 603c8f071001210707v4e345ab2o917ed22f1c9fd029@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan <zb(at)cybertec(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2010-01-21 15:15:38 Re: 8.5 vs. 9.0
Previous Message Robert Haas 2010-01-21 15:00:36 Re: quoting psql varible as identifier