Re: log_postmaster_stats

From: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Quan Zongliang <quanzongliang(at)yeah(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: log_postmaster_stats
Date: 2026-07-27 06:47:47
Message-ID: CAKZiRmy+qqox8XSk+cd+c7XmbGZHHpnAHOg3D-Ho-atuQRP4fg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 23, 2026 at 10:25 AM Jakub Wartak
<jakub(dot)wartak(at)enterprisedb(dot)com> wrote:
>
> On Mon, Jul 20, 2026 at 3:16 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
[..]

After some quick offline follow-up chat with Robert last Thursday, he
helped me to steer more this towards emergency logging in case of overloaded
postmaster rather constant logging of postmaster statistics. One can think
of it something like 'checkpoints happening too fast', but for postmaster.

Now the GUC/concept is called log_excess_connection_attempts, however it is
based on postmaster's CPU time or delay in getting CPU scheduled at all.
I think name is nice, but one can argue it should be
log_excess_postmaster_cpu_time too technically, but I find it way too long.

I've did not wanted to clobber more the logging output, so the HINT line is
not there, but now documentation has tip what to check (and btw it is off by
default, so only people suspecting/debugging something would be getting any
of this)

There's one problem with github CI (and probably buildfarm), not being good
place to test it (apparently ~8 VCPUs are not enough to overload with pgbench
--connect the postamster), so that test is there, but commented out mostly.

-J.

Attachment Content-Type Size
v2-0001-Add-log_excess_connection_attempts.patch text/x-patch 16.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2026-07-27 06:55:51 Re: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum
Previous Message Jacob Brazeal 2026-07-27 06:23:06 Re: Write skew observed under serializable isolation