From: Ronan Dunklau <ronan.dunklau@aiven.io>
To: pgsql-hackers@lists.postgresql.org,
 Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Subject: Re: Proposal: More structured logging
Date: Thu, 09 Sep 2021 11:15:36 +0200
Message-ID: <19106440.dsh0iPAc3d@aivenronan>
Organization: aiven
In-Reply-To: <03fa81f6-77b0-e7eb-b390-dfe04f180495@enterprisedb.com>
References: <3207907.AWbSqkKDnR@aivenronan> <163276811.1OrvvjSa7g@aivenronan>
 <03fa81f6-77b0-e7eb-b390-dfe04f180495@enterprisedb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Archived-At: 
 <https://www.postgresql.org/message-id/19106440.dsh0iPAc3d%40aivenronan>
Precedence: bulk

Le mercredi 8 septembre 2021, 11:51:31 CEST Peter Eisentraut a =E9crit :
> On 01.09.21 10:00, Ronan Dunklau wrote:
> > In-core it would open up the possibility to split log messages into
> > different fields, for example the different statistics reported in the
> > logs by VACUUM / ANALYZE VERBOSE and make it easier to consume the outp=
ut
> > without having to parse the message. Parsing the message also means that
> > any tool parsing it needs to either be aware of the locale, or to force
> > the user to use a specific one.
>=20
> I think those messages would themselves have substructure.  For example,
> the current message
>=20
>      "I/O timings: read: %.3f ms, write: %.3f ms\n"
>=20
> might be
>=20
>      {"I/O timings": {"read": ..., "write": ...}}
>=20
> and that in turn is already part of a larger message.
>=20
> So just having a single level of tags wouldn't really work for this.

I agree having a nested structure may feel more natural, but I don't think =
it=20
would matter too much if we standardize on ini-style property names (ie,=20
iotimings.read, iotimings.write and so on...)

Regards,

=2D-=20
Ronan Dunklau