Re: Questions on logical replication

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Koen De Groote <kdg(dot)dev(at)gmail(dot)com>
Cc: PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Questions on logical replication
Date: 2024-06-07 15:15:56
Message-ID: 490e8a5c-f1f5-40fe-8243-f1c8c18d03f2@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 6/6/24 15:19, Koen De Groote wrote:
> I'll give them a read, though it might take a few weekends
>
> Meanwhile, this seems to be what I'm looking for:
>
> From
> https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION-SLOTS <https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION-SLOTS>
>
> " Replication slots provide an automated way to ensure that the primary
> does not remove WAL segments until they have been received by all
> standbys, and that the primary does not remove rows which could cause a
> recovery conflict
> <https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT> even when the standby is disconnected."
>
> I'm reading that as: "if there is a replication slot, if the standby is
> disconnected, WAL is kept"
>
> And if we know WAL is kept in the "pg_wal" directory, that sounds like
> it could slowly but surely fill up disk space.
>
>
> But again, I'll give them a read. I've read all of logical replication
> already, and I feel like I didn't get my answer there.

It would be a good idea to provide an a fairly specific outline of what
you are trying to achieve, then it would be easier for folks to offer
suggestions on what to do or not to do.

>
> Thanks for the help
>
>
> Regards,
> Koen De Groote

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2024-06-07 15:33:08 Re: PG 14 pg_basebackup accepts --compress=server-zst option
Previous Message David G. Johnston 2024-06-07 14:42:31 PG16.1 security breach?