|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Nathan Bossart <nathandbossart(at)gmail(dot)com>|
|Cc:||Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: recovery modules|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2023-01-27 15:28:21 -0800, Nathan Bossart wrote:
> The more I think about this, the more I wonder whether we really need to
> include archive_cleanup_command and recovery_end_command in recovery
I think it would be hard to write a good module that isn't just implementing
the existing commands without it. Needing to clean up archives and reacting to
the end of recovery seems a pretty core task.
> Another weird thing with the checkpointer is that the restore_library will
> stay loaded long after recovery is finished, and it'll be loaded regardless
> of whether recovery is required in the first place.
I don't see a problem with that. And I suspect we might even end up there
for other reasons.
I was briefly wondering whether it'd be worth trying to offload things like
archive_cleanup_command from checkpointer to a different process, for
robustness. But given that it's pretty much required for performance that the
module runs in the startup process, that ship probably has sailed.
|Next Message||Amin||2023-01-28 00:11:26||Re: How to find the number of cached pages for a relation?|
|Previous Message||Andres Freund||2023-01-27 23:55:14||Re: Add n_tup_newpage_upd to pg_stat table views|