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
