On 7/4/2007 10:52 AM, Christopher Browne wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 7/3/2007 12:33 PM, Christopher Browne wrote:
"Andrew Hammond" <[EMAIL PROTECTED]> writes:
Also, ISTM that the big reason we don't like statement based
replication is that SQL has many non-deterministic aspects. However,
there is probably a pretty darn big subset of SQL which is provably
non-deterministic. And for that subset, would it be any less
rigorous to transmit those statements than to transmit the per-row
change statments like we currently do?
Well, by capturing the values, we have captured a deterministic form
of the update.
How to figure out what is deterministic and what isn't? A simple
insert into summary select id, sum(value) from detail group by id;
seems pretty deterministic, doesn't it? But the result of it depends
on the exact commit order and the transaction isolation level. We
don't capture the commit order of single transactions, nor do we care
for it anywhere in the Slony-I logic.
But at the time that we apply these changes in log_actionseq order, we
have imposed a deterministic order. (Which happens to be repeatable,
on each node.)
The question was, how do we figure out which SQL statement would be
deterministic and thus a candidate for SQL query string propagation -
aside from the fact that there is no standard way in Postgres to capture
query strings or parsetrees anyway. So far we have only established that
the logging of the changes has to be done the way we are doing it now,
on a row base where the actionseq determines the repeatable order. I
don't see how going through a lot of effort to group those individual
log rows together again will gain us a lot.
Unless the effort also attempts to group together consecutive insert and
update statements affecting the same columns and using prepared
statements, and unless we have some evidence that doing so will gain
more than the effort of all that grouping costs, I don't think it is a
good idea to make that part of remote_worker.c any more complicated than
it is today. How many developers do we have who actually understand how
that part of slon really works and who could go in and fix some bug in
there?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
