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
