On Thu, Feb 28, 2019 at 10:09 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The real reason I'm concerned about this, though, is that for either
> a database or a tablespace, you can *not* get away with having a magic
> OID just hanging in space with no actual catalog row matching it.
> If nothing else, you need an entry there to prevent someone from
> reusing the OID for another purpose. And a pg_database row that
> doesn't correspond to a real database is going to break all kinds of
> code, starting with pg_upgrade and the autovacuum launcher. Special
> rows in pg_tablespace are much less likely to cause issues, because
> of the precedent of pg_global and pg_default.
My first intuition was the same as yours -- that we should use the
tablespace to decide which smgr is relevant -- but I now think that
intuition was wrong. Even if you use the tablespace OID to select the
smgr, it doesn't completely solve the problem you're worried about
here. You still have to put SOMETHING in the database OID field, and
that's going to be just as fake as it was before. I guess you could
use the OID for pg_global for things like undo and SLRU data, but then
how is GetRelationPath() going to work? You don't have enough bits
left anywhere to specify both a tablespace and a location within that
tablespace in a reasonable way, and I think it's far from obvious how
you would build a side channel that could carry that information.
Also, I don't see why we'd need a fake pg_database row in the first
place. IIUC, the OID counter wraps around to FirstNormalObjectId, so
nobody should have a database with an OID less than that value.
If we were using smgrs to represent other kinds of ways of storing
user tables, e.g. network.c, cloud.c, magtape.c, punchcard.c, etc. -
then I think we'd have to find some way to let each user-defined
tablespace pick an smgr, and I don't really know how that would work
given the fact that we can't really use catalog lookups to figure out
which one to use, but actually the direction here is to store files
internal to the system using special-purpose smgrs so that we can pull
more things into shared_buffers, and for that purpose the database OID
seems cleaner.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company