Re: PoC: Simplify recovery after dropping a table by LOGGING the restore LSN

On 15/10/2026 16:26, Salma El-Sayed wrote:
> But in this exact scenario, didn't the database become invalid?
> postgres=# \c db
> connection to server on socket "/tmp/.s.PGSQL.5435" failed: FATAL:
> cannot connect to invalid database "db"
> HINT: Use DROP DATABASE to drop invalid databases.
>
> The LSN value itself is fine to recover to. The problem is the word
> "dropped," since the drop did not actually complete.

Right, this is how I see it too. Stating that the database was dropped
while it is still there (valid or not) isn't ideal.

On top of what Zsolt pointed out:

== new warning ==

postgres=# drop database db;
ERROR: canceling statement due to statement timeout
WARNING: DROP DATABASE "db" (OID 16393) did not complete; the database
may be left invalid and require DROP DATABASE to be run again
HINT: Files belonging to this database may already have been removed.
To recover data from before this attempt, use recovery_target_lsn =
'0/10276790' with recovery_target_inclusive = false.

This warning is now sent to the client, and I have mixed feelings about
it. If a cancelled drop database should tell the user that the database
was left invalid, that's useful whether or not this GUC is set, and it
belongs in a separate patch, not behind log_object_drops. While I
understand the motivation behind it, I'd argue that it should be logged
only in the server -- the user most likely cannot act on it anyway :)
But it is just my opinion.

Also, the primary message is quite long (two clauses). I recommend
taking a look at the error style guide[1]

Thanks for working on this!

Best, Jim

1 - https://www.postgresql.org/docs/18/error-style-guide.html