Re: silent data loss with ext4 / all current versions
От | Robert Haas |
---|---|
Тема | Re: silent data loss with ext4 / all current versions |
Дата | |
Msg-id | CA+TgmoYKmj0zGu76NPbmuXfVvf2tu3KxbRqnSV4qRcyT2oL9Tw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: silent data loss with ext4 / all current versions (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Thu, Mar 17, 2016 at 11:03 AM, Andres Freund <andres@anarazel.de> wrote: > On 2016-03-17 23:05:42 +0900, Michael Paquier wrote: >> > Are you working on a fix for pg_rewind? Let's go with initdb -S in a >> > first iteration, then we can, if somebody is interest enough, work on >> > making this nicer in master. >> >> I am really -1 for this approach. Wrapping initdb -S with >> find_other_exec is intrusive in back-branches knowing that all the I/O >> write operations manipulating file descriptors go through file_ops.c, >> and we actually just need to fsync the target file in >> close_target_file(), making the fix being a 7-line patch, and there is >> no need to depend on another binary at all. The backup label file, as >> well as the control file are using the same code path in file_ops.c... >> And I like simple things :) > > This is a *much* more expensive approach though. Doing the fsync > directly after modifying the file. One file by one file. Will usually > result in each fsync blocking for a while. > > In comparison of doing a flush and then an fsync pass over the whole > directory will usually only block seldomly. The flushes for all files > can be combined into very few barrier operations. Yeah, I'm pretty sure this was discussed when initdb -S went in. I think reusing that is a good idea. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: