Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel

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.
>