Re: Potential data loss of 2PC files - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Potential data loss of 2PC files
Date
Msg-id CAB7nPqS0+=OBe_w9FGtdmrqdt6RPWUJMJr_TYXH00UaBxfcoPg@mail.gmail.com
Whole thread Raw
In response to Re: Potential data loss of 2PC files  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: Potential data loss of 2PC files  (Teodor Sigaev <teodor@sigaev.ru>)
Re: Potential data loss of 2PC files  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
On Fri, Mar 24, 2017 at 11:36 PM, Teodor Sigaev <teodor@sigaev.ru> wrote:
>> And the renaming of pg_clog to pg_xact is also my fault. Attached is
>> an updated patch.
>
>
> Thank you. One more question: what about symlinks? If DBA moves, for
> example, pg_xact to another dist and leaves the symlink in data directoty.
> Suppose, fsync on symlink will do nothing actually.

I did not think of this case, but is that really common? There is even
no option to configure that at command level. And surely we cannot
support any fancy scenario that people figure out using PGDATA.
Existing callers of fsync_fname don't bother about this case as well
by the way, take the calls related to pg_logical and pg_repslot.

If something should be done in this area, that would be surely in
fsync_fname directly to centralize all the calls, and I would think of
that as a separate patch, and a separate discussion.
-- 
Michael



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: increasing the default WAL segment size
Next
From: Alvaro Herrera
Date:
Subject: dsm.c API tweak