Re: pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)
Дата
Msg-id CAB7nPqS2gDYDQkGRNvqjp5-=tRa63boQ9Ck-8VeAk1V-Z7z0pw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
On Tue, Sep 27, 2016 at 11:16 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 9/23/16 11:15 AM, Michael Paquier wrote:
>>> 0002:
>>> >
>>> > durable_rename needs close(fd) in non-error path (compare backend code).
>> Oops, leak.
>
> Why did you remove the errno save and restore?

That's this bit in durable_rename, patch 0002:
+        if (fsync(fd) != 0)
+        {
+            fprintf(stderr, _("%s: could not fsync file \"%s\": %s\n"),
+                    progname, newfile, strerror(errno));
+            close(fd);
+            return -1;
+        }
+        close(fd);
I thought that as long as the error string is shown to the user, it
does not matter much if errno is still saved or not. All the callers
of durable_rename() on frontends don't check for strerrno(errno)
afterwards. Do you think it matters? Changing that back is trivial.
Sorry for not mentioning directly in the thread that I modified that
when dropping the last patch set.
-- 
Michael



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Password identifiers, protocol aging and SCRAM protocol
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: pageinspect: Hash index support