Re: Potential data loss of 2PC files

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Potential data loss of 2PC files
Дата
Msg-id CAB7nPqS0+=OBe_w9FGtdmrqdt6RPWUJMJr_TYXH00UaBxfcoPg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Potential data loss of 2PC files  (Teodor Sigaev <teodor@sigaev.ru>)
Ответы Re: Potential data loss of 2PC files  (Teodor Sigaev <teodor@sigaev.ru>)
Re: Potential data loss of 2PC files  (Teodor Sigaev <teodor@sigaev.ru>)
Список 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 по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: increasing the default WAL segment size
Следующее
От: Alvaro Herrera
Дата:
Сообщение: dsm.c API tweak