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 | Resend email |
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 |
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) |