[PATCH] Add GUCs for predicate lock promotion thresholds

From: ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)
To: pgsql-hackers(at)postgresql(dot)org
Subject: [PATCH] Add GUCs for predicate lock promotion thresholds
Date: 2016-12-14 14:16:39
Message-ID: d8joa0eh9yw.fsf@dalvik.ping.uio.no
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Hi hackers,

I have a workload using SSI that causes a lot of tuple predicate to be
promoted to page locks. This causes a lot of spurious serialisability
errors, since the promotion happens at once three tuples on a page are
locked, and the affected tables have 30-90 tuples per page.

PredicateLockPromotionThreshold() has the following comment:

* TODO SSI: We should do something more intelligent about what the
* thresholds are, either making it proportional to the number of
* tuples in a page & pages in a relation, or at least making it a
* GUC.

Attached is a patch that does the "at least" part of this.

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.

Cheers,

Ilmari

Attachment Content-Type Size
0001-Add-GUCs-for-predicate-lock-promotion-thresholds.patch text/x-diff 7.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2016-12-14 14:26:03 Re: [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]
Previous Message Fujii Masao 2016-12-14 14:10:30 Re: Re: [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)