To: "Peter Childs" <peterachilds@gmail.com>
cc: pgsql-performance@postgresql.org
Subject: Re: doubt with pg_dump and high concurrent used databases 
In-reply-to: <a2de01dd0711251115l935fd31n8e7d1526fdb08097@mail.gmail.com> 
References: <4749A6ED.2010005@laotraesquina.com.ar>
	<9D744F5C-08B2-4C85-B06A-1A9FAD533AB6@myemma.com>
	<a2de01dd0711251115l935fd31n8e7d1526fdb08097@mail.gmail.com>
Comments: In-reply-to "Peter Childs" <peterachilds@gmail.com>
	message dated "Sun, 25 Nov 2007 19:15:17 +0000"
Date: Sun, 25 Nov 2007 14:35:27 -0500
Message-ID: <20568.1196019327@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Peter Childs" <peterachilds@gmail.com> writes:
> On 25/11/2007, Erik Jones <erik@myemma.com> wrote:
>>> Does the pg_dump create this kind of "consistent backups"? Or do I
>>> need to do the backups using another program?
>> 
>> Yes, that is exactly what pg_dump does.
>> 
> Yes so long as you are using transactions correctly. Ie doing a begin before
> each invoice and a commit afterwards if your not bothering and using auto
> commit you *may* have problems.

I think you need to qualify that a bit more.  What you're saying is that
if an application has consistency requirements that are momentarily
violated during multi-statement updates, and it fails to wrap such
updates into a single transaction, then pg_dump could capture one of the
intermediate states.  That's true, but it's hardly pg_dump's fault.
If there were a system crash partway through such a sequence, the
consistency requirements would be violated afterwards, too.

			regards, tom lane