Re: Bug with temporary child of a permanent table after recovery

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Sun, 2012-12-16 at 21:17 -0500, Tom Lane wrote:
>> One thing I noticed that maybe needs more work is that tablecmds.c in
>> general seems mighty willing to hack upon temp tables belonging to other
>> sessions. I added tests for that in the places where there already were
>> checks on relpersistence, but I wonder whether we ought not simply
>> forbid all forms of ALTER on nonlocal temp rels, right up at the top.

> Do you see any path where an ALTER can get a hold on a non-local temp
> table? Or do you just mean as a sanity check? Either way, blocking it at
> the top sounds good to me.

Well, if you're not a superuser then you shouldn't be able to access
non-local temp tables at all, because they live in schemas you won't
have permissions for. So what we're discussing here is mainly just
protecting superusers from shooting themselves in the foot. But, given
that there are any protections at all against non-local temp tables in
the code (and there are quite a number of such checks), I'm wondering
why ALTER TABLE doesn't have a blanket rejection. Even for catalog
updates that don't involve direct touches of the file data (which is
certainly unsafe because of local vs shared buffer handling), it seems
risky because we also have various places that skip taking locks on
local temp tables.

regards, tom lane