From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | pg_basebackup fails if a data file is removed |
Date: | 2012-12-21 13:28:08 |
Message-ID: | 50D463E8.9000000@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
- Heikki
Attachment | Content-Type | Size |
---|---|---|
fix-enoent-in-basebackup.patch | text/x-diff | 2.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2012-12-21 13:30:23 | Re: pg_basebackup fails if a data file is removed |
Previous Message | Paragon Corporation | 2012-12-21 09:06:57 | Re: BUG #7756: When upgrading postgis extension get row is too big: size 9272, maximum size 8160 |