Thomas Munro <thomas.munro@gmail.com> writes:
> On Thu, Feb 28, 2019 at 7:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Thomas Munro <thomas.munro@gmail.com> writes:
>>> Our current thinking is that smgropen() should know how to map a small
>>> number of special database OIDs to different smgr implementations
>> Hmm. Maybe mapping based on tablespaces would be a better idea?
> In the undo log proposal (about which more soon) we are using
> tablespaces for their real purpose, so we need that OID. If you SET
> undo_tablespaces = foo then future undo data created by your session
> will be written there, which might be useful for putting that IO on
> different storage.
Meh. That's a point, but it doesn't exactly seem like a killer argument.
Just in the abstract, it seems much more likely to me that people would
want per-database special rels than per-tablespace special rels. And
I think your notion of a GUC that can control this is probably pie in
the sky anyway: if we can't afford to look into the catalogs to resolve
names at this code level, how are we going to handle a GUC?
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.
In short, I think you're better off equating smgrs to magic
tablespaces, and if you need some way of letting users control
where those map to storage-wise, control it in some other way.
regards, tom lane