On Thu, Oct 5, 2023 at 2:29 PM Dilip Kumar <
dilipbalaut@gmail.com> wrote:
>
> On Thu, Oct 5, 2023 at 1:48 AM Amit Kapila <
amit.kapila16@gmail.com> wrote:
> >
> > On Tue, Oct 3, 2023 at 9:58 AM Bharath Rupireddy
> > <
bharath.rupireddyforpostgres@gmail.com> wrote:
> > >
> > > On Fri, Sep 29, 2023 at 5:27 PM Hayato Kuroda (Fujitsu)
> > > <
kuroda.hayato@fujitsu.com> wrote:
> > > >
> > > > Yeah, the approach enforces developers to check the decodability.
> > > > But the benefit seems smaller than required efforts for it because the function
> > > > would be used only by pg_upgrade. Could you tell me if you have another use case
> > > > in mind? We may able to adopt if we have...
> > >
> > > I'm attaching 0002 patch (on top of v45) which implements the new
> > > decodable callback approach that I have in mind. IMO, this new
> > > approach is extensible, better than the current approach (hard-coding
> > > of certain WAL records that may be generated during pg_upgrade) taken
> > > by the patch, and helps deal with the issue that custom WAL resource
> > > managers can have with the current approach taken by the patch.
> > >
> >
> > Today, I discussed this problem with Andres at PGConf NYC and he
> > suggested as following. To verify, if there is any pending unexpected
> > WAL after shutdown, we can have an API like
> > pg_logical_replication_slot_advance() which will simply process
> > records without actually sending anything downstream.
>
> So I assume in each lower-level decode function (e.g. heap_decode() )
> we will add the check that if we are checking the WAL for an upgrade
> then from that level we will return true or false based on whether the
> WAL is decodable or not. Is my understanding correct?
>
Yes, this is one way to achive but I think this will require changing return value of many APIs. Can we somehow just get this via LogicalDecodingContext or some other way at the caller by allowing to set some variable at required places?