Re: pg_dump and pgpool - Mailing list pgsql-general

From Tom Lane
Subject Re: pg_dump and pgpool
Date
Msg-id 18331.1104359598@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump and pgpool  (Scott Marlowe <smarlowe@g2switchworks.com>)
Responses Re: pg_dump and pgpool  (Scott Marlowe <smarlowe@g2switchworks.com>)
List pgsql-general
Scott Marlowe <smarlowe@g2switchworks.com> writes:
> On Wed, 2004-12-29 at 16:11, Tom Lane wrote:
>> I would like to know exactly what pgpool has done to break pg_dump.

> What's happening is that there are two databases behind pgpool, and each
> has managed to assign a different (set of) OID(s) to the table(s).  So,
> when pg_dump asks for an OID, it gets two different ones.

Mph.  I'd have zero confidence in a dump taken under such circumstances,
anyway.  If pgpool can't duplicate OIDs (which I agree it probably
can't) then it's unlikely to be able to make the databases match closely
enough to satisfy pg_dump in other ways.  I'd worry about
synchronization issues to start with...

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.

            regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: debug_print_plan (pg7.4) doesn't seem to do anything
Next
From: Tom Lane
Date:
Subject: Re: WARNING: group with ID NNN does not exist