diff options
| author | Andres Freund <andres@anarazel.de> | 2015-04-28 00:12:38 +0200 |
|---|---|---|
| committer | Andres Freund <andres@anarazel.de> | 2015-04-28 00:17:43 +0200 |
| commit | dfbaed459754e71e01bb0cc90a12802bba3f9786 (patch) | |
| tree | e321306e7c21bcc290fb03c989a0fed634d4ef85 | |
| parent | dcbf5948e12aa60b4d6ab65b6445897dfc971e01 (diff) | |
| download | postgresql-dfbaed459754e71e01bb0cc90a12802bba3f9786.tar.gz postgresql-dfbaed459754e71e01bb0cc90a12802bba3f9786.zip | |
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
| -rw-r--r-- | src/backend/replication/slot.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c index fa1f07b3f3e..d2e18423746 100644 --- a/src/backend/replication/slot.c +++ b/src/backend/replication/slot.c @@ -1092,7 +1092,7 @@ RestoreSlotFromDisk(const char *name) elog(DEBUG1, "restoring replication slot from \"%s\"", path); - fd = OpenTransientFile(path, O_RDONLY | PG_BINARY, 0); + fd = OpenTransientFile(path, O_RDWR | PG_BINARY, 0); /* * We do not need to handle this as we are rename()ing the directory into |