Re: libpq debug log - Mailing list pgsql-hackers

From 'alvherre@alvh.no-ip.org'
Subject Re: libpq debug log
Date
Msg-id 20210330235255.GA17949@alvherre.pgsql
Whole thread Raw
In response to RE: libpq debug log  ("iwata.aya@fujitsu.com" <iwata.aya@fujitsu.com>)
Responses Re: libpq debug log  ("'alvherre@alvh.no-ip.org'" <alvherre@alvh.no-ip.org>)
RE: libpq debug log  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
List pgsql-hackers
Okay, pushed this patch and the new testing for it based on
libpq_pipeline.  We'll see how the buildfarm likes it.

I made some further changes to the last version; user-visibly, I split
the trace flags in two, keeping the timestamp suppression separate from
the redacting feature for regression testing.

I didn't like the idea of silently skipping the redacted fields, so I
changed the code to print NNNN or SSSS instead.  I also made the
redacting occur in the last mile (pqTraceOutputInt32 / String) rather
that in their callers: it seemed quite odd to advance the cursor in the
"else" branch.

I refactored the duplicate code that appeared for Notice and Error.
In that function, we redact not only the 'L' field (what Iwata-san was
doing) but also 'F' (file) and 'R' (routine) because those things can
move around for reasons that are not interesting to testing this code.

In the libpq_pipeline commit I added 'pipeline_abort' and 'transaction'
to the cases that generate traces, which adds coverage for
NoticeResponse and ErrorResponse.

-- 
Álvaro Herrera                            39°49'30"S 73°17'W



pgsql-hackers by date:

Previous
From: Zhihong Yu
Date:
Subject: Re: What to call an executor node which lazily caches tuples in a hash table?
Next
From: Tom Lane
Date:
Subject: Re: unconstrained memory growth in long running procedure stored procedure after upgrading 11-12