Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
От | Masahiko Sawada |
---|---|
Тема | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |
Дата | |
Msg-id | CAD21AoBS=nOM1-EP0H-zVTvjF4BJLfbKTtFVb0NnjQ=Y-9u=WQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
|
Список | pgsql-hackers |
On Thu, Jul 17, 2025 at 2:36 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > What if we make DROP SUBSCRIPTION fail if it can lead to removal of > the last slot on publisher and allow DROP to succeed when the > subscription's drop_slot_force (a new subscription option) is set? > Now, users can still be allowed to Drop the subscription, if it > disassociates the subscription from the slot by using method explained > in docs [1] (See Notes section). Similarly when a user is trying to > drop the last logical slot via pg_drop_replication_slot, we will allow > it only with the force option. This should ensure that the user is > aware of the consequences of dropping the last slot. I think even if we prevent the last logical replication that was used for logical replication from being removed, the primary would continue to accumulate WALs for that slot. I think it actually doesn't need to hold WALs and dead catalog tuples in order to keep the effective WAL level 'logical'. So probably it's better to 'reset' the slot, meaning to clear the last slot's restart_lsn and catalog_xmin? Using such option would work in interactive case but I'm not sure how works in tools like shell scripts. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: