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
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 |