Re: pg_dump, pg_dumpall and data durability

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: David Steele <david(at)pgmasters(dot)net>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump, pg_dumpall and data durability
Date: 2017-03-04 06:08:58
Message-ID: CA+TgmoZzZ1fJLfb3BNRRoN2zbWT1-FpWjXTSSgQPaXonVF2D5g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 2, 2017 at 5:02 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Thu, Mar 2, 2017 at 2:26 AM, David Steele <david(at)pgmasters(dot)net> wrote:
>> This patch is in need of a committer. Any takers?
>> I didn't see a lot of enthusiasm from committers on the thread
>
> Stephen at least has showed interest.
>
>> so if nobody picks it up by the end of the CF I'm going to mark the patch RWF.
>
> Yes, that makes sense. If no committer is willing to have a look at
> code-level and/or has room for this patch then it is as good as
> doomed. Except for bug fixes, I have a couple of other patches that
> are piling up so they would likely get the same treatment. There is
> nothing really we can do about that.

Before we reach the question of whether committers have time to look
at this, we should first consider the question of whether it has
achieved consensus. I'll try to summarize the votes:

Tom Lane: premise pretty dubious
Robert Haas: do we even want this?
Peter Eisentraut: I had voiced a similar concern [to Robert's] previously
Albe Laurenz: I think we should have that
Andres Freund: [Tom's counterproposal won't work]
Robert Haas: [Andres has a good point, still nervous] I'm not sure
there's any better alternative to what's being proposed, though.
Fujii Masao: One idea is to provide the utility or extension which
fsync's the specified files and directories

Here's an attempt to translate those words into numerical votes. As
per my usual practice, I will count the patch author as +1:

Michael Paquier: +1
Tom Lane: -1
Peter Eisentraut: -1
Albe Laurenz: +1
Andres Freund: +1
Robert Haas: +0.5
Fujii Masao: -0.5

So, my interpretation is that, out of 7 votes, we have -2.5 and +3.5.
Perhaps that is a consensus for proceeding, but if so it's a pretty
marginal one. I think the next step for this patch is to consider why
we shouldn't, in lieu of what's proposed here, add a pg_fsync utility
that fsyncs a file or recursively fsyncs a directory, ship that, and
let people use it on their pg_dump files and/or base backups if they
wish. I am not altogether convinced that's a better option, but I am
also not altogether convinced that it's worse. Also, if anyone else
wishes to vote, or if anyone to whom I've attributed a vote wishes to
assign a numerical value to their vote other than the one I've
assigned, please feel free.

The issue with this patch isn't that nobody is interested, but that
not everybody thinks it's a good idea.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2017-03-04 06:11:21 Re: Logical replication existing data copy
Previous Message Robert Haas 2017-03-04 05:52:09 Re: [BUGS] Seems bug in postgres_fdw?