Re: [HACKERS] Potential data loss of 2PC files

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Potential data loss of 2PC files
Дата
Msg-id 20161227113142.tug4v2bhq5lv7zen@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Potential data loss of 2PC files  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] Potential data loss of 2PC files  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
On 2016-12-27 14:09:05 +0900, Michael Paquier wrote:
> On Fri, Dec 23, 2016 at 3:02 AM, Andres Freund <andres@anarazel.de> wrote:
> > Not quite IIRC: that doesn't deal with file size increase.  All this would be easier if hardlinks wouldn't exist
IIUC.It's basically a question whether dentry, inode or contents need to be synced.   Yes, it sucks.
 
>
> I did more monitoring of the code... Looking at unlogged tables and
> empty() routines of access methods, isn't there a risk as well for
> unlogged tables? mdimmedsync() does not fsync() the parent directory
> either!

But the files aren't created there, so I don't generally see the
problem.  And the creation of the metapages etc. should be WAL logged
anyway.  So I don't think we should / need to do anything special
there.  You can argue however that we wouldn't necessarily fsync the
parent directory for the file creation, ever.  But that'd be more
smgrcreate's responsibility than anything.


> We could do that at checkpoint as well, actually, by looping through
> all the tablespaces and fsync the database directories.

That seems like a bad idea, as it'd force fsyncs on unlogged tables and
such.

Regards,

Andres



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Declarative partitioning - another take
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Support for pg_receivexlog --format=plain|tar