On Wed, Oct 29, 2025 at 9:47 PM Robert Haas <[email protected]> wrote: > > On Mon, Oct 27, 2025 at 8:22 AM Alena Vinter <[email protected]> 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.
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
