| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | "Peter Childs" <peterachilds(at)gmail(dot)com> | 
| Cc: | pgsql-performance(at)postgresql(dot)org | 
| Subject: | Re: doubt with pg_dump and high concurrent used databases | 
| Date: | 2007-11-25 19:35:27 | 
| Message-ID: | 20568.1196019327@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
"Peter Childs" <peterachilds(at)gmail(dot)com> writes:
> On 25/11/2007, Erik Jones <erik(at)myemma(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pablo Alcaraz | 2007-11-25 22:37:45 | Re: doubt with pg_dump and high concurrent used databases | 
| Previous Message | Peter Childs | 2007-11-25 19:15:17 | Re: doubt with pg_dump and high concurrent used databases |