On Thu, Feb 28, 2019 at 7:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > Motivation: A couple of projects propose to add new smgr
> > implementations alongside md.c in order to use bufmgr.c for more kinds
> > of files, but it seems entirely bogus to extend the unused smgr type
> > to cover those.
>
> I agree that smgrtype as it stands is pretty pointless, but what
> will we be using instead to get to those other implementations?
Our current thinking is that smgropen() should know how to map a small
number of special database OIDs to different smgr implementations
(where currently it hard-codes smgr_which = 0). For example there
would be a pseudo-database for undo logs, and another for the SLRUs
that Shawn Debnath and others have been proposing to move into shared
buffers. Another idea would be to widen the buffer tag to include the
selector. Unlike the ancestral code, it wouldn't need to appear in
catalogs or ever be seen or typed in by users so there still wouldn't
be a use for this type.
--
Thomas Munro
https://enterprisedb.com