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

I wrote:
> I'm not sure where rd_backend gets set up, but maybe we can fix this
> by not allowing rd_backend to acquire a valid value unless we've begun
> using the temp namespace.

The key bit of code seems to be this in RelationBuildDesc():

switch (relation->rd_rel->relpersistence)
...
case RELPERSISTENCE_TEMP:
if (isTempOrToastNamespace(relation->rd_rel->relnamespace))
relation->rd_backend = MyBackendId;
else
{
/*
* If it's a local temp table, but not one of ours, we have to
* use the slow, grotty method to figure out the owning
* backend.
*/
relation->rd_backend =
GetTempNamespaceBackendId(relation->rd_rel->relnamespace);
Assert(relation->rd_backend != InvalidBackendId);
}

where the second part of the if() will happily set rd_backend to
MyBackendId if that's what comes out of the namespace name, never
mind that we ought not to consider it "our" temp table.

The pre-9.1 coding in this area got it right:

relation->rd_istemp = relation->rd_rel->relistemp;
if (relation->rd_istemp)
relation->rd_islocaltemp = isTempOrToastNamespace(relation->rd_rel->relnamespace);
else
relation->rd_islocaltemp = false;

There was no way to consider a temp table "ours" unless it satisfied
isTempOrToastNamespace.

Possibly we could reset rd_backend to InvalidBackendId here if the
computed value is equal to MyBackendId, but it seems a bit fragile.
That would prevent us from computing a correct pathname for the
underlying file --- not that that file should be there anymore,
but this could hinder relation creation for instance.

Perhaps a better idea is to not overload rd_backend to serve both
the "physical name of file" purpose and the "is it my temp table"
purpose. We could add an additional relcache field with the
three possible states "not temp, my temp, somebody else's temp"
and make sure that the third state gets selected when there's
a chance collision like this. Or resurrect the old rd_istemp and
rd_islocaltemp flags.

Thoughts?

regards, tom lane