From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_repack vs. running logical/physical replication |
Date: | 2024-01-30 07:27:48 |
Message-ID: | 5d541112fcf04486228714f200ed2b596bbb15f3.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)mantzios(at)cloud(dot)gatewaynet(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gabriel Guillem Barceló Soteras | 2024-01-30 07:46:31 | Re: Setup load balancing using HAProxy |
Previous Message | Ron Johnson | 2024-01-30 01:00:53 | Re: pg_repack vs. running logical/physical replication |