update on global temporary and unlogged tables

I haven't had a chance to do a great deal of work on this project, but
I'm hoping to get back to it at some point and, in the meantime,
thought that it might be useful to circulate a few thoughts I've had
so far.

1. As common architecture for both features, I think that it might
make sense to replace the existing relistemp (bool) field with a
relpersistence (char) field.  The current tests against rel->rd_istemp
can be replaced with macros testing the exact property we really care
about in that situation.  I'm thinking of RelationNeedsWAL(),
RelationUsesLocalBuffers(), and RelationUsesTempNamespace().

2. With respect to global temporary tables, I've hit a fairly serious
roadblock in the form of relfrozenxid.  For a permanent table, VACUUM
by any backend can advance relfrozenxid; for a backend-local temporary
table, VACUUM by the owning backend can advance relfrozenxid.  But for
a global temporary table, the proper value for relfrozenxid is the
earliest value for any backend that has stored tuples into the table.
I'm not immediately sure what to do about this.  Tom's previous
suggestion of cloning the catalog entries for each backend that tries
to access the table is one possible alternative, but I don't like that
much for reasons previously discussed.  Incidentally, per some
previous discussion, I took a look at what Oracle does with respect to
DDL on global temp tables, and I gather that they allow it if no
session has "bound" (instantiated?) the table.  Maybe some
infrastructure along those lines would be useful in dealing with the
VACUUM problem also; not sure.

3. With respect to unlogged tables, the major obstacle seems to be
figuring out a way for these to get automatically truncated at startup
time.  As with temporary table cleanup in general, the problem here is
that you can't do the obvious thing of iterating through pg_class and
truncating each unlogged table you find without greatly complicating
the startup sequence.  However, I think there's a fairly easy way
around this problem: truncating a table basically means removing all
segments and relation forks other than the first segment of the main
fork, and truncating that one to zero length.  So we could do it the
same way we clean up temporary files - namely, based on the file name
- if we made the filenames for unlogged tables distinguishable from
those for regular and temporary tables.  What I'm thinking about is
reserving a backend ID of -2 for this purpose via some suitable
constant definition, just as -1 (InvalidBackendId) represents a
permanent table in this context.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company