Re: Potential data loss of 2PC files

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/

In response to

Responses

Browse pgsql-hackers by date

  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