Re: Minimal logical decoding on standbys

From: Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>
To: "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, fabriziomello(at)gmail(dot)com, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Rahila Syed <rahila(dot)syed(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Minimal logical decoding on standbys
Date: 2022-07-01 20:03:22
Message-ID: CALtqXTc6k5eVAUPhE5v4de+_vkG8U2VUNss_9_XWhyvjFtAn9w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 30, 2022 at 1:49 PM Drouvot, Bertrand <bdrouvot(at)amazon(dot)com>
wrote:

> Hi,
>
> On 2/25/22 10:34 AM, Drouvot, Bertrand wrote:
> > 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(at)amazon(dot)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
> >
> I'm going to re-create a CF entry for it, as:
>
> - It seems there is a clear interest for the feature (given the time
> already spend on it and the number of people that worked on)
>
> - I've in mind to resume working on it
>
> I have already done some research on that, I can definitely look at it.

> - It would give more visibility in case others want to jump in
>
> Hope that makes sense,
>
> Thanks,
>
> Bertrand
>
>

--
Ibrar Ahmed

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-07-01 20:14:23 Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Previous Message Justin Pryzby 2022-07-01 19:18:41 Re: ccache, MSVC, and meson