Re: pg_dump and pgpool - Mailing list pgsql-general

From Tom Lane
Subject Re: pg_dump and pgpool
Date
Msg-id 26218.1104420028@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:
>> I don't think it's worth that price to support a fundamentally bogus
>> approach to backup.

> But it's not bogus.  IT allows me to compare two databases running under
> a pgpool synchronous cluster and KNOW if there are inconsistencies in
> data between them, so it is quite useful to me.

As a data comparison tool it is certainly bogus.  What about different
row ordering between the two databases, for instance?

AFAICS this could only work if you were doing physical rather than
logical replication (eg, shipping WAL logs) in which case the OIDs would
be just as much in sync as everything else.

Basically my point is that you are proposing to do a lot of work in
order to solve the first problem you are running up against, but that
will only get you to the next problem.  I'm not prepared to accept a
significant increase in complexity and loss of maintainability in
pg_dump in order to move one step closer to the dead end that you will
certainly hit.

            regards, tom lane

pgsql-general by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: pg_dump and pgpool
Next
From: Tatsuo Ishii
Date:
Subject: Re: pg_dump and pgpool