Re: Too coarse predicate locks granularity for B+ tree indexes

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Rinat Shigapov <rinatshigapov(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Too coarse predicate locks granularity for B+ tree indexes
Date: 2023-02-07 10:29:50
Message-ID: f5ddc5fc7ef9fc3a8469bc7e0ee68e89ea8f1e2a.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Tue, 2023-02-07 at 16:23 +0600, Rinat Shigapov wrote:
> I have a concurrent testsuite that runs 14 test cases. Each test case operates
> on a disjoint set of records, doesn't retry transactions and is run under
> 'serializable' isolation level. The test data is small and likely fits within
> a single tuple page.
>
> When I finished the test suite I was surprised that PostgreSQL 14.5 returns
> serialization failure on every test suite run.

This is no question for the hackers list; redirecting to general.

That behavior sounds perfectly normal to me: if everything is in a single
page, PostgreSQL probably won't use an index scan. With a sequential scan,
the predicate lock will be on the whole table. So you should expect
serialization failures. This is well documented.

Perhaps you should use a more realistic test case with a reasonable
amount of data.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Sebastien Flaesch 2023-02-07 10:43:06 Re: Get the sequence name corresponding to a GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY column
Previous Message Rinat Shigapov 2023-02-07 10:23:54 Too coarse predicate locks granularity for B+ tree indexes

Browse pgsql-hackers by date

  From Date Subject
Next Message Drouvot, Bertrand 2023-02-07 10:36:48 Re: Minimal logical decoding on standbys
Previous Message Dean Rasheed 2023-02-07 10:28:42 Re: MERGE ... WHEN NOT MATCHED BY SOURCE