|From:||ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)|
|Subject:||[PATCH] Add GUCs for predicate lock promotion thresholds|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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.
|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)|