Re: [patch] pg_copy - a command for reliable WAL archiving

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, MauMau <maumau307(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] pg_copy - a command for reliable WAL archiving
Date: 2014-08-19 19:52:47
Message-ID: 53F3AB0F.8030406@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/19/2014 12:37 PM, Peter Eisentraut wrote:
> On 8/19/14 9:35 AM, MauMau wrote:
>> pg_copy is for copying a file reliably by syncing. If sync is not
>> necessary, people can use cp/copy.
>
> I'm getting mixed messages from this thread.
>
> I think there could be a fair amount of support for a new tool that can
> serve as a universal plug-and-play archive_command, with a variety of
> options, such as fsync yes/no, fadvise yes/no, direct-io[*] yes/no,
> atomic copy yes/no, allow overwrite yes/no, compression yes/no. That
> would reduce the need for users to compose adventurous shell commands,
> and it would set out the various options more clearly.

Yes please!

Although I'm not sold on the idea of using DirectIO for this. Is there
really enough benefit to make it worth the trouble?

>
> This is not that. This is cp+fsync with a hardcoded fadvise policy and
> optional direct-io. That is a valid problem to address, but it is one
> of many. On the other hand, I fear that the addition of this
> single-and-a-half-purpose tool would make the overall landscape more
> complicated than it already is. Since it's in the examples, people will
> probably use it, even if they don't need to or shouldn't. And not
> recommending it for the restore_command is also confusing.

I'm afraid that I agree with Peter here. pg_copy looks like a nice
foundation for the eventual pg_copy utility we need, but it's not there yet.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2014-08-19 20:24:20 Re: 9.3: more problems with "Could not open file "pg_multixact/members/xxxx"
Previous Message Stephen Frost 2014-08-19 19:47:17 Re: PQgetssl() and alternative SSL implementations