Re: Should the nbtree page split REDO routine's locking work more like the locking on the primary? - Mailing list pgsql-hackers

From Andrey M. Borodin
Subject Re: Should the nbtree page split REDO routine's locking work more like the locking on the primary?
Date
Msg-id 1EB83B5A-B243-4278-AE8F-5F8C4DB9B15F@yandex-team.ru
Whole thread Raw
In response to Re: Should the nbtree page split REDO routine's locking work more like the locking on the primary?  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers

> 8 авг. 2020 г., в 03:28, Peter Geoghegan <pg@bowt.ie> написал(а):
>
> On Thu, Aug 6, 2020 at 7:00 PM Peter Geoghegan <pg@bowt.ie> wrote:
>> On Thu, Aug 6, 2020 at 6:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> +1 for making this more like what happens in original execution ("on the
>>> primary", to use your wording).  Perhaps what you suggest here is still
>>> not enough like the original execution, but it sounds closer.
>>
>> It won't be the same as the original execution, exactly -- I am only
>> thinking of holding on to same-level page locks (the original page,
>> its new right sibling, and the original right sibling).
>
> I pushed a commit that reorders the lock acquisitions within
> btree_xlog_unlink_page() -- they're now consistent with _bt_split()
> (at least among sibling pages involved in the page split).

Sounds great, thanks!

Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: get rid of distprep?
Next
From: "Andrey M. Borodin"
Date:
Subject: Re: [PATCH] Covering SPGiST index