From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: pgsql-admin@postgresql.org
Subject: Re: Hard link backup strategy
Date: Tue, 31 Mar 2009 14:00:22 +0200
Message-ID: <200903311400.26346@zmi.at> (raw)
In-Reply-To: <49D0B91B.EE98.0025.0@wicourts.gov>
References: <49CB9D8302000025000257DF@gwmta.wicourts.gov>
<200903270843.45051@zmi.at>
<49D0B91B.EE98.0025.0@wicourts.gov>
On Montag 30 März 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
somewhere else. But if process B processes WAL, it still does after the
cp. It is no problem if B reads, A can copy without a problem, even
without the cp before mv. And if B writes to WAL, you have other
problems. And if A deletes WAL, B can still process it as long as it
keeps the file open. So at least for Linux/Unix systems, I don't
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,
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
for your scenario :-)
mfg zmi
--
// 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
Attachments:
signature.asc (application/pgp-signature, 196B) download
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: pgsql-admin@postgresql.org
Cc: michael.monnerie@is.it-management.at
Subject: Re: Hard link backup strategy
In-Reply-To: <200903311400.26346@zmi.at>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox