Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Feb-23, Tom Lane wrote:
>> However, if someone held a gun to my head and said fix it, I'd be inclined
>> to do so by having temp-namespace creation insert a "pin" dependency into
>> pg_depend. Arguably, the only reason we don't create all the temp
>> namespaces during bootstrap is because we aren't sure how many we'd need
>> --- but if we did do that, they'd presumably end up pinned.
> Is there a problem if we start with very high max_backends and this pins
> a few thousands schemas that are later no longer needed? There's no
> decent way to drop them ... (I'm not sure it matters all that much,
> except for bloat in pg_namespace.)
> How about hardcoding a pin for any schema that's within the current
> max_backends?
I remain skeptical that there's a problem here that so badly needs
fixed as to justify half-baked hacks in the dependency system. We'd
be more likely to create problems than fix them.
The existing state of affairs is that a superuser who really needs to drop
a temp schema can do so, if she's careful that it's not active. Pinning
things would break that, or at least add an additional roadblock. If it's
some sort of virtual pin rather than a regular pg_depend entry, then it
*would* be impossible to get around (mumble ... DELETE FROM pg_namespace
... mumble). As against that, what problem are we fixing by preventing
superusers from doing that? A careless superuser can screw things up
arbitrarily badly in any case, so I'm not that fussed about the hazard
that the namespace isn't idle.
regards, tom lane