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

Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> Spotted by accident while working on a patch:
> Open psql and do:

> CREATE TABLE uctest(f1 int, f2 text);
> -- Create a temporary child of the permanent table
> CREATE TEMP TABLE ucchild () inherits (uctest);

> In another terminal:
> pg_ctl stop -m immediate
> pg_ctl start

> psql (9.3devel)
> Type "help" for help.

> postgres=# SELECT * FROM uctest;
> ERROR: could not open file "base/12030/t2_16392": No such file or directory

> This goes back to 9.1.

I believe this used to work before Robert redesigned temp relations.
The underlying physical file got removed during postmaster restart, but
at this point the catalog entry for the temp table is still there, and
the planner is failing to disregard it as intended. The problem is that
the RELATION_IS_OTHER_TEMP macro

#define RELATION_IS_OTHER_TEMP(relation) \
((relation)->rd_rel->relpersistence == RELPERSISTENCE_TEMP \
&& (relation)->rd_backend != MyBackendId)

is getting fooled by a chance collision of backend IDs --- that is,
the failure only occurs in sessions with the same BackendId that the
original table creator had.

It worked before because the "is my temp table" test was based on
whether the table belonged to myTempNamespace, which would be InvalidOid
until the backend had started using the temp namespace --- and one of
the things involved in that is to run around and clean out any leftover
tables in that schema.

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.

regards, tom lane