On Thu, Feb 28, 2019 at 10:09 AM Tom Lane <t...@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
