> >* Getting truncate MVCC safe
> >* Getting system tables MVCC safe
>
> Can you elaborate on how these two relate to clustering?
Well, the second is not so vital anymore with the introduction of
session_replication_role, but making updates in a safe matter
on older versions of Postgres requires mucking around with the
system catalogs, which (unless you actually lock the tables,
a non-starter), leads to problems.
Getting truncate MVCC safe would make life much easier, as
truncate is so much faster than delete when doing a bulk update
of a replicated table.
> >Perhaps, but there seems to be very little overlap in the things I
> >work on (async replication) versus some of the other solutions
> >(esp. built-in and synchronous ones)
>
> Spotting the common issues/modules is one of the reasons why we get
> (or got) together.
>
> For example, I'm interested in the conflict resolution logic of
> Bucardo. I plan to add something akin for Postgres-R to reduce the
> amount of transactions that need to be aborted.
Well, it's all open source for the looking. :) Here's a quick summary.
Basically, Bucardo supports two types of conflict resolution: standard
and custom. The standard includes a handful of default rules about which
side (let's call them A and B) should "win" in a conflict. Options
include 'source' (A), 'target' (B), 'latest' (who made the most recent
change), and 'random' (call it a really weird form of load balancing :).
The custom handlers are much more interesting, as it can incroporate
business logic. Basically, you write a perl subroutine that gets fed
information about the current conflict and returns a code indicating
which side should win. The passed in information also includes handles
to both sides, so that you can query other tables, and even update
the rows in conflict directly. I don't know if any of that is really
applicable to something like Postgres-R, but maybe that's one of the
things we can talk about.
--
Greg Sabino Mullane greg@endpoint.com
End Point Corporation
PGP Key: 0x14964AC8