Re: [PoC] pg_upgrade: allow to upgrade publisher node
От | Dilip Kumar |
---|---|
Тема | Re: [PoC] pg_upgrade: allow to upgrade publisher node |
Дата | |
Msg-id | CAFiTN-tNXPsq=4-L86OBezCzheSxmF6HuRw06rzFLHJxVUrgrw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PoC] pg_upgrade: allow to upgrade publisher node (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Список | pgsql-hackers |
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. I did not see the patch, but I like this approach better. I mean this approach does not check what record types are generated during updagre instead this directly targets that after the confirmed_flush_lsn what type of records shouldn't be generated. So if rmgr says that after commit_flush_lsn no decodable record was generated then we are safe to upgrade that slot. So this seems an expandable approach. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: