|From:||Julien Rouhaud <rjuju123(at)gmail(dot)com>|
|To:||Jacob Champion <pchampion(at)vmware(dot)com>|
|Cc:||"michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>|
|Subject:||Re: [PATCH] Expose port->authn_id to extensions and triggers|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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.
> > 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.
|Next Message||Tom Lane||2022-02-24 17:20:38||Re: libpq async duplicate error results|
|Previous Message||Matthias van de Meent||2022-02-24 17:14:53||Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)|