On Fri, Mar 01, 2019 at 11:38:49AM +1300, Thomas Munro wrote:
> > Food for thought: if we are going to muck with the smgr APIs, would it
> > make sense to move away from SMgrRelation to something a bit more
> > generic like, say, SMgrHandle to better organize the internal contents
> > of this structure? Internally, we could move things into an union and
> > based on type of handle: relation, undo, slru/generic, translate the
> > contents correctly. As you can guess, SMgrRelationData today is very
> > specific to relations and holding md specific information whose memory
> > would be better served re-used for the other storage managers.
> >
> > Thoughts?
>
> Right, it does contain some md-specific stuff without even
> apologising. Also smgropen() was rendered non-virtual at some point
> (I mean that implementations don't even get a chance to initialise
> anything, which works out only because md-specific code has leaked
> into smgr.c). In one of my undo patches (which I'll post an updated
> version of on the appropriate thread soon) I added a void * called
> private_data so that undo_file.c can keep track of some stuff, but
> yeah I agree that more tidying up could be done.
I can send out a patch for this (on a separate thread!) to unblock us
both. Unless you are closer to completion on this.
I prefer the union approach to make it more readable. I was considering
re-factoring the structure to SMgrHandle and having the relation
specific structure retain SMgrRelationData. For undo we could have
SMgrUndoData, and similarly for SLRU (I will come up with a better name
than generic). Then have these be in the union instead of the
individual members of the struct.
--
Shawn Debnath
Amazon Web Services (AWS)
