| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(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-20 13:16:13 |
| Message-ID: | CA+TgmoZLAr2Y8ZRpxCg5oQa8qGUh3pXTB2mMkM9EnDoUaSUV9Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 10, 2026 at 3:24 AM Jakub Wartak
<jakub(dot)wartak(at)enterprisedb(dot)com> wrote:
> thanks for trying out the patch! To be honest, I don't have opinion on
> this, we could do that if there's community agreement to do this (or
> some committer wants it this way or that way), but right now e.g.
> checkpoint_timeout (which serves similiar purpose) does not behave
> like that and always logs stuff and I was been told we should do
> things consistently.
>
> As for reducing logs volume, I think one could just use threshold
> of 1 or 10 minutes (but while assessing some production issues one
> could bump it down to every 1s temporarily just to have data to have
> much better understandind what was system/postmaster doing).
Well, on the immediate question, I think omitting the line altogether
when all the counters were zero would be sensible. I don't see who
would be helped by bloating the log volume in such a case.
But I would be really surprised if the overall design of this feature
didn't draw objections. I think what we normally do for features of
this type is include the relevant information in the cumulative
statistics system, and then leave it up to the user to decide how
often they want to poll the counters and how they want to summarize or
visualize the advancement of those counters. One could certainly make
an argument that having the information go to the log is a superior
user experience for people who don't need want, or need the complexity
of, an external tool. But it's going to be hard to justify why this
particular feature should be designed differently than all the other
features that do similar things.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-07-20 13:17:08 | Re: Fix RETURNING side effects for FOR PORTION OF leftover rows |
| Previous Message | Tomas Vondra | 2026-07-20 13:02:14 | Re: pg_class.reltuples can become non-finite and never recovers |