Re: pg_dump and pgpool

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_dump and pgpool
Date: 2004-12-29 22:56:05
Message-ID: 18519.1104360965@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Scott Marlowe <smarlowe(at)g2switchworks(dot)com> writes:
> On Wed, 2004-12-29 at 16:33, Tom Lane wrote:
>> I'd worry about
>> synchronization issues to start with...

> I am not worried about that. As long as I'm not doing things like
> inserting random() into the database, the data in the two backend stores
> is coherent.

For sufficiently small values of "coherent", sure, but I am not prepared
to buy into the notion that pg_dump cannot examine the database contents
more closely than the stupidest user application will ;-).

Also, let's play devil's advocate and assume that the master and slave
*have* managed to get out of sync somehow. Do you want your backup to
be a true picture of the master's state, or an unpredictable
amalgamation of the master and slave states? Heaven help you if you
need to use the backup to recover from the out-of-sync condition.

>> I don't think we should make pg_dump slower and possibly less reliable
>> in order to support a fundamentally dangerous administration procedure.
>> Run pg_dump directly into the database, not through pgpool.

> What makes you think this would be slower. If anything, it would be
> faster or as fast, since we're throwing fewer queries and at the same
> time, hiding the implementation details that OIDs are.

No, we'd be throwing more, and more complex, queries. Instead of a
simple lookup there would be some kind of join, or at least a lookup
that uses a multicolumn key.

There are also correctness issues to think about. OID *is* the primary
key on most of the system catalogs pg_dump is looking at, and not all of
them have other unique keys. Doing anything useful with pg_depend or
pg_description without explicitly looking at OIDs would be darn painful,
too.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2004-12-29 23:07:20 Re: pg_dump and pgpool
Previous Message Matthew Terenzio 2004-12-29 22:49:37 Fwd: Advice on moving rows to history