Hi,
On 2019-02-28 10:02:46 -0800, Shawn Debnath wrote:
> 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. See [1] for previous
> discussion on this topic. We wouldn't need to do catalog lookups for
> being able to use the smgrs as the OIDs will be hardcoded in C, but the
> data will be available for posterity and OID reservation.
I'm inclined to just put them in pg_am, with a new type 's' (we already
have amtype = i for indexes, I'm planning to add 't' for tables
soon). While not a perfect fit for storage managers, it seems to fit
well enough.
> Another thought: my colleague Anton Shyrabokau suggested potentially
> re-using forknumber to differentiate smgrs. We are using 32 bits to
> map 5 entries today. This approach would be similar to how we split up
> the segment numbers and use the higher bits to identify forget or
> unlink requests for checkpointer.
That could probably be done, without incurring too much overhead
here. I'm not sure that the added complexity around the tree is worth it
however.
I personally would just go with the DB oid for the near future, where we
don't need per-database storage for those. And then plan for buffer
manager improvements.
Greetings,
Andres Freund