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-30 15:20:28 |
Message-ID: | 26218.1104420028@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:
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-12-30 15:36:41 | Re: pg_dump and pgpool |
Previous Message | Tatsuo Ishii | 2004-12-30 14:50:31 | Re: pg_dump and pgpool |