Shawn Debnath <sdn@amazon.com> writes:
> On Thu, Feb 28, 2019 at 10:35:50AM -0500, Robert Haas wrote:
>> 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.
> We have scripts under catalog directory that can check to ensure OIDs
> aren't re-used accidentally. However, we still have to define an entry
> in a catalog somewhere and I was proposing creating a new one,
> pg_storage_managers?, to track these entries.
That would fail to capture the property that the smgr OIDs mustn't
conflict with database OIDs, so the whole thing still seems like an
ugly kluge from here.
> Another thought: my colleague Anton Shyrabokau suggested potentially
> re-using forknumber to differentiate smgrs. We are using 32 bits to
> map 5 entries today.
Yeah, that seems like it might be a workable answer.
I really do think that relying on magic database OIDs is a bad idea;
if you think you aren't going to need a real database ID in there in
the future, you're being short-sighted. And I guess the same argument
establishes that relying on magic tablespace OIDs would also be a bad
idea, even if there weren't a near-term proposal on the table for
needing real tablespace IDs in an alternate smgr. So we need to find
some bits somewhere else, and the fork number field is the obvious
candidate. Since, per this discussion, the smgr IDs need not really
be OIDs at all, we just need a few bits for them.
regards, tom lane