From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Rick Otten <rottenwindfish@gmail.com>
To: pgsql-performa. <pgsql-performance@postgresql.org>
Subject: Re: max_wal_senders
Date: Thu, 09 Feb 2023 06:59:53 +0100
Message-ID: <ba04a12d2b1e792e863e98cd88d3d54649464d21.camel@cybertec.at> (raw)
In-Reply-To: <CAMAYy4JKvug31ri0nJxn+yVB20XKg-Si5+7VwZocQRV_0Rzyig@mail.gmail.com>
References: <CAMAYy4JKvug31ri0nJxn+yVB20XKg-Si5+7VwZocQRV_0Rzyig@mail.gmail.com>
On Wed, 2023-02-08 at 18:07 -0500, Rick Otten wrote:
> I've been thinking about the max_wal_senders parameter lately and wondering if there
> is any harm in setting it too high.
No, there isn't, except that if you end up having too many *actual* WAL senders, it
will cause load. A high limit is no problem as such.
> The documentation mentions an orphaned connection slot that may take a while to time out.
> How can I tell if I have any of those? I was looking for a `pg_wal_slots` table
> similar to the `pg_replication_slots` table, but don't see anything obvious in the catalog.
The view is "pg_stat_replication", but you won't see there if an entry is
abandoned before PostgreSQL does and terminates it. You can set "tcp_keepalived_idle"
low enough so that the kernel will detect broken connections early on.
Yours,
Laurenz Albe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: laurenz.albe@cybertec.at, rottenwindfish@gmail.com
Subject: Re: max_wal_senders
In-Reply-To: <ba04a12d2b1e792e863e98cd88d3d54649464d21.camel@cybertec.at>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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