Re: lock_timeout GUC patch

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: lock_timeout GUC patch
Дата
Msg-id 603c8f071001210800h31bd0d8eg49f51b45f582f949@mail.gmail.com
обсуждение исходный текст
Ответ на Re: lock_timeout GUC patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: lock_timeout GUC patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan <zb@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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: lock_timeout GUC patch
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Git out of sync vs. CVS