From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Greg Stark <stark@mit.edu>, pgsql-hackers@postgresql.org
Subject: Re: identifying the backend that owns a temporary schema
In-reply-to: <20220926160822.GA1298186@nathanxps13>
References: <20220815205811.GA250990@nathanxps13>
 <CAM-w4HMZ03AbQjBbfN_mTxct68HX3NPRQVfLaRxLGJTejJ8xbg@mail.gmail.com>
 <20220829230757.GA542616@nathanxps13> <2297420.1664041298@sss.pgh.pa.us>
 <20220926160822.GA1298186@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Mon, 26 Sep 2022 09:08:22 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3499641.1664221809.1@sss.pgh.pa.us>
Date: Mon, 26 Sep 2022 15:50:09 -0400
Message-ID: <3499642.1664221809@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3499642.1664221809%40sss.pgh.pa.us>
Precedence: bulk

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.

			regards, tom lane