Hi Otto,
Ok, so I setup something in Buildbot.
Whenever something is pushed to git://github.com/ottok/mariadb-5.5.git,
Buildbot will do a build in two VMs: trusty amd64 and sid amd64.
You need to configure your repository to send notifications to Buildbot for
this to take effect (I tested with
Hi, Tan Tran.
Your patch is quite correct.
I just don't think the 'internal_stop_logging' and 'mark_always_logged'
lines
are superfluous in this case.
And there are 2 more variables that don't effectively change it's value
until restart logging.
So i modified the patch with all that, it's
Hi Kristian,
First of all thanks for the great on-list explanations of your parallel
replication features. It looks as if you are making good progress on a
very hard problem.
Second, this is slightly off-topic but can you expand somewhat on the
semantics of group-committed transactions in the
Otto Kekäläinen o...@seravo.fi writes:
Change the line
3902 time git-buildpackage --git-pristine-tar --git-notify=false
--git-pbuilder --git-dist=trusty --git-arch=amd64
to
3902 time git-buildpackage --git-pristine-tar --git-notify=false
Ok, I did that, we will see how it goes.
Buildbot is
Robert Hodges robert.hod...@continuent.com writes:
a.) It seems logical that transactions within a group commit should appear
together in the binlog and should be serialized before and after other
transactions in the binlog. Is there *any* way this ordering could be
violated, for example to
Hi Kristian,
Thanks for the prompt and detailed response!
I’m glad you clarified that GTIDs cannot ever walk backwards. It’s really bad
design if they are not monotonically increasing and comparable. This will
really help restart logic in a number of places, not just for your own
AFAIK, timestamp for a binlog event is the time when corresponding
statement started to execute. The order of statements in the binlog is
according to the time when statements were committed, which of course
doesn't have anything to do with the time statement started to execute.
That's why
Hi Pavel,
On March 14, 2014 at 9:09:47 AM, Pavel Ivanov (piva...@google.com) wrote:
AFAIK, timestamp for a binlog event is the time when corresponding statement
started to execute. The order of statements in the binlog is according to the
time when statements were committed, which of course
8 matches
Mail list logo
