Dear Bharath,
> I'm attaching 0002 patch (on top of v45) which implements the new
> decodable callback approach that I have in mind. IMO, this new
> approach is extensible, better than the current approach (hard-coding
> of certain WAL records that may be generated during pg_upgrade) taken
> by the patch, and helps deal with the issue that custom WAL resource
> managers can have with the current approach taken by the patch.
Thanks for sharing your PoC! I tested yours and worked well. I have also made
the decoding approach locally, but your approach is conceptually faster. I think
it still checks the type one by one so not sure the acceptable, but at least
checkings are centerized. We must hear opinions from others. How do other think?
Comments for your patch. I attached the txt file, please include if it is OK.
1.
According to your post, we must have comments to notify developers that
is_decodable API must be implemented. Please share it too if you have idea.
2.
The existence of is_decodable should be checked in RegisterCustomRmgr().
3.
Anther rmgr API (rm_identify) requries uint8 without doing a bit operation:
they do "info & ~XLR_INFO_MASK" in the callbacks. Should we follow that?
4.
It is helpful for developers to add a function to test_custom_rmgrs module.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED