Re: identifying the backend that owns a temporary schema

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Stark <stark@mit.edu>, pgsql-hackers@postgresql.org
Date: 2022-09-26T20:11:13Z
Lists: pgsql-hackers

Attachments

On Mon, Sep 26, 2022 at 03:50:09PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> On Sat, Sep 24, 2022 at 01:41:38PM -0400, Tom Lane wrote:
>>> One thing I don't like about it documentation-wise is that it leaves
>>> the concept of backend ID pretty much completely undefined.
> 
>> How specific do you think this definition ought to be?
> 
> Fairly specific, I think, so that people can reason about how it behaves.
> Notably, it seems absolutely critical to be clear that the IDs recycle
> over short time frames.  Maybe like
> 
>     These access functions use the session's backend ID number, which is
>     a small integer that is distinct from the backend ID of any concurrent
>     session, although an ID can be recycled as soon as the session exits.
>     The backend ID is used, among other things, to identify the session's
>     temporary schema if it has one.
> 
> I'd prefer to use the terminology "session" than "backend" in the
> definition.  I suppose we can't get away with actually calling it
> a "session ID" given that "backend ID" is used in so many places;
> but I think people have a clearer handle on what a session is.

Thanks for the suggestion.  I used it in v4 of the patch.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Commits

  1. Use actual backend IDs in pg_stat_get_backend_idset() and friends.