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
