From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug in slot.c and are replication slots ever used at Window? |
Date: | 2018-08-31 18:46:47 |
Message-ID: | 20180831184647.GC5305@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Konstantin,
On Thu, Aug 30, 2018 at 11:27:31AM -0700, Michael Paquier wrote:
> It seems to me that you are right here, "path" points to
> pg_replslot/$SLOTNAME/state which is a file so the fsync is incorrect.
> I am not sure that we'd want to publish fsync_parent_path out of fd.c
> though, so perhaps we could just save the slot path in a different
> variable and use it?
I have spent more time on this bug, and the code path you have pointed
at is the only one having such an issue. Attached is a patch to fix the
problem. It includes the sanity checks I have used to check all code
paths calling fsync_fname() for both the frontend and the backend code.
The checks will not be included in the final fix, still they look useful
so I am planning to start a new thread on the matter as perhaps other
folks have more and/or better ideas.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
slotpath_sync.patch | text/x-diff | 2.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-08-31 19:55:51 | Re: pg_verify_checksums and -fno-strict-aliasing |
Previous Message | Michael Paquier | 2018-08-31 18:10:08 | Re: BUG #15346: Replica fails to start after the crash |