Re: Some other things about contrib/bloom and generic_xlog.c

On Tue, Apr 12, 2016 at 3:08 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> 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