Robert Haas <robertmhaas@gmail.com> writes:
> 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.
My thought was that that could be zero if not relevant ... isn't that
what we do now for buffer tags for shared rels?
> 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.
It's certainly possible/likely that we're going to end up needing to
widen buffer tags to represent the smgr explicitly, because some use
cases are going to need a real database spec, some are going to need
a real tablespace spec, and some might need both. Maybe we should
just bite that bullet.
regards, tom lane
