Re: Drop type "smgr"?
От | Thomas Munro |
---|---|
Тема | Re: Drop type "smgr"? |
Дата | |
Msg-id | CA+hUKG+VeoBJkonRjUeFpHpBkw7ZY5j3rc8FJzcDfxCytpk7ng@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Drop type "smgr"? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Drop type "smgr"?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: