From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: pgsql-admin@postgresql.org
Subject: Re: Hard link backup strategy
Date: Tue, 31 Mar 2009 14:00:22 +0200
User-Agent: KMail/1.10.3 (Linux/2.6.28.9-ZMI; KDE/4.1.3; x86_64; ; )
References: <49CB9D8302000025000257DF@gwmta.wicourts.gov>
	<200903270843.45051@zmi.at> <49D0B91B.EE98.0025.0@wicourts.gov>
In-Reply-To: <49D0B91B.EE98.0025.0@wicourts.gov>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2097606.ARh95m9hFk";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200903311400.26346@zmi.at>

--nextPart2097606.ARh95m9hFk
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Montag 30 M=E4rz 2009 Kevin Grittner wrote:
> I don't want anything to attempt to process a WAL file while it is in
> the process of being copied.  By copying to a separate directory on
> the same mount point and moving it, once complete, to the location
> where other software is looking for WAL files, we avoid that problem.

Hm. So process A copies the WAL to dir1, then moves dir1/WAL to=20
somewhere else. But if process B processes WAL, it still does after the=20
cp. It is no problem if B reads, A can copy without a problem, even=20
without the cp before mv. And if B writes to WAL, you have other=20
problems. And if A deletes WAL, B can still process it as long as it=20
keeps the file open. So at least for Linux/Unix systems, I don't=20
understand the benefits of cp before mv.

> PostgreSQL version has nothing to do with it.  PostgreSQL segments a
> table into 1GB files.  Our largest tables are are either "insert
> only" or rarely have updates or deletes

OK, that's the reason. Our db's have lots of updates/deletes everywhere,=20
that's why I didn't think about it.

> Basically, the hard links will be used to conserve disk space; rsync
> will be used to conserve network bandwidth.

Yes, that can make sense if the 1GB parts don't change a lot. Good idea=20
for your scenario :-)

mfg zmi
=2D-=20
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4


--nextPart2097606.ARh95m9hFk
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAknSBdoACgkQzhSR9xwSCbTkQgCgpzmrEPxBAXFEx5P3EShhC0oK
1e8AoIoWdm1NDhFbso9lcbM8G7ysdu8A
=A9qq
-----END PGP SIGNATURE-----

--nextPart2097606.ARh95m9hFk--