Re: pg_dump and pgpool

On Wed, 2004-12-29 at 23:12, Greg Stark wrote:
> Scott Marlowe <smarlowe(at)g2switchworks(dot)com> writes:
>
> > 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.
>
> If pgpool is so good at maintaining consistency between databases how did they
> end up with different OIDs?

That's rather disingenuous, considering that OIDs are more of an
internal artifact of the databases, while the USER data stored therein
is what I, or anyone else, would consider the word consistency applies
to. The fact that both databases have different OIDs for the same
objects has nothing to do with the userland data being consistent or
not.

> It seems you really do have inconsistent databases and are asking for pg_dump
> to be robust against that.

No. I have a perfectly consistent database. It happens to reside on a
cluster of two machines which have different internal ids assigned to
the same objects, which, when I throw bog standard SQL at them, I get
the same answer from both. That is consistent. The fact that
PostgreSQL has different OIDs underneath is an implementation quirk that
I, as a user, shouldn't really have to worry about or even notice.
IMHO.

> Wouldn't hiding the
> inconsistency only be doing you a disservice?

If they were inconsistent, then certainly it would. But again, they're
NOT inconsistent. You've built your argument on a false premise.

> I think you should be trying to figure out why the databases are inconsistent
> and working to figure out what you have to change to avoid whatever actions
> caused that.

I shouldn't have to care what the OIDs used internally are.

Users are consistently warned to never use OIDs as PKs, yet PostgreSQL
the database does just that. My data is coherent. I'll explain more in
my reply to Tom Lane...