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

From: Rob Emery <postgresql(at)mintsoft(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Re: BUG #16032: pg_basebackup when running on Windows doesn't clean up on failure correctly
Date: 2019-10-07 15:52:41
Message-ID: 8b5a4cd5812e2ec1e22ae1d9cc370ab2@mintsoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David Raymond 2019-10-07 18:29:04 RE: BUG #16031: Group by returns duplicate groups
Previous Message Komal Sookee 2019-10-07 13:40:14 Re: BUG #16043: Duplicate Entry Key Message on postgres