From: Peter Childs <peterachilds@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: doubt with pg_dump and high concurrent used databases
Date: Mon, 26 Nov 2007 10:41:24 +0000
Message-ID: <a2de01dd0711260241m3debd932sa8a82b0238d6e48@mail.gmail.com> (raw)
In-Reply-To: <4749F939.7090107@laotraesquina.com.ar>
References: <4749A6ED.2010005@laotraesquina.com.ar>
<9D744F5C-08B2-4C85-B06A-1A9FAD533AB6@myemma.com>
<a2de01dd0711251115l935fd31n8e7d1526fdb08097@mail.gmail.com>
<20568.1196019327@sss.pgh.pa.us>
<4749F939.7090107@laotraesquina.com.ar>
On 25/11/2007, Pablo Alcaraz <pabloa@laotraesquina.com.ar> wrote:
>
> Tom Lane wrote:
> > "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.
> >
> >
>
> Agree. In my case I define "consistent database state" like the state
> the database has when the program that use it is stopped normally and
> without errors. In this "state" the program starts without troubles and
> "everything looks fine". I believe this behavior is because all the
> inserts and updates are made using transactions. Another things will be
> a bug, it ll be fixed and it ll not be pg_dump fault.
>
> So if pg_dump can capture a "consistent state" with all the data until
> the start time, without all the pending open transaction updates/inserts
> in the same way that I did when I stopped the program before start
> pg_dump, for me is usefull and enough to solve my problem.
>
> Thanks to all!
>
> Pablo
>
>
Given your long description over what you though was "constant" I thought it
important that the answer yes but was given rather than just a plain yes.
I've met quite a few apps that create inconstant databases when the
database its self is actually consistent.
Peter
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-performance@postgresql.org
Cc: peterachilds@gmail.com
Subject: Re: doubt with pg_dump and high concurrent used databases
In-Reply-To: <a2de01dd0711260241m3debd932sa8a82b0238d6e48@mail.gmail.com>
* 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