Re: Extensible storage manager API - SMGR hook Redux

On 9/21/24 8:24 PM, Nitin Jadhav wrote:
> I reviewed the discussion and took a look at the patch sets. It seems
> like many things are combined here. Based on the subject, I initially
> thought it aimed to provide the infrastructure to easily extend
> storage managers. This would allow anyone to create their own storage
> managers using this infrastructure. While it addresses this, it also
> includes additional features like fsync_checker, which I believe
> should be a separate feature. Even though it might use the same
> infrastructure, it appears to be a different functionality. I think we
> should focus solely on providing the infrastructure here.

I personally think that it is fine that there are patches which provide
a PoC implementation of the new API. It is hard to verify if an API is
correct if there are zero alternative implementations. And there is also
a case to be made for having one of them in contrib just to make it hard
for us to break the API for external users.

That said I have not made up my mind yet if this is a good extension for
contrib.

> We need to decide on our approach—whether to use a hook-based method
> or a registration-based method—and I believe this requires further
> discussion.

100% agreed.

> The hook-based approach is simple and works well for anyone writing
> their own storage manager. However, it has its limitations as we can
> either use the default storage manager or a custom-built one for all
> the work load, but we cannot choose between multiple storage managers.
> On the other hand, the registration-based approach allows choosing
> between multiple storage managers based on the workload, though it
> requires a lot of changes.
>
> Are we planning to support other storage managers in PostgreSQL in the
> near future? If not, it is better to go with the hook-based approach.
> Otherwise, the registration-based approach is preferable as it offers
> more flexibility to users and enhances PostgreSQL’s functionality.
>
> Could you please share your thoughts on this? Also, let me know if
> this topic has already been discussed and if any conclusions were
> reached.

I do not think there is any plan for core to support multiple storage
managers, but there are open source thrid party extensions which plan to
implement this API once it has been merged.

Andreas