Re: Should the nbtree page split REDO routine's locking work more like the locking on the primary?
| От | Peter Geoghegan |
|---|---|
| Тема | Re: Should the nbtree page split REDO routine's locking work more like the locking on the primary? |
| Дата | |
| Msg-id | CAH2-Wz=ukRBOFjTkmHJGBr9zzHaSwfYP4_JN6R3mq2=SFv5MYg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Should the nbtree page split REDO routine's locking work more like the locking on the primary? (Peter Geoghegan <pg@bowt.ie>) |
| Ответы |
Re: Should the nbtree page split REDO routine's locking work more like the locking on the primary?
|
| Список | pgsql-hackers |
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).
Thanks
--
Peter Geoghegan
В списке pgsql-hackers по дате отправления: