On Wed, Oct 29, 2025 at 9:47 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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
workflowmay be uncommon, PostgreSQL should still handle it gracefully. The fact that the server can end up in a state
whereit cannot start because it fails to reach a recovery target point far in the past suggests a potential area for
improvementin the recovery process. It would be helpful if the system could detect such a case — where the recovery
targetprecedes the current consistent point — and either skip recovery or emit a clear diagnostic message rather than
failingto 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.
Can we see this from the different prospective? pg_createsubscriber
is intended to turn physical replica into a logical replica. And it
leaves subscriber database cluster with rudimentary configuration
options needed purely for its intermediate step. Whatever usage
scenario is, user might deleted these extra options if needed. This
is not a big deal. However, it's certainly cleaner for
pg_createsubscriber to avoid leaving this options (especially if their
appearance is not documented).
------
Regards,
Alexander Korotkov
Supabase
