[Pgpool-general] Replication Flawed?

[Andrew Sullivan]

On Wed, May 17, 2006 at 09:48:32AM -0500, Jim C. Nasby wrote:
> 
> Actually, Continuent's replication solution will look for things like
> now() in commands and replace it with an actual timestamp, so they've
> made some efforts to mitigate the problems with statement-based
> replication. But there's still plenty of issues, which is why I
> generally don't care for it.

That's nifty.  I wasn't aware of that (although it seems to me you're
now paying for parsing at least twice, which might be expensive). 
It's sort of dodgy, though, since the database engine doesn't control
everything that happens in the transaction.  But as long as this is
exposed to the user, I can't see it as a complaint.

It seems to me that you still have potential ordering issues, though,
unless they're actually serialising everything through the central
component (in which case, performance is going to be _really awful_).

> As for OID's in pg_class, the only 'replication' scheme that protects
> against that is PITR.

Well, no.  Hardware-based replication by a disk array, along with
machine-level failover will give you this.  Of course, you only have
one read/write engine running at a time, so there's a performance
hit.  The problem is to match the replication approach with your
problem.  (This is the same reason I get so cranky every time someone
pops up pontificating about how we should have "one" "official"
"built-in" replication system: one size doesn't fit all.)

A

-- 
Andrew Sullivan  | ajs at crankycanuck.ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well. 
		--Dennis Ritchie