Re: [HACKERS] pg_dump, pg_dumpall and data durability - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] pg_dump, pg_dumpall and data durability
Date
Msg-id CA+TgmoZzZ1fJLfb3BNRRoN2zbWT1-FpWjXTSSgQPaXonVF2D5g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_dump, pg_dumpall and data durability  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] pg_dump, pg_dumpall and data durability  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] pg_dump, pg_dumpall and data durability  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
On Thu, Mar 2, 2017 at 5:02 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Thu, Mar 2, 2017 at 2:26 AM, David Steele <david@pgmasters.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [BUGS] Seems bug in postgres_fdw?
Next
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] Logical replication existing data copy