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
-
Use actual backend IDs in pg_stat_get_backend_idset() and friends.
- d7e39d72ca1c 16.0 landed