What I thought we should be able to do with that should not be only limited to indexes, aka to: - Be able to register and log full pages - Be able to log data associated to a block - Be able to have record data - Use at recovery custom routines to apply those WAL records The first 3 ones are done via the set of routines generating WAL records for the rmgr RM_GENERIC_ID. The 4th one needs a hook in generic_redo. Looking at the thread where this patch has been debated I am not seeing a discussion regarding that.
I've designed generic xlog under following restrictions:
- We don't want users to register their own redo functions since it could affect reliability. Unfortunately, I can't find original discussion now.
- API should be as simple as possible for extension author.
However, I think we should add some way for custom redo functions one day. If we will add pluggable storage engines (I hope one day we will), then we would face some engines which don't use our buffer manager. For such pluggable storage engines, current generic WAL wouldn't work, but user-defined redo functions would.
Now, my view is that we will need kind of two-phase recovery in order to provide user-defined redo functions:
1) In the first phase, all built-in objects are recovered. After this phase, we can use system catalog.
2) In the second phase, user-defined redo functions are called on the base of consistent system catalog.
I think we can implement such two-phase recovery even now on the base of generic logical messages. We can create logical slot. When extension is loaded it starts second phase of recovery by reading generic logical messages from this logical slot. Logical slot position should be also advanced on checkpoint.
------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
