|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||"Bossart, Nathan" <bossartn(at)amazon(dot)com>|
|Cc:||Andrew Dunstan <andrew(at)dunslane(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Sehrope Sarkuni <sehrope(at)jackdb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, "david(at)fetter(dot)org" <david(at)fetter(dot)org>|
|Subject:||Re: Add jsonlog log_destination for JSON server logs|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Tue, Jan 11, 2022 at 08:34:26PM +0000, Bossart, Nathan wrote:
> 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.
Thanks. I have looked again at 0001 and 0002 today and applied both,
so it means that we are done with all the refactoring pieces proposed
up to now.
> IIUC 0003 simply introduces jsonlog using the existing framework.
This part will have to wait a bit more, but yes, this piece should be
> 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.
I am not sure that this is worth the complications, either.
|Next Message||Julien Rouhaud||2022-01-12 06:31:53||Re: cfbot wrangling (was Re: Add checkpoint and redo LSN to LogCheckpointEnd log message)|
|Previous Message||Tom Lane||2022-01-12 06:19:22||cfbot wrangling (was Re: Add checkpoint and redo LSN to LogCheckpointEnd log message)|