Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit dfbaed4

Browse files
committed
Use a fd opened for read/write when syncing slots during startup.
Some operating systems, including the reporter's windows, return EBADFD or similar when fsync() is invoked on a O_RDONLY file descriptor. Unfortunately RestoreSlotFromDisk() does exactly that; which causes failures after restarts in at least some scenarios. If you hit the bug the error message will be something like ERROR: could not fsync file "pg_replslot/$name/state": Bad file descriptor Simply use O_RDWR instead of O_RDONLY when opening the relevant file descriptor to fix the bug. Unfortunately I have no way of verifying the fix, but we've seen similar problems in the past. This bug goes back to 9.4 where slots were introduced. Backpatch accordingly. Reported-By: Patrice Drolet Bug: #13143: Discussion: 20150424101006.2556.60897@wrigleys.postgresql.org
1 parent dcbf594 commit dfbaed4

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

src/backend/replication/slot.c

+1-1
Original file line numberDiff line numberDiff line change
@@ -1092,7 +1092,7 @@ RestoreSlotFromDisk(const char *name)
10921092

10931093
elog(DEBUG1, "restoring replication slot from \"%s\"", path);
10941094

1095-
fd = OpenTransientFile(path, O_RDONLY | PG_BINARY, 0);
1095+
fd = OpenTransientFile(path, O_RDWR | PG_BINARY, 0);
10961096

10971097
/*
10981098
* We do not need to handle this as we are rename()ing the directory into

0 commit comments

Comments
 (0)