[Bugs] [Bug 1512691] PostgreSQL DB Restore: unexpected data beyond EOF

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1512691



--- Comment #37 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: https://review.gluster.org/20428 committed in master by "Raghavendra G"
<rgowdapp at redhat.com> with a commit message- performance/ob: stringent
synchronization between rename/unlink and open

Issue 1:
========
open all pending fds before resuming rename and unlink

currently ob uses fd_lookup to find out the opened-behind. But,
fd_lookup gives the recent fd opened on the inode, but the oldest
fd(s) (there can be multiple fds opened-behind when the very first
opens on an inode are issued in parallel) are the candidates for fds
with pending opens on backend. So, this patch explictily tracks the
opened-behind fds on an inode and opens them before resuming rename or
unlink.

similar code changes are also done for setattr and setxattr to make
sure pending opens are complete before permission change.

This patch also adds a check for an open-in-progress to
ob_get_wind_fd. If there is already an open-in-progress,
ob_get_wind_fd won't return an anonymous fd as a result. This is done
to make sure that rename/unlink/setattr/setxattr don't race with an
operation like readv/fstat on an anonymous fd already in progress.

Issue 2:
========
once renamed/unlinked, don't open-behind any future opens on the same
inode.

Issue 3:
========
Don't use anonymous fds by default. Note that rename/unlink can race
with a read/fd on anonymous fds and these operations can fail with
ESTALE. So, for better consistency in default mode, don't use
anonymous fds. If performance is needed with tradeoff of consistency,
one can switch on the option "use-anonymous-fd"

Change-Id: Iaf130db71ce61ac37269f422e348a45f6ae6e82c
Signed-off-by: Raghavendra G <rgowdapp at redhat.com>
Updates: bz#1512691

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=cH5G4YdJfc&a=cc_unsubscribe