Re: Resetting recovery target parameters in pg_createsubscriber

On Mon, Oct 27, 2025 at 8:22 AM Alena Vinter <dlaaren8@gmail.com> wrote:
> Robert, this scenario actually occurred in production at one of our customer environments. Even though this workflow may be uncommon, PostgreSQL should still handle it gracefully. The fact that the server can end up in a state where it cannot start because it fails to reach a recovery target point far in the past suggests a potential area for improvement in the recovery process. It would be helpful if the system could detect such a case — where the recovery target precedes the current consistent point — and either skip recovery or emit a clear diagnostic message rather than failing to start.

The question isn't whether the workflow is common. If something is
broken, we should ideally fix it even if we don't believe that it is
very likely to occur. The question is whether the workflow is
something that a user can reasonably expect to work. If you remove all
of your data files and then complain that the database doesn't work
any more, that's not an indication of a problem with PostgreSQL, but
rather an indication that it's not a good idea to remove all of your
data files. More generally, if you make manual changes to the data
directory and the results are unsatisfactory, we generally consider
that to be an error on your part rather than a problem with
PostgreSQL. You can of course edit configuration files like
postgresql.conf or pg_hba.conf and expect things to work as long as
the resulting configuration file is still valid, but you can't
manually modify pg_control on disk and then call it a bug when
something goes wrong.

In the case at hand, you've offered no justification for why it's OK
to put the server back into recovery at all -- normally, you only put
a server in recovery if you're spinning it up from a backup, which is
not the case in this scenario. I don't really understand why that
would be a valid thing to do, and I even less understand why you
should expect to be able to do it without checking the recovery
configuration and still have things work.

-- 
Robert Haas
EDB: http://www.enterprisedb.com