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 |
Date: | 2023-01-28 00:09:39 |
Message-ID: | 20230128000939.yxyoerpe4dstfgfm@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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
> modules.
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.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
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 |