Re: [PATCH] Re: BUG #16032: pg_basebackup when running on Windows doesn't clean up on failure correctly - Mailing list pgsql-bugs

From Rob Emery
Subject Re: [PATCH] Re: BUG #16032: pg_basebackup when running on Windows doesn't clean up on failure correctly
Date
Msg-id 8b5a4cd5812e2ec1e22ae1d9cc370ab2@mintsoft.net
Whole thread Raw
In response to Re: [PATCH] Re: BUG #16032: pg_basebackup when running on Windowsdoesn't clean up on failure correctly  (Michael Paquier <michael@paquier.xyz>)
List pgsql-bugs
Hiya Michael,

> Regarding your patch, anything living in the middle of processing
> (basically calling disconnect_and_exit() in ~11 and exit() for 12~)
> would fail into this category.  Wouldn't it make sense here to use
> atexit() to ensure that the cleanup always happens?  I am not sure
> that it is a good idea to hope that anything processing the base
> backup COPY chunks will remember to clean up those handles in the
> event of an error.  I am ready to bet that any future code will forget
> to add that so we would keep falling into the same trap.

Yes and no, the problem is that under Windows the file cleanup
occurs before the process itself actually ends, as the streaming of
the backup from the COPY is performed in a thread, not a fork.

So, if we attempt to use atexit to cleanup the filehandles,
pg_basebackup will still be attempting to delete the partial backup
before the file handles are cleaned up by the atexit callback.

I hope that makes sense; I agree with your sentiment that there must
be a better way of structuring this.

-Rob



pgsql-bugs by date:

Previous
From: Komal Sookee
Date:
Subject: Re: BUG #16043: Duplicate Entry Key Message on postgres
Next
From: David Raymond
Date:
Subject: RE: BUG #16031: Group by returns duplicate groups