wal_level = minimal.
On Tue, Dec 19, 2023 at 11:09 AM SOzcn <selahattinozcnma@xxxxxxxxx> wrote:
Hmm, It seems like NodeB is attempting to initialize replication despite the termination and dropping of the replication slot. The error message suggests that it's trying to establish a standby connection but encountering a limitation regarding max_wal_senders, which is currently set to 0.
Could you restart your NodeB to check this? If It does not work there are also some connection strings from applications.
Also is your wal_level is replica in the Primary?Ron Johnson <ronljohnsonjr@xxxxxxxxx>, 19 Ara 2023 Sal, 18:26 tarihinde şunu yazdı:max_wal_senders is currently 0. That's why it's complaining.On Tue, Dec 19, 2023 at 9:57 AM SOzcn <selahattinozcnma@xxxxxxxxx> wrote:Hello Ron, Can you check your "max_wal_senders" parameter value?
This is must come from the "max_wal_senders" parameter, if you set this as 5 seconds it's going to check this for each 5 second.
If you want to disable this, parameter value must be 0.
Have a nice day!Ron Johnson <ronljohnsonjr@xxxxxxxxx>, 19 Ara 2023 Sal, 17:08 tarihinde şunu yazdı:PG 14.10I had initiated streaming replication on a pair of new instances from Node A to Node B, and then stopped it via:SELECT pg_terminate_backend(<wallreceiver pid>);SELECT pg_drop_replication_slot(<slot name>);That seemed to work, since Node A isn't replicating anymore:postgres=# SELECT * from pg_replication_slots;
(0 rows)
postgres=#
postgres=# SELECT * from pg_stat_replication;
(0 rows)Node B, unsurprisingly, doesn't have anything in pg_stat_wal_receiver.$ psql --host=NodeB -xc "SELECT * FROM pg_stat_wal_receiver;"
(0 rows)And yet, Node B tries to initialize replication every 5 seconds. An excerpt from the log file:2023-12-19 08:53:52.778 EST NodeB replicator 202014 initializing 53300 FATAL: 53300: number of requested standby connections exceeds max_wal_senders (currently 0)
2023-12-19 08:53:52.778 EST NodeB replicator 202014 initializing 53300 LOCATION: InitProcess, proc.c:358