Re: recovery modules - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: recovery modules
Date
Msg-id Y9Re7eOm2shoYI1v@paquier.xyz
Whole thread Raw
In response to Re: recovery modules  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
On Thu, Jan 26, 2023 at 09:40:58PM -0800, Nathan Bossart wrote:
> Yeah, there are some problems here.  If we ERROR, we'll just bounce back to
> the sigsetjmp() block once a second, and we'll never pick up configuration
> reloads, shutdown signals, etc.  If we FATAL, we'll just rapidly restart
> over and over.  Given the dicussion about misconfigured archiving
> parameters [0], I doubt folks will be okay with giving priority to one or
> the other.
>
> I'm currently thinking that the checkpointer should set a flag and clear
> the recovery callbacks when a misconfiguration is detected.  Anytime the
> checkpointer tries to use the archive-cleanup callback, a WARNING would be
> emitted.  This is similar to an approach I proposed for archiving
> misconfigurations (that we didn't proceed with) [1].  Given the
> aformentioned problems, this approach might be more suitable for the
> checkpointer than it is for the archiver.

So, by doing that, archive_library would be ignored.  What should be
the checkpointer do when a aconfiguration error is found on
misconfiguration?  Would archive_cleanup_command be equally ignored or
could there be a risk to see it used by the checkpointer?

Ignoring it would be fine as the user intended the use of a library,
rather than enforcing its use via a value one did not really want.
So, on top of cleaning the callbacks, archive_cleanup_command should
also be cleaned up in the checkpointer?  Issuing one WARNING per
checkpoint would be indeed much better than looping over and over,
impacting the system reliability.

Thoughts or comments from anyone?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: heapgettup() with NoMovementScanDirection unused in core?
Next
From: Andres Freund
Date:
Subject: Re: Add n_tup_newpage_upd to pg_stat table views