On 2019-02-28 13:16:02 -0500, Tom Lane wrote: > Shawn Debnath <s...@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.
It's definitely a kludge, but it doesn't seem that bad for now. Delaying a nice answer till we have a more efficient bufmgr representation doesn't seem crazy to me. I don't think there's a real conflict risk given that we don't allow for duplicated oids across catalogs at bootstrap time, and this is definitely a bootstrap time issue. > > 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. Yea, if we just split that into two 16bit entries, there'd not be much lost. Some mild mild performance regression due to more granular memory->register reads/writes, but I can't even remotely see that matter. > Since, per this discussion, the smgr IDs need not really be OIDs at > all, we just need a few bits for them. Personally I find having them as oids more elegant than the distaste from misusing the database oid for a wihle, but I think it's fair to disagree here. Greetings, Andres Freund
