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@postgresql.org> wrote in 
> The following bug has been logged on the website:
> 
> Bug reference:      16771
> Logged by:          Bo Chen
> Email address:      bchen90@163.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