On Wed, 2004-12-29 at 16:33, Tom Lane wrote:
> 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.
Such as?
> 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.
> 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.
Or is it technically impossible to dump data from PostgreSQL reliably
without relying on OIDs to get the right table at the right time?
