On 02/06/2014 01:54 AM, Peter Geoghegan wrote:
On Thu, Jan 23, 2014 at 1:36 PM, Peter Geoghegan <p...@heroku.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
