Re: BUG #16771: Server process killed by signal 9, after recovery drop tablespace failed

Hello.

At Fri, 11 Dec 2020 11:34:47 +0000, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote in
> The following bug has been logged on the website:
>
> Bug reference: 16771
> Logged by: Bo Chen
> Email address: bchen90(at)163(dot)com
> PostgreSQL version: 11.8
> Operating system: euleros v2r7 x86_64
> Description:
>
> hi
>
> I encounter a problem of drop tablespace failed for reasion 'tablespace is
> not empty'. The problem occurs in the following scenarios:
>
> I start a transaction to create some table located in an alreaedy created
> tablespace, before the transaction commits, the process of creating data is
> killed by somebady with signal 9. when the database recoveried I try to drop
> the tablesapce, it failed for 'tablespace is not empty'.
>
> Does this bug need to be resolved ?

It seems to be a known behavior that hasn't been fixed for a long time.

It comes from a mechanism in PostgreSQL called "pending deletes", by
which deletion of underlynig files is delayed until commit/abort
time. Since the "to-be-deleted at abort" infomation is not persistent,
it should be lost if the server crashed before the transaction ends.

I happend to be proposing a patch [*1] for another issue and I
realized that the approach could solve this issue as well.

*1: https://www.postgresql.org/message-id/20201225.091252.53717619425847881.horikyota.ntt%40gmail.com

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center