Re: DROP DATABASE is interruptible

Hi,

On 2023-05-09 15:41:36 +1200, Thomas Munro wrote:
> I tried out the patch you posted over at [1].

Thanks!

> $ psql db2
> psql: error: connection to server on socket "/tmp/.s.PGSQL.5432"
> failed: FATAL: database "db2" is invalid
> DETAIL: Use DROP DATABASE to drop invalid databases
>
> I suppose it should be a HINT?

Yup.

> +# FIXME: It'd be good to test the actual interruption path. But it's not
> +# immediately obvious how.
>
> I wonder if there is some way to incorporate something based on
> SIGSTOP signals into the test, but I don't know how to do it on
> Windows and maybe that's a bit weird anyway. For a non-OS-specific
> way to do it, I was wondering about having a test module function that
> has a wait loop that accepts ^C but deliberately ignores
> ProcSignalBarrier, and leaving that running in a background psql for a
> similar effect?

Seems a bit too complicated.

We really need to work at a framework for this kind of thing.

> Not sure why the test is under src/test/recovery.

Where else? We don't really have a place to put backend specific tests that
aren't about logical replication or recovery right now...

It partially is about dealing with crashes etc in the middle of DROP DATABASE,
so it doesn't seem unreasonble to me anyway.

> While a database exists in this state, we get periodic autovacuum
> noise, which I guess we should actually skip?

Yes, good catch.

Also should either reset datfrozenxid et al when invalidating, or ignore it
when computing horizons.

> I suppose someone might eventually wonder if autovacuum could complete the
> drop, but it seems a bit of a sudden weird leap in duties and might be
> confusing (perhaps it'd make more sense if 'invalid because creating' and
> 'invalid because dropping' were distinguished).

I'm bit hesitant to do so for now. Once it's a bit more settled, maybe?
Although I wonder if there's something better suited to the task than
autovacuum.

Greetings,

Andres Freund