Re: Failure while inserting parent tuple to B-tree is not fun

On 02/06/2014 01:54 AM, Peter Geoghegan wrote:
> On Thu, Jan 23, 2014 at 1:36 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>> So while post-recovery callbacks no longer exist for any
>> rmgr-managed-resource, 100% of remaining startup and cleanup callbacks
>> concern the simple management of memory of AM-specific recovery
>> contexts (for GiST, GiN and SP-GiST). I have to wonder if there isn't
>> a better abstraction than that, such as a generic recovery memory
>> context, allowing you to retire all 3 callbacks. I mean, StartupXLOG()
>> just calls those callbacks for each resource at exactly the same time
>> anyway, just as it initializes resource managers in precisely the same
>> manner earlier on. Plus if you look at what those AM-local memory
>> management routines do, it all seems very simple.
>
> What are your thoughts on this, as someone that has a broader
> perspective here? Are you inclined to keep the startup and cleanup
> callbacks in anticipation of a day when that degree of generality is
> useful? That would be pretty well-precedented of course, but I would
> like to hear your opinion.

So, I just removed the rm_safe_restartpoint callback, as that's clearly
dead now and I would complain loudly if someone tried to add a resource
manager that would need it again.

Yeah, it's a bit silly that each resource manager has to do that on
their own. It would be useful to have a memory context that was
automatically reset between each WAL record. In fact that should
probably be the default memory context you run the WAL redo routines in.

But even if we do that, I'm not in a hurry to remove rm_startup/cleanup.
They seem generally useful, even if they're not actually used for much
anymore.

- Heikki