Re: including PID or backend ID in relpath of temp rels

On Tue, May 4, 2010 at 3:03 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
>> > Hmm, wasn't there a proposal to have the owning backend delete the files
>> > instead of asking the bgwriter to?
>>
>> I did propose that upthread; it may have been proposed previously
>> also. This might be worth doing independently of the rest of the patch
>> (which I'm starting to fear is doomed, cue ominous soundtrack) since
>> it would reduce the chance of orphaning data files and possibly
>> simplify the logic also.
>
> +1 for doing it separately, but hopefully that doesn't mean the rest of
> this patch is doomed ...

I wonder if it would be possible to reject access to temporary
relations at a higher level. Right now, if you create a temporary
relation in one session, you can issue a SELECT statement against it
in another relation, and get back 0 rows. If you then insert data
into it and select against it again, you'll get an error saying that
you can't access temporary tables of other sessions. If you try to
truncate somebody else's temporary relation, it fails; but if you try
to drop it, it works. In fact, you can even run ALTER TABLE ... ADD
COLUMN on somebody else's temp table, as long as you don't do anything
that requires a rewrite. CLUSTER fails; VACUUM and VACUUM FULL both
appear to work but apparently actually don't do anything under the
hood, so that database-wide vacuums don't barf. The whole thing seems
pretty leaky. It would be nice if we could find a small set of
control points where we basically reject ALL access to somebody else's
temp relations, period.

One possible thing we might do (bearing in mind that we might need to
wall off access at multiple levels) would be to forbid creating a
relcache entry for a non-local temprel. That would, in turn, forbid
doing pretty much anything to such a relation, although I'm not sure
what else would get broken in the process. But it would eliminate,
for example, all the checks for RELATION_IS_OTHER_TEMP, since that
Just Couldn't Happen. It would would eliminate the need to install
specific handling for this case in dbsize.c - we'd just automatically
croak. And it's also probably necessary to do this anyhow if we want
to ever eliminate those CacheInvalidSmgr() calls for temp rels,
because if I can drop your temprel, that implies I can smgropen() it.

...Robert