Hi Jim and Zsolt, On Fri, Oct 16, 2026 at 12:25 AM Zsolt Parragi <[email protected]> wrote: > > If a backend crashes between them the callback doesn't run and we are > left with an invalid database without logging it. > > You can reproduce this by stopping the drop at the > 'dropdb-after-invalid-marker' injection point and killing the backend.
Thanks, I was able to reproduce it. I don't think the callback can cover this case at all, since nothing runs in the backend after it dies. The only option I could think of was logging the lsn with a neutral message right after we capture it, before the database is marked invalid. I tried it and I don't think it's a good fit. At that point we don't know if the drop will succeed, so the message can only say the drop is starting. We would still need the callback afterwards to log the real outcome, so every DROP DATABASE would log two messages, and after a crash the user would only have the neutral one and would need to check pg_database to find out what actually happened. What makes DROP DATABASE harder than DROP TABLE is that it marks the database invalid before doing work it can't roll back, so a failed or crashed drop can leave the database broken. So I'd like to remove DROP DATABASE from this patch and keep it to DROP TABLE and TRUNCATE TABLE, which was the original scope. DROP DATABASE could be handled separately in another patch. What do you think? On Fri, Oct 16, 2026 at 3:18 PM Jim Jones <[email protected]> wrote: > > 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. > I agree. Warning that a cancelled DROP DATABASE left the database invalid is a separate issue from log_object_drops and should be its own patch. > > Also, the primary message is quite long (two clauses). I recommend > taking a look at the error style guide[1] > Thanks. That message goes away with DROP DATABASE, but I'll go through the style guide and apply it to the DROP TABLE and TRUNCATE messages in the next version. Best regards, Salma Elsayed
