From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Potential data loss of 2PC files |
Date: | 2017-03-27 16:34:31 |
Message-ID: | ffa95209-ce28-bc9a-9774-3a8e1f19510e@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thank you, pushed
Michael Paquier wrote:
> On Fri, Mar 24, 2017 at 11:36 PM, Teodor Sigaev <teodor(at)sigaev(dot)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.
>
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-03-27 16:35:50 | Re: crashes due to setting max_parallel_workers=0 |
Previous Message | Ashutosh Sharma | 2017-03-27 16:34:30 | Re: segfault in hot standby for hash indexes |