On 12-10-11 06:27 PM, Josh Berkus wrote:
On 10/10/12 7:26 PM, Bruce Momjian wrote:
How does Slony write its changes without causing serialization replay
conflicts?
Since nobody from the Slony team answered this:
a) Slony replicates *rows*, not *statements*
True, but the proposed logical replication also would replicate rows not
the original statements. I don't consider this proposal to be an
example of 'statement' replication like pgpool is. If the original
SQL was 'update foo set x=x+1 where id > 10'; there will be a WAL
record to decode for each row modified by the table. In a million row
table I'd expect the replica will have to apply a million records
(whether they be binary heap tuples or SQL statements).
b) Slony uses serializable mode internally for row replication
Actually recent versions of slony apply transactions against the replica
in read committed mode. Older versions used serializable mode but with
the SSI changes in 9.1 we found slony tended to have serialization
conflicts with itself on the slony internal tables resulting in a lot of
aborted transactions.
When slony applies changes on a replica table it does so in a single
transaction. Slony finds a set of transactions that committed on the
master in between two SYNC events. It then applies all of the rows
changed by any of those transactions as part of a single transaction on
the replica. Chris's post explains this in more detail.
Conflicts with user transactions on the replica are possible.
c) it's possible (though difficult) for creative usage to get Slony into
a deadlock situation
FWIW, I have always assumed that is is impossible (even theoretically)
to have statement-based replication without some constraints on the
statements you can run, or some replication failures. I think we should
expect 9.3's logical replication out-the-gate to have some issues and
impose constraints on users, and improve with time but never be perfect.
The design Andres and Simon have advanced already eliminates a lot of
the common failure cases (now(), random(), nextval()) suffered by pgPool
and similar tools. But remember, this feature doesn't have to be
*perfect*, it just has to be *better* than the alternatives.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
