Re: pg_repack vs. running logical/physical replication - Mailing list pgsql-admin

From Laurenz Albe
Subject Re: pg_repack vs. running logical/physical replication
Date
Msg-id 5d541112fcf04486228714f200ed2b596bbb15f3.camel@cybertec.at
Whole thread Raw
In response to Re: pg_repack vs. running logical/physical replication  (Ron Johnson <ronljohnsonjr@gmail.com>)
List 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 by date:

Previous
From: Ron Johnson
Date:
Subject: Re: pg_repack vs. running logical/physical replication
Next
From: Gabriel Guillem Barceló Soteras
Date:
Subject: Re: Setup load balancing using HAProxy