Re: identifying the backend that owns a temporary schema
| От | Nathan Bossart |
|---|---|
| Тема | Re: identifying the backend that owns a temporary schema |
| Дата | |
| Msg-id | 20220926201113.GA1340606@nathanxps13 обсуждение исходный текст |
| Ответ на | Re: identifying the backend that owns a temporary schema (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: identifying the backend that owns a temporary schema
|
| Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: