New rmgr stuff looks interesting. I've had a detailed look through it and tried to think about how it might be used in practice.
Spotted a minor comment that needs adjustment for new methods... [PATCH: rmgr_001.v1.patch] I notice rm_startup() and rm_cleanup() presume that this only works in recovery. If recovery is "not needed", there is no way to run anything at all, which seems wrong because how do we know that? I would prefer it if rm_startup() and rm_cleanup() were executed in all cases. Only 4 builtin index rmgrs have these anyway, and they are all quick, so I suggest we run them always. This allows a greater range of startup behavior for rmgrs. [PATCH: rmgr_002.v1.patch] It occurs to me that any use of WAL presumes that Checkpoints exist and do something useful. However, the custom rmgr interface doesn't allow you to specify any actions on checkpoint, so ends up being limited in scope. So I think we also need an rm_checkpoint() call - which would be a no-op for existing rmgrs. [PATCH: rmgr_003.v1.patch] The above turns out to be fairly simple, but extends the API to something truly flexible. Please let me know what you think? -- Simon Riggs http://www.EnterpriseDB.com/
rmgr_002.v1.patch
Description: Binary data
rmgr_001.v1.patch
Description: Binary data
rmgr_003.v1.patch
Description: Binary data
