On Wed, Sep 01, 2021 at 04:39:43PM -0400, Sehrope Sarkuni wrote: > That makes the elog.c changes in the JSON logging patch minimal as all it's > really doing is invoking the new write_jsonlog(...) function.
Looking at 0001, to do things in order. > @@ -46,8 +46,8 @@ typedef struct > char nuls[2]; /* always \0\0 */ > uint16 len; /* size of this chunk (counts > data only) */ > int32 pid; /* writer's pid */ > - char is_last; /* last chunk of message? 't' > or 'f' ('T' or > - * 'F' for CSV > case) */ > + int32 dest; /* log destination */ > + char is_last; /* last chunk of message? 't' or 'f'*/ > char data[FLEXIBLE_ARRAY_MEMBER]; /* data payload starts > here */ > } PipeProtoHeader; Making PipeProtoHeader larger is not free, and that could penalize workloads with a lot of short messages and many backends as the syslogger relies on pipes with sync calls. Why not switching is_last to bits8 flags instead? That should be enough for the addition of JSON. 3 bits are enough at the end: one to know if it is the last chunk of message, one for CSV and one for JSON. -- Michael
signature.asc
Description: PGP signature