Re: Add jsonlog log_destination for JSON server logs - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Add jsonlog log_destination for JSON server logs
Date
Msg-id 2674A01D-CC61-42DA-9923-DEF943D08FF1@amazon.com
Whole thread Raw
In response to Re: Add jsonlog log_destination for JSON server logs  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Add jsonlog log_destination for JSON server logs
List pgsql-hackers
On 1/10/22, 4:51 AM, "Michael Paquier" <michael@paquier.xyz> wrote:
> The issue comes from an incorrect change in syslogger_parseArgs()
> where I missed that the incrementation of argv by 3 has no need to be
> changed.  A build with -DEXEC_BACKEND is enough to show the failure,
> which caused a crash when starting up the syslogger because of a NULL
> pointer dereference.  The attached v9 should be enough to switch the
> CF bot to green.

I've been looking at the latest patch set intermittently and playing
around with jsonlog a little.  It seems to work well, and I don't have
any significant comments about the code.  0001 and 0002 seem
straightforward and uncontroversial.  IIUC 0003 simply introduces
jsonlog using the existing framework.

I wonder if we should consider tracking each log destination as a set
of function pointers.  The main logging code would just loop through
the enabled log destinations and use these functions, and it otherwise
would be completely detached (i.e., no "if jsonlog" blocks).  This
might open up the ability to define custom log destinations via
modules, too.  However, I don't know if there's any real demand for
something like this, and it should probably be done separately from
introducing jsonlog, anyway.

Nathan


pgsql-hackers by date:

Previous
From: "Imseih (AWS), Sami"
Date:
Subject: Re: Add index scan progress to pg_stat_progress_vacuum
Next
From: Tom Lane
Date:
Subject: Re: Use -fvisibility=hidden for shared libraries