Re: pg_repack vs. running logical/physical replication

Поиск
Список
Период
Сортировка
От Ron Johnson
Тема Re: pg_repack vs. running logical/physical replication
Дата
Msg-id CANzqJaAXyw3bD4xi_UmOc2zFjaY7be1Tuf1-xfoqFXKaQ=kigQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_repack vs. running logical/physical replication  (Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>)
Ответы Re: pg_repack vs. running logical/physical replication  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список pgsql-admin
On Mon, Jan 29, 2024 at 2:27 PM Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com> wrote:
Στις 29/1/24 16:56, ο/η Dirk Krautschick έγραψε:
> Hi,
>
>
> is there any good reason to cut of logical and/or physical replication
> for the time pg_repack (please no discussion about pg_repack at all,
> customer request, his idea, his strict wish) is running? I am not so
> deep into how pg_repack is running things but as the docs are saying
> it could affect hard at least the publications for logrep. Haven't
> tested it yet and just hopeing for a quick answer here :-)

Why should logical replication break?
 
LR gets fiddly, and needs manual attention when DDL changes are applied, no?

For example, we're not using LR to migrate from 9.6 to 14 because the application regularly makes DDL modifications (inheritance partitioning: dropping old tables, creating new ones, and dropping/recreating the triggers; 71 of them).  I don't trust my ability to catch all those changes, and apply them to the new server.

Why would you want to fill your repl slots (if any) by suspending
physical replication while pg_repack runs?

Fear of corrupting the destination.
 

В списке pgsql-admin по дате отправления:

Предыдущее
От: Achilleas Mantzios
Дата:
Сообщение: Re: pg_repack vs. running logical/physical replication
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: pg_repack vs. running logical/physical replication