Re: RFC: pg_stat_logmsg

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>, Gurjeet Singh <gurjeet(at)singh(dot)im>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: pg_stat_logmsg
Date: 2024-07-16 22:14:36
Message-ID: 5dc12198-80ff-4e70-b187-11ef33418411@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I noticed this patch hasn't moved since September 2023, so I wonder
what's the main blocker / what is needed to move this?

As for the feature, I've never done a fleet-wide analysis, so if this is
one of the main use cases, I'm not really sure I can judge if this is a
good tool for that. It seems like it might be a convenient way to do
that, but does that require we add the module to contrib?

As for the code, I wonder if the instability of line numbers could be a
problem - these can change (a little bit) between minor releases, so
after an upgrade we'll read the dump file with line numbers from the old
release, and then start adding entries with new line numbers. Do we need
to handle this in some way?

This might be partially solved by eviction of entries from the old
release - we apply decay, so after a while their usage will be 0. But
what if there's no pressure for space, we'll not actually evict them.
And it'll be confusing to have a mix of old/new line numbers.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-07-16 23:08:48 Re: RFC: pg_stat_logmsg
Previous Message Nazir Bilal Yavuz 2024-07-16 22:01:10 Re: PG_TEST_EXTRA and meson