Hi, On 2022-11-16 15:59:09 +0300, Maxim Orlov wrote: > Patch is posted as PoC is attached.
> --- a/src/backend/storage/smgr/md.c > +++ b/src/backend/storage/smgr/md.c > @@ -40,6 +40,7 @@ > #include "storage/sync.h" > #include "utils/hsearch.h" > #include "utils/memutils.h" > +#include "utils/spccache.h" > > /* > * The magnetic disk storage manager keeps track of open file > @@ -479,14 +480,16 @@ mdextend(SMgrRelation reln, ForkNumber forknum, > BlockNumber blocknum, > > if ((nbytes = FileWrite(v->mdfd_vfd, buffer, BLCKSZ, seekpos, > WAIT_EVENT_DATA_FILE_EXTEND)) != BLCKSZ) > { > + int elevel = > get_tablespace_elevel(reln->smgr_rlocator.locator.spcOid); > + You can't do catalog access below the bufmgr.c layer. It could lead to all kinds of nastiness, including potentially recursing back to md.c. Even leaving that aside, we can't do catalog accesses in all kinds of environments that this currently is active in - most importantly it's affecting the startup process. We don't do catalog accesses in the startup process, and even if we were to do so, we couldn't unconditionally because the catalog might not even be consistent at this point (nor is it guaranteed that the wal_level even allows to access catalogs during recovery). I'm not convinced by the usecase in the first place, but purely technically I think it's not viable to make this a tablespace option. Greetings, Andres Freund