From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: pg_basebackup fails if a data file is removed |
Date: | 2012-12-21 13:30:23 |
Message-ID: | CABUevExf8D+pVYujONG3ipvoc=7DyhiB18+SOiMokB4+gDwq-A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Dec 21, 2012 at 2:28 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> When pg_basebackup copies data files, it does basically this:
>
>> if (lstat(pathbuf, &statbuf) != 0)
>> {
>> if (errno != ENOENT)
>> ereport(ERROR,
>> (errcode_for_file_access(),
>> errmsg("could not stat file or directory
>> \"%s\": %m",
>> pathbuf)));
>>
>> /* If the file went away while scanning, it's no error. */
>> continue;
>> }
>
>> ...
>> sendFile(pathbuf, pathbuf + basepathlen + 1, &statbuf);
>
> There's a race condition there. If the file is removed after the lstat call,
> and before sendFile opens the file, the backup fails with an error. It's a
> fairly tight window, so it's difficult to run into by accident, but by
> putting a breakpoint with a debugger there it's quite easy to reproduce, by
> e.g doing a VACUUM FULL on the table about to be copied.
>
> A straightforward fix is to allow sendFile() to ignore ENOENT. Patch
> attached.
Looks good to me. Nice spot - don't tell me you actually ran into it
during testing? :)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2012-12-21 13:38:10 | Re: pg_basebackup fails if a data file is removed |
Previous Message | Heikki Linnakangas | 2012-12-21 13:28:08 | pg_basebackup fails if a data file is removed |