Subject: Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

From: Ron Johnson <[email-masked]>
Date: Sun, 24 Nov 2024 12:15:27 -0500

On Sun, Nov 24, 2024 at 12:06 PM Christophe Pettus <[email-masked]> wrote:

> > On Nov 24, 2024, at 09:03, Subhash Udata <[email-masked]> wrote:
> > When we shut down the standby, upgrade it, and then start it back up,
> will the replication automatically resume from the primary to the standby?
>
> Assuming that the standby has access to any WAL generated during the
> shutdown (either still in the primary's WAL directory, or via an archive
> using archive_command), yes.  If you are not using a WAL archive using
> archive_command, you will want to make sure your wal_keep_size parameter is
> set high enough that required WAL segments aren't recycled during the
> standby's downtime.

Doesn't the existence of a replication slot force PG to retain WAL files
when replication is broken?

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

---

From: Christophe Pettus <[email-masked]>
Date: Sun, 24 Nov 2024 11:54:52 -0800

> On Nov 24, 2024, at 09:15, Ron Johnson <[email-masked]> wrote:
> 
> Doesn't the existence of a replication slot force PG to retain WAL files when replication is broken?

It does.  I don't recall if the OP said that they were using a persistent replication slot or not; it's not as common with binary replication as with logical replication.

---

From: Ron Johnson <[email-masked]>
Date: Sun, 24 Nov 2024 16:00:08 -0500

On Sun, Nov 24, 2024 at 2:55 PM Christophe Pettus <[email-masked]> wrote:

> It does.  I don't recall if the OP said that they were using a persistent
> replication slot or not; it's not as common with binary replication as with
> logical replication.
>

Really? I wonder why people fight with configuring max_wal_size and
wal_keep_size, when replication slots do all the work for you.

---

From: Adrian Klaver <[email-masked]>
Date: Sun, 24 Nov 2024 13:58:01 -0800

On 11/24/24 13:00, Ron Johnson wrote:
> On Sun, Nov 24, 2024 at 2:55 PM Christophe Pettus <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > On Nov 24, 2024, at 09:15, Ron Johnson <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>     It does.  I don't recall if the OP said that they were using a
>     persistent replication slot or not; it's not as common with binary
>     replication as with logical replication.
> 
> 

https://www.postgresql.org/docs/current/logicaldecoding-explanation.html

"
Caution

Replication slots persist across crashes and know nothing about the 
state of their consumer(s). They will prevent removal of required 
resources even when there is no connection using them. This consumes 
storage because neither required WAL nor required rows from the system 
catalogs can be removed by VACUUM as long as they are required by a 
replication slot. In extreme cases this could cause the database to shut 
down to prevent transaction ID wraparound (see Section 24.1.5). So if a 
slot is no longer required it should be dropped.
"

"
Caution

There is a chance that the old primary is up again during the promotion 
and if subscriptions are not disabled, the logical subscribers may 
continue to receive data from the old primary server even after 
promotion until the connection string is altered. This might result in 
data inconsistency issues, preventing the logical subscribers from being 
able to continue replication from the new primary server.
"

https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION

"
Caution

Beware that replication slots can cause the server to retain so many WAL 
segments that they fill up the space allocated for pg_wal. 
max_slot_wal_keep_size can be used to limit the size of WAL files 
retained by replication slots.
"

They have their issues also, namely they may not do all the work for you.

-- 
Adrian Klaver
[email-masked]

---

From: Ron Johnson <[email-masked]>
Date: Sun, 24 Nov 2024 17:15:18 -0500

> slot is no longer required it should be dropped.

Nagios has built-in disk space monitoring, and if it doesn't also have
built-in replication monitoring, you can write a plug-in.  Or write your
own bash script that periodically runs "SELECT * from
pg_replication_slots;" and "SELECT * FROM pg_stat_replication;" on the
primary and "SELECT * FROM pg_stat_wal_receiver;" on the secondary.

Whichever you do, some monitoring should always be in place.

"
> able to continue replication from the new primary server.

Logical replication is off-topic for this problem, no?