pg_basebackup fails if a data file is removed

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

Responses

Browse pgsql-bugs by date

  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