Re: Teach pg_upgrade to deal with invalid databases

Hi,

On Thu, Nov 5, 2026 at 7:25 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> Here is what I have staged for commit, which I'm planning to do soon.

Thanks for taking care of this, and sorry for the delay.

> Thinking ahead to the automatic deletion project, I wonder if we should
> make DROP DATABASE work more like CHECKPOINT. That is, it would mark the
> database for deletion, but another process would do the actual work. That
> way, dropping a database follows the same path every time, regardless of
> whether the DROP command was interrupted. This would also open the door
> for a DROP DATABASE option to initiate the drop without waiting for it to
> complete, although I'm admittedly not sure that has many use-cases.

Interesting. So it's essentially an async drop database. The database
is marked dropped in the catalogs and acked to the client, while
resource removal is deferred to a bg worker. If my understanding is
right, that would need a new mechanism for clients to confirm the
resources (e.g., files) are actually gone and the drop truly
succeeded, which feels like a whole new behavior.

Also, invalid databases are uncommon in practice, so letting a bg
worker (checkpointer, a new custodian worker, or a dynamic worker)
clean up the remains seems like the simpler choice to me.
https://postgr.es/m/20230509040203.z6mvijumv7wxcuib%40awork3.anarazel.de

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com