Re: Proposal: Save user's original authenticated identity for logging - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Proposal: Save user's original authenticated identity for logging
Date
Msg-id a4fddbcd2f99c293991b7669bd0da3e5a7d3f93b.camel@vmware.com
Whole thread Raw
In response to Re: Proposal: Save user's original authenticated identity for logging  (Jacob Champion <pchampion@vmware.com>)
Responses Re: Proposal: Save user's original authenticated identity for logging  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Tue, 2021-03-30 at 17:06 +0000, Jacob Champion wrote:
> Would it be acceptable to adjust the tests for live rotation using the
> logging collector, rather than a full restart? It would unfortunately
> mean that we have to somehow wait for the rotation to complete, since
> that's asynchronous.

I wasn't able to make live rotation work in a sane way. So, v14 tries
to thread the needle with a riff on your earlier idea:

> If you want to keep this information around
> for debugging, I guess that we could just print the contents of the
> backend logs to regress_log_001_password instead?  This could be done
> with a simple wrapper routine that prints the past contents of the log
> file before truncating them.

Rather than putting Postgres log data into the Perl logs, I rotate the
logs exactly once at the beginning -- so that there's an
old 001_ssltests_primary.log, and a new 001_ssltests_primary_1.log --
and then every time we truncate the logfile, I shuffle the bits from
the new logfile into the old one. So no one has to learn to find the
log entries in a new place, we don't get an explosion of rotated logs,
we don't lose the log data, we don't match incorrect portions of the
logs, and we only pay the restart price once. This is wrapped into a
small Perl module, LogCollector.

WDYT?

--Jacob

Attachment

pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: Idea: Avoid JOINs by using path expressions to follow FKs
Next
From: David Rowley
Date:
Subject: What to call an executor node which lazily caches tuples in a hash table?