Re: Proposal: Save user's original authenticated identity for logging

From: Jacob Champion <pchampion(at)vmware(dot)com>
To: "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>
Cc: "magnus(at)hagander(dot)net" <magnus(at)hagander(dot)net>, "stark(at)mit(dot)edu" <stark(at)mit(dot)edu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Proposal: Save user's original authenticated identity for logging
Date: 2021-03-19 18:37:05
Message-ID: d88b52ac2539caa7eb28bde6db589926e187ab76.camel@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2021-03-19 at 16:54 +0000, Jacob Champion wrote:
> One additional improvement I would suggest, now that the rotation logic
> is simpler than it was in my original patch, is to rotate the logfile
> regardless of whether the test is checking the logs or not. (Similarly,
> we can manually rotate after the block of test_query() calls.) That way
> it's harder to match the last test's output.

The same effect can be had by moving the log rotation to the top of the
test that needs it, so I've done it that way in v7.

> The tradeoff is that if you need to check for log message order, or for
> multiple instances of overlapping patterns, you still need some sort of
> search-forward functionality.

Turns out it's easy now to have our cake and eat it too; a single if
statement can implement the same search-forward functionality that was
spread across multiple places before. So I've done that too.

Much nicer, thank you for the suggestion!

--Jacob

Attachment Content-Type Size
v7-0001-test-kerberos-rotate-logs-between-tests.patch text/x-patch 2.9 KB
v7-0002-ssl-store-client-s-DN-in-port-peer_dn.patch text/x-patch 3.2 KB
v7-0003-Log-authenticated-identity-from-all-auth-backends.patch text/x-patch 27.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2021-03-19 18:42:08 Re: non-HOT update not looking at FSM for large tuple update
Previous Message John Naylor 2021-03-19 18:16:22 Re: non-HOT update not looking at FSM for large tuple update