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:33:18 |
Message-ID: | 18331.1104359598@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: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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-12-29 22:36:26 | Re: WARNING: group with ID NNN does not exist |
Previous Message | Tom Lane | 2004-12-29 22:28:36 | Re: debug_print_plan (pg7.4) doesn't seem to do anything |