On 2019-02-28 13:16:02 -0500, Tom Lane wrote:
> 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.
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