Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file
От | Magnus Hagander |
---|---|
Тема | Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file |
Дата | |
Msg-id | CABUevEyTHVWOmvyjkDVbJbkWUObGhCTBf=1TM0soa21DdnT2RQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING
file
|
Список | pgsql-bugs |
On Mon, Aug 22, 2016 at 3:42 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Mon, Aug 22, 2016 at 10:17 PM, Magnus Hagander <magnus@hagander.net> > wrote: > > Not having looked in detail, but in pgwin32_safestat(), if the stat() > call > > fails, we return immediately without calling _dosmaperr(), don't we? So > > we're still going to error out there with whatever the default mapping > is, > > and that's access denied. > > > > It's only if the the stat() call succeeds but the getting of extended > > attributes fail that we actually call _dosmaperr(). > > Meh, you're right. How stupid I am here. So we could just reuse the > first block of your patch when checking for (r < 0), but drop the > second part that complicates GetFileAttributesEx if win32error.c gets > completed for _dosmaperr as my last patch does, right? > Yeah, that seems correct. And I agree that it's cleaner to do it in _dosmaperr() than to do it in the individual locations. > By the way, in your patch you really need to > s/STATUS_DELETE_PENDING/ERROR_DELETE_PENDING or compilation just > fails. > Hah. Yeah, that patch was coded-without-compiling as a poc of how to do it. Would've definitely needed a round of testing before applying :) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-bugs по дате отправления: