Re: Extensible storage manager API - smgr hooks

From: Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
To: Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Extensible storage manager API - smgr hooks
Date: 2021-06-30 02:36:11
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Anastasia Lubennikova писал 2021-06-30 00:49:
> Hi, hackers!
> Many recently discussed features can make use of an extensible storage
> manager API. Namely, storage level compression and encryption [1],
> [2], [3], disk quota feature [4], SLRU storage changes [5], and any
> other features that may want to substitute PostgreSQL storage layer
> with their implementation (i.e. lazy_restore [6]).
> Attached is a proposal to change smgr API to make it extensible. The
> idea is to add a hook for plugins to get control in smgr and define
> custom storage managers. The patch replaces smgrsw[] array and smgr_sw
> selector with smgr() function that loads f_smgr implementation.
> As before it has only one implementation - smgr_md, which is wrapped
> into smgr_standard().
> To create custom implementation, a developer needs to implement smgr
> API functions
> static const struct f_smgr smgr_custom =
> {
> .smgr_init = custominit,
> ...
> }
> create a hook function
> const f_smgr * smgr_custom(BackendId backend, RelFileNode rnode)
> {
> //Here we can also add some logic and chose which smgr to use
> based on rnode and backend
> return &smgr_custom;
> }
> and finally set the hook:
> smgr_hook = smgr_custom;
> [1]
> [2]
> [3]
> [4]
> [5]
> [6]
> --
> Best regards,
> Lubennikova Anastasia

Good day, Anastasia.

I also think smgr should be extended with different implementations
aside of md.
But which way concrete implementation will be chosen for particular
I believe it should be (immutable!) property of tablespace, and should
be passed
to smgropen. Patch in current state doesn't show clear way to distinct
implementations per relation.

I don't think patch should be that invasive. smgrsw could pointer to
array instead of static array as it is of now, and then reln->smgr_which
will remain with same meaning. Yep it then will need a way to select
implementation, but something like `char smgr_name[NAMEDATALEN]` field
linear search in (i believe) small smgrsw array should be enough.

Maybe I'm missing something?

Sokolov Yura.

Attachment Content-Type Size
0001-smgr_api.patch text/x-patch 12.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-06-30 02:59:23 Re: Preventing abort() and exit() calls in libpq
Previous Message Noah Misch 2021-06-30 01:37:28 Re: public schema default ACL