recovery modules
От | Nathan Bossart |
---|---|
Тема | recovery modules |
Дата | |
Msg-id | 20221227192449.GA3672473@nathanxps13 обсуждение исходный текст |
Ответы |
Re: recovery modules
|
Список | pgsql-hackers |
I've attached a patch set that adds the restore_library, archive_cleanup_library, and recovery_end_library parameters to allow archive recovery via loadable modules. This is a follow-up to the archive_library parameter added in v15 [0] [1]. The motivation behind this change is similar to that of archive_library (e.g., robustness, performance). The recovery functions are provided via a similar interface to archive modules (i.e., an initialization function that returns the function pointers). Also, I've extended basic_archive to work as a restore_library, which makes it easy to demonstrate both archiving and recovery via a loadable module in a TAP test. A few miscellaneous design notes: * Unlike archive modules, recovery libraries cannot be changed at runtime. There isn't a safe way to unload a library, and archive libraries work around this restriction by restarting the archiver process. Since recovery libraries are loaded via the startup and checkpointer processes (which cannot be trivially restarted like the archiver), the same workaround is not feasible. * pg_rewind uses restore_command, but there isn't a straightforward path to support restore_library. I haven't addressed this in the attached patches, but perhaps this is a reason to allow specifying both restore_command and restore_library at the same time. pg_rewind would use restore_command, and the server would use restore_library. * I've combined the documentation to create one "Archive and Recovery Modules" chapter. They are similar enough that it felt silly to write a separate chapter for recovery modules. However, I've still split them up within the chapter, and they have separate initialization functions. This retains backward compatibility with v15 archive modules, keeps them logically separate, and hopefully hints at the functional differences. Even so, if you want to create one library for both archive and recovery, there is nothing stopping you. * Unlike archive modules, I didn't add any sort of "check" or "shutdown" callbacks. The recovery_end_library parameter makes a "shutdown" callback largely redundant, and I couldn't think of any use-case for a "check" callback. However, new callbacks could be added in the future if needed. * Unlike archive modules, restore_library and recovery_end_library may be loaded in single-user mode. I believe this works out-of-the-box, but it's an extra thing to be cognizant of. * If both the library and command parameter for a recovery action is specified, the server should fail to startup, but if a misconfiguration is detected after SIGHUP, we emit a WARNING and continue using the library. I originally thought about emitting an ERROR like the archiver does in this case, but failing recovery and stopping the server felt a bit too harsh. I'm curious what folks think about this. * Іt could be nice to rewrite pg_archivecleanup for use as an archive_cleanup_library, but I don't think that needs to be a part of this patch set. [0] https://postgr.es/m/668D2428-F73B-475E-87AE-F89D67942270%40amazon.com [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5ef1eef -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: