Re: pg_repack vs. running logical/physical replication
От | Laurenz Albe |
---|---|
Тема | Re: pg_repack vs. running logical/physical replication |
Дата | |
Msg-id | 5d541112fcf04486228714f200ed2b596bbb15f3.camel@cybertec.at обсуждение исходный текст |
Ответ на | Re: pg_repack vs. running logical/physical replication (Ron Johnson <ronljohnsonjr@gmail.com>) |
Список | pgsql-admin |
On Mon, 2024-01-29 at 20:00 -0500, Ron Johnson wrote: > On Mon, Jan 29, 2024 at 2:27 PM Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com> wrote: > > Στις 29/1/24 16:56, ο/η Dirk Krautschick έγραψε: > > > 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? Yes, but pg_repack doesn't change the table definition or contents, so it should be able to work with logical replication. I guess the question is if pg_repack WAL logs everything correctly. If yes, I'd assume that it should work as well with logical replication as VACUUM (FULL). I guess you'd have to try it out, perhaps with a concurrent pgbench run. Yours, Laurenz Albe
В списке pgsql-admin по дате отправления: