Re: recovery modules

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: recovery modules
Date: 2023-01-27 23:31:57
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-01-27 23:55:14 Re: Add n_tup_newpage_upd to pg_stat table views
Previous Message Tom Lane 2023-01-27 23:30:35 Re: heapgettup() with NoMovementScanDirection unused in core?