From: | Jerry Sievers <gsievers19(at)comcast(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jerry Sievers <gsievers19(at)comcast(dot)net>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Which backend using which pg_temp_N schema? |
Date: | 2018-06-06 17:13:01 |
Message-ID: | 87wovbrg82.fsf@jsievers.enova.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Jerry Sievers <gsievers19(at)comcast(dot)net> writes:
>
>> Yep thanks... but IMO something that simply exposes whatever internal
>> registry of temp schemas/PIDs (which I presume must exist)
>
> Not really. There are a couple of ways that one could identify a
> session's "BackendId", which is the "N" in the "pg_temp_N" name of
> the temp schema that it would use if it uses one. But I do not think
> there's any terribly reliable way to tell from outside the session
> whether it has actually done anything with the temp schema. If it
> hasn't, then at least in principle there could be objects in the
> schema that are left over from a crashed session that previously had
> the same BackendId. We only make an effort to clean out such objects
> at the time that a session first creates a temp object.
Hmmm, interesting.
> In any case, I think you're right that this isn't exposed at the SQL
> level presently.
Roger that and what motivated the post was basically to explore that
issue.
Thx
>
> regards, tom lane
>
>
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres(dot)consulting(at)comcast(dot)net
p: 312.241.7800
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Schneider | 2018-06-06 17:39:36 | Re: Code of Conduct plan |
Previous Message | Tom Lane | 2018-06-06 17:12:13 | Re: Slow planning time for simple query |