PostgreSQL Fixes: Updates, Stops and Restores

What's changed

• The Updates tab of a managed PostgreSQL database no longer says A replica scaling operation is in progress forever. A finished scaling record was never closed, so no database could be updated to a newer version; it now closes within about a minute once the database's servers match the count you set, and the tab offers the newer versions again
• A PostgreSQL version update is now recognised as finished once its new servers are ready. Before, it was never confirmed, so it ran into its time limit, which marks the update failed and the database Error although the new version was already serving
• When a database, cache or queue update fails, the Updates history now says what happened in plain words, for example that the backup before the update could not be taken and nothing was changed, instead of showing internal error text
• Stopping a PostgreSQL database now shows Stopping until it has shut down. It used to flip back to Running and then Provisioning for about three minutes before showing Stopped, and a database with open connections can still take about three minutes to stop. A new or restored database also reads Running within seconds of becoming healthy, instead of up to a minute later
• A point-in-time restore to a moment after a quiet database's last change no longer has to wait for the source to write again, as long as the source is running and SQL Studio has been opened in your project before. The restore first commits an empty transaction on the source, which changes no data, so recovery has a later commit to stop at, and the restore timeline says so; if the source cannot be prepared, for example because it is stopped or SQL Studio has not been opened in your project yet, the restore goes ahead as before. Before, such a restore could fail and retry for many minutes
• Removing replicas gives the room back: a PostgreSQL database that had replicas and now has none is no longer refused a new one because of your account's replica limit
• Two databases with the same name in different projects no longer take each other's server entries, which could leave one of them showing no server