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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Add GUCs for predicate lock promotion thresholds
Date: 2017-01-05 18:19:34
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> ilmari(at)ilmari(dot)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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2017-01-05 18:54:56 Re: ALTER SYSTEM for pg_hba.conf
Previous Message Tom Lane 2017-01-05 18:15:39 Re: [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.