Re: RFC: pg_stat_logmsg

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Gurjeet Singh <gurjeet(at)singh(dot)im>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: pg_stat_logmsg
Date: 2024-07-18 04:26:29
Message-ID: ZpiZdR4m2KVi4RsC@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 17, 2024 at 07:48:15AM -0400, Joe Conway wrote:
> I think including version in the key makes most sense. Also do we even have
> a mechanism to grab the commit sha in running code?

Not directly, still that's doable.

The closest thing I would consider here is to get the output of
something like 'git rev-parse --short HEAD` and attach it to
PG_VERSION with --with-extra-version. I do that in my local builds
because I always want to know from which commit I am building
something. Then, PG_VERSION could be stored with the entries while
hashing the stats key with the version string, the error code, the
source file name and/or the line number for uniqueness. 32 bytes of
room would be most likely enough when it comes to the PG_VERSION data
stored in the stats entries.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2024-07-18 04:27:17 Re: Allow logical failover slots to wait on synchronous replication
Previous Message Tom Lane 2024-07-18 03:58:21 Re: improve performance of pg_dump with many sequences