public inbox for [email protected]  

help / color / mirror / Atom feed

From: Peter Eisentraut <[email protected]>
To: Bruce Momjian <[email protected]>
Cc: Josh Kupershmidt <[email protected]>
Cc: Greg Smith <[email protected]>
Cc: Euler Taveira de Oliveira <[email protected]>
Cc: [email protected]
Subject: Re: somewhat wrong archive_command example
Date: Wed, 29 Aug 2012 21:57:28 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAK3UJRHChOcGQ0kzu01wZX6PB9pScHSzg1X+hThdR7QXWoe1yw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Mon, 2012-08-27 at 09:46 -0400, Bruce Momjian wrote:
> I thought the idea was just to show what a shell script might look like
> --- we could say it does the same as a single-line copy, but then people
> could improve it, or we could add a comment to show how people could
> improve it.

Why can't we provide the improved version to begin with, if we know it
needs improvement?  I think we don't really know what it should look
like, do we?

> I am actually unclear how the partial copy problem would not be fixed by
> just using cp without -i < /dev/null.

Sure, that would do it, but elsewhere we also say that the command
should guard against overwriting existing files.  That's a safety
measure against overwriting existing archives due to configuration
mistakes, which is fair enough.  So there is still something that needs
refining.  Either

- We don't care about the partial copy problem, or

- We don't care about the overwriting existing archives issue, or

- We make the copy quasi-atomic using mktemp + mv (could also use the
"install" program, I think), or

- We make the file names absolutely unique by adding the system ID or a
UUID of some kind.

> > I think what we should do is write a wrapper program in C that covers
> > all the bases, support all platforms, and supports a handful of the most
> > commonly used copy methods (cp, scp, etc. + compression).  Then everyone
> > can just use that and doesn't have to figure all these things out from
> > scratch every time.
> 
> I doubt it would work because people like the flexibility of shell
> scripts.

Well, we thought that about the base backup, but now we have
pg_basebackup, which supports two output methods that should cover most
cases.  If we could provide an archive command that has two or three
methods, that could also cover most uses.  Of course, in either case you
are free to write your own script.

view thread (24+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: somewhat wrong archive_command example
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox