Re: [PATCH] Expose port->authn_id to extensions and triggers - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: [PATCH] Expose port->authn_id to extensions and triggers
Date
Msg-id a4d9baa0717ca924331cb1dd062788bd73bd14a4.camel@vmware.com
Whole thread Raw
In response to Re: [PATCH] Expose port->authn_id to extensions and triggers  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: [PATCH] Expose port->authn_id to extensions and triggers  (Julien Rouhaud <rjuju123@gmail.com>)
Re: [PATCH] Expose port->authn_id to extensions and triggers  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
On Fri, 2022-02-25 at 01:15 +0800, Julien Rouhaud wrote:
> On Thu, Feb 24, 2022 at 04:50:59PM +0000, Jacob Champion wrote:
> > On Thu, 2022-02-24 at 20:39 +0900, Michael Paquier wrote:
> > > I don't quite see the additional value that this API brings as
> > > MyProcPort is directly accessible, and contrib modules like
> > > postgres_fdw and sslinfo just use that to find the data of the current
> > > backend.
> > 
> > Right -- I just didn't know if third-party modules were actually able
> > to rely on the internal layout of struct Port. Is that guaranteed to
> > remain constant for a major release line? If so, this new API is
> > superfluous.
> 
> Yes, third-party can rely on Port layout.  We don't break ABI between minor
> release.  In some occasions we can add additional fields at the end of a
> struct, but nothing more.

That simplifies things. PFA a smaller v2; if pgaudit can't make use of
libpq-be.h for some reason, then I guess we can tailor a fix to that
use case.

> > > I could still see a use case for that at a more global level with
> > > beentrys, but it looked like there was not much interest the last time
> > > I dropped this idea.
> > 
> > I agree that this would be useful to have in the stats. From my outside
> > perspective, it seems like it's difficult to get strings of arbitrary
> > length in there; is that accurate?
> 
> Yes, as it's all in shared memory.  The only workaround is using something like
> track_activity_query_size, but it's not great.

Yeah... I was following a similar track with the initial work last
year, but I dropped it when the cost of implementation started to grow
considerably. At the time, though, it looked like some overhauls to the
stats framework were being pursued? I should read up on that thread.

--Jacob

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Logical insert/update/delete WAL records for custom table AMs
Next
From: Tomas Vondra
Date:
Subject: ltree_gist indexes broken after pg_upgrade from 12 to 13