Re: introduce bufmgr hooks

Thanks for taking a look.

On Tue, Aug 30, 2022 at 01:02:20PM +0900, Kyotaro Horiguchi wrote:
> smgr is an abstract interface originally intended to allow to choose
> one implementation among several (though cannot dynamically). Even
> though the patch intends to replace specific (but most of all) uses of
> the smgrread/write, still it sounds somewhat strange to me to add
> hooks to replace smgr functions in that respect. I'm not sure whether
> we still regard smgr as just an interface, though..

I suspect that it's probably still worthwhile to provide such hooks so that
you don't have to write an entire smgr implementation. But I think you
bring up a good point.

> As for the names, bufmgr_read_hook looks like as if it is additionally
> called when the normal operation performed by smgrread completes, or
> just before. (planner_hook already doesn't sounds so for me, though:p)
> "bufmgr_alt_smgrread" works for me but I'm not sure it is following
> the project policy.

Yeah, the intent is for this hook to replace the smgrread() call (although
it might end up calling smgrread()). I debated having this hook return
whether smgrread() needs to be called. Would that address your concern?

> I think that the INSTR_* section should enclose the hook call as it is
> still an I/O operation in the view of the core.

Okay, will do.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com