On Tue, Apr 9, 2019 at 2:12 PM Haribabu Kommi <kommi.harib...@gmail.com> wrote: > I got the same doubt when i looked into some of the UNDO patches > where it tries to modify the core code to add UNDO specific WAL types. > Different AM's may need different set of operations to be WAL logged, > so it may be better for the AM's to register their own types?
In the current undo proposal, the undo subsystem itself needs an rmgr ID for WAL-logging of some low level undo log management records (ie its own record types), but then any undo-aware AM would also need to have its own rmgr ID for its own universe of WAL records (its own types, meaningful to it alone), and that same rmgr ID is used also for its undo records (which themselves have specific types). That is, in rmgrlist.h, an undo-aware AM would register not only its redo function (called for each WAL record in recovery) but also its undo function (called when transaction roll back, if your transaction generated any undo records). Which raises the question of how a hypothetical undo-aware AM could deal with undo records if it's using generic WAL records. I haven't thought about that. A couple of ideas we've bounced around to allow extensions to work with specific WAL records: (1) a community-wide registry of rmgr IDs (basically, just allocate the IDs for all known extensions in a header in the tree, like IANA), or (2) a per-cluster registry scheme where an extension, identified by its name, would be permanently allocated an rmgr number and library + callback functions for the lifetime of that cluster. Or something like that. -- Thomas Munro https://enterprisedb.com
