On Mon, 4 Dec 2023 at 17:51, Kirill Reshke <reshkekir...@gmail.com> wrote: > > So, 0002 patch uses the `get_tablespace` function, which searches Catalog to > tablespace SMGR id. I wonder how `smgr_redo` would work with it?
That's a very good point I hadn't considered in detail yet. Quite clearly, the current code is wrong in assuming that the catalog is accessible, and it should probably be stored in a way similar to pg_filenode.map in a file managed outside the buffer pool. > Is it possible to query the system catalog during crash recovery? As far as i > understand the answer is "no", correct me if I'm wrong. Yes, you're correct, we can't access buffers like this during recovery. That's going to need some more effort. > Furthermore, why do we only allow tablespace to have its own SMGR > implementation, can we have per-relation SMGR? Maybe we can do it in a way > similar to custom RMGR (meaning, write SMGR OID into WAL and use it in crash > recovery etc.)? AMs (and by extension, their RMGRs) that use Postgres' buffer pool have control over how they want to layout their blocks and files, but generally don't care about where those blocks and files are located, as long as they _can_ be retrieved. Tablespaces, however, describe 'drives' or 'storage pools' in which the tables/relations are stored, which to me seems to be the more logical place to configure the SMGR abstraction of how and where to store the actual data, as SMGRs manage the low-level relation block IO (= file accesses), and tablespaces manage where files are stored. Note that nothing prevents you from using one tablespace (thus different SMGR) per relation, apart from bloated catalogs and the superuser permissions required for creating those tablespaces. It'd be difficult to manage, but not impossible. Kind regards, Matthias van de Meent Neon (https://neon.tech)