Re: Minimal logical decoding on standbys
От | Drouvot, Bertrand |
---|---|
Тема | Re: Minimal logical decoding on standbys |
Дата | |
Msg-id | efb77c85-9263-1889-4593-0988ad23fd8c@amazon.com обсуждение исходный текст |
Ответ на | Re: Minimal logical decoding on standbys (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Minimal logical decoding on standbys
|
Список | pgsql-hackers |
Hi, On 10/28/21 11:07 PM, Andres Freund wrote: > Hi, > > On 2021-10-28 16:24:22 -0400, Robert Haas wrote: >> On Wed, Oct 27, 2021 at 2:56 AM Drouvot, Bertrand <bdrouvot@amazon.com> wrote: >>> So you have in mind to check for XLogLogicalInfoActive() first, and if true, then open the relation and call >>> RelationIsAccessibleInLogicalDecoding()? >> I think 0001 is utterly unacceptable. We cannot add calls to >> table_open() in low-level functions like this. Suppose for example >> that _bt_getbuf() calls _bt_log_reuse_page() which with 0001 applied >> would call get_rel_logical_catalog(). _bt_getbuf() will have acquired >> a buffer lock on the page. The idea that it's safe to call >> table_open() while holding a buffer lock cannot be taken seriously. > Yes - that's pretty clearly a deadlock hazard. It shouldn't too hard to fix, I > think. Possibly a bit more verbose than nice, but... > > Alternatively we could propagate the information whether a relcache entry is > for a catalog from the table to the index. Then we'd not need to change the > btree code to pass the table down. +1 for the idea of propagating to the index. If that sounds good to you too, I can try to have a look at it. Thanks Robert and Andres for the feedbacks you have done on the various sub-patches. I've now in mind to work sub patch by sub patch (starting with 0001 then) and move to the next one once we agree that the current one is "ready". I think that could help us to get this new feature moving forward more "easily", what do you think? Thanks Bertrand
В списке pgsql-hackers по дате отправления: