Scott Marlowe <[EMAIL PROTECTED]> writes:
> I'm certainly willing to do the vast majority of the work. As Greg I
> think mentioned, maybe a fresh start using the information_schema would
> make sense as a sort of non-pg specific backup tool or something.
This is a dead end.
First, the informatio
> On Thu, 2004-12-30 at 09:20, Tom Lane wrote:
> > Scott Marlowe <[EMAIL PROTECTED]> 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 sync
On Thu, 2004-12-30 at 09:20, Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> 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 cluste
On Thu, 2004-12-30 at 09:46, Tatsuo Ishii wrote:
> > On Wed, 2004-12-29 at 17:30, Tom Lane wrote:
> > > Scott Marlowe <[EMAIL PROTECTED]> writes:
> > > > On Wed, 2004-12-29 at 16:56, Tom Lane wrote:
> > > >> No, we'd be throwing more, and more complex, queries. Instead of a
> > > >> simple lookup
Scott Marlowe <[EMAIL PROTECTED]> writes:
> On Wed, 2004-12-29 at 23:12, Greg Stark wrote:
> > Scott Marlowe <[EMAIL PROTECTED]> 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,
> On Wed, 2004-12-29 at 17:30, Tom Lane wrote:
> > Scott Marlowe <[EMAIL PROTECTED]> writes:
> > > On Wed, 2004-12-29 at 16:56, Tom Lane wrote:
> > >> No, we'd be throwing more, and more complex, queries. Instead of a
> > >> simple lookup there would be some kind of join, or at least a lookup
> >
Scott Marlowe <[EMAIL PROTECTED]> 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
On Wed, 2004-12-29 at 17:30, Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
> > On Wed, 2004-12-29 at 16:56, Tom Lane wrote:
> >> No, we'd be throwing more, and more complex, queries. Instead of a
> >> simple lookup there would be some kind of join, or at least a lookup
> >> that uses
On Wed, 2004-12-29 at 23:12, Greg Stark wrote:
> Scott Marlowe <[EMAIL PROTECTED]> 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 differ
Scott Marlowe <[EMAIL PROTECTED]> 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 consisten
Scott Marlowe <[EMAIL PROTECTED]> writes:
> On Wed, 2004-12-29 at 16:56, Tom Lane wrote:
>> No, we'd be throwing more, and more complex, queries. Instead of a
>> simple lookup there would be some kind of join, or at least a lookup
>> that uses a multicolumn key.
> I'm willing to bet the performan
On Wed, 2004-12-29 at 16:56, Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
> > On Wed, 2004-12-29 at 16:33, Tom Lane wrote:
> >> 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(
Scott Marlowe <[EMAIL PROTECTED]> writes:
> On Wed, 2004-12-29 at 16:33, Tom Lane wrote:
>> 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
> i
On Wed, 2004-12-29 at 16:33, Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> 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
Scott Marlowe <[EMAIL PROTECTED]> 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 tabl
On Wed, 2004-12-29 at 16:11, Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
> > I've noticed today that if one tries to pg_dump a database cluster
> > running under pgpool, one gets the error message:
>
> > pg_dump: query to get table columns failed: ERROR: kind mismatch
> > between
Scott Marlowe <[EMAIL PROTECTED]> writes:
> I've noticed today that if one tries to pg_dump a database cluster
> running under pgpool, one gets the error message:
> pg_dump: query to get table columns failed: ERROR: kind mismatch
> between backends
> HINT: check data consistency between master a
I've noticed today that if one tries to pg_dump a database cluster
running under pgpool, one gets the error message:
pg_dump: query to get table columns failed: ERROR: kind mismatch
between backends
HINT: check data consistency between master and secondary
Looking at the SQL that pg_dump sends
18 matches
Mail list logo
