Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
Дата
Msg-id 8545.1483640374@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
Ответы Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds  (Kevin Grittner <kgrittn@gmail.com>)
Список pgsql-hackers
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>> One thing I don't like about this patch is that if a user has increased
>> max_pred_locks_per_transaction, they need to set
>> max_pred_locks_per_relation to half of that to retain the current
>> behaviour, or they'll suddenly find themselves with a lot more relation
>> locks.  If it's possible to make a GUCs default value dependent on the
>> value of another, that could be a solution.  Otherwise, the page lock
>> threshold GUC could be changed to be expressed as a fraction of
>> max_pred_locks_per_transaction, to keep the current behaviour.

> Another option would be to have a special sentinel (e.g. -1) which is
> the default, and keeps the current behaviour.

FWIW, interdependent GUC defaults are generally unworkable.
See commit a16d421ca and the sorry history that led up to it.
I think you could make it work as a fraction, though.
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.
Следующее
От: Euler Taveira
Дата:
Сообщение: Re: [HACKERS] ALTER SYSTEM for pg_hba.conf