On Fri, Sep 22, 2023 at 12:11 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > Yeah, both by tests and manually verifying the WAL records. Basically, > we need to care about records that could be generated by background > processes like checkpointer/bgwriter or can be generated during system > table scans. You may want to read my latest email for a summary on how > we reached at this design choice [1]. > > [1] - > https://www.postgresql.org/message-id/CAA4eK1JVKZGRHLOEotWi%2Be%2B09jucNedqpkkc-Do4dh5FTAU%2B5w%40mail.gmail.com
+ /* Logical slots can be migrated since PG17. */ + if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1600) + { Why can't the patch allow migration of logical replication slots from PG versions < 17 to say 17 or later? If done, it will be a main advantage of the patch since it will enable seamless major version upgrades of postgres database instances with logical replication slots. I'm looking at the changes to the postgres backend that this patch does - AFICS, it does 2 things 1) implements binary_upgrade_validate_wal_logical_end function, 2) adds an assertion that the logical slots won't get invalidated. For (1), pg_upgrade can itself can read the WAL from the old cluster to determine the logical WAL end (i.e. implement the functionality of binary_upgrade_validate_wal_logical_end ) because the xlogreader is available to FRONTEND tools. For (2), it's just an assertion and logical WAL end determining logic will anyway determine whether or not the slots are valid; if needed, the assertion can be backported. Is there anything else that stops this patch from supporting migration of logical replication slots from PG versions < 17? -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com