Re: identifying the backend that owns a temporary schema

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: identifying the backend that owns a temporary schema
Date: 2022-09-26 19:50:09
Message-ID: 3499642.1664221809@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nathan Bossart <nathandbossart(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-09-26 20:05:46 Re: HOT chain validation in verify_heapam()
Previous Message Peter Geoghegan 2022-09-26 19:47:14 Re: [RFC] building postgres with meson - v13