pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedpg_repack vs. running logical/physical replication
4+ messages / 4 participants
[nested] [flat]
* pg_repack vs. running logical/physical replication
@ 2024-01-29 14:56 Dirk Krautschick <dirk.krautschick@googlemail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Dirk Krautschick @ 2024-01-29 14:56 UTC (permalink / raw)
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>
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 :-)
Thanks and best regards
Dirk
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pg_repack vs. running logical/physical replication
@ 2024-01-29 19:27 Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
parent: Dirk Krautschick <dirk.krautschick@googlemail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Achilleas Mantzios @ 2024-01-29 19:27 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
Στις 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?
Why would you want to fill your repl slots (if any) by suspending
physical replication while pg_repack runs?
I would advise reading about pg_repack and/or testing yourself to see
how it works.
>
>
> Thanks and best regards
>
>
> Dirk
>
>
>
--
Achilleas Mantzios
IT DEV - HEAD
IT DEPT
Dynacom Tankers Mgmt (as agents only)
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pg_repack vs. running logical/physical replication
@ 2024-01-30 01:00 Ron Johnson <ronljohnsonjr@gmail.com>
parent: Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
0 siblings, 1 reply; 4+ messages in thread
From: Ron Johnson @ 2024-01-30 01:00 UTC (permalink / raw)
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>
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.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pg_repack vs. running logical/physical replication
@ 2024-01-30 07:27 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Ron Johnson <ronljohnsonjr@gmail.com>
0 siblings, 0 replies; 4+ messages in thread
From: Laurenz Albe @ 2024-01-30 07:27 UTC (permalink / raw)
To: Ron Johnson <ronljohnsonjr@gmail.com>; Pgsql-admin <pgsql-admin@lists.postgresql.org>
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
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-01-30 07:27 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-01-29 14:56 pg_repack vs. running logical/physical replication Dirk Krautschick <dirk.krautschick@googlemail.com>
2024-01-29 19:27 ` Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
2024-01-30 01:00 ` Ron Johnson <ronljohnsonjr@gmail.com>
2024-01-30 07:27 ` Laurenz Albe <laurenz.albe@cybertec.at>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox