Hi Brandon,
The test failure in https://jira.mariadb.org/browse/MDEV-28776 (the one with
10 failed retries after deadlock, not the freebsd failures) seems like it
could be something serious. But it has been very difficult to track down. I
believe you have tried different things, and I also tried h
Hi Marko,
I'd like to ask your opinion/review of the below patch for MDEV-31482:
https://github.com/MariaDB/server/commit/dbe5c20b755b87f67d87990c3baabc87e41b
https://jira.mariadb.org/browse/MDEV-31482
As you know, in-order parallel replication has InnoDB report lock waits. If
T1 mu
Hi Marko,
I'd like to ask you to review the below patch for MDEV-31655.
https://jira.mariadb.org/browse/MDEV-31655
https://github.com/MariaDB/server/commit/cb06612a9da09a7981ada84768793f2ff3ef842c
This patch restores code in InnoDB that was originally part of the parallel
replication implem
Brandon Nesterenko via developers writes:
> That sounds like a good idea to me. Did you mean to use the option for
Thanks Brandon.
I actually now managed to reproduce the failure once, after several days
running on the buildbot machines. I'll see if I can get any progress that
way, otherwise I'
Kristian Nielsen writes:
> I actually now managed to reproduce the failure once, after several days
> running on the buildbot machines. I'll see if I can get any progress that
> way, otherwise I'll try to push this patch (it will have to be done to all
I was able to solve this by running on the
Andrei via developers writes:
>> The root cause of these failures is MDEV-31655,
>> https://jira.mariadb.org/browse/MDEV-31655. Sad that this serious bug was
>> actually visible as test failures in the CI for years without being fixed.
>> What can we do to improve this in the future?
> always a
Sergei Golubchik via developers writes:
> There's a compromise approach - mariadb-upgrade is required (and thus
> downgrade does not work) between major versions, but mariadb-upgrade is
> not needed (and downgrade works) between minor versions.
I agree with this approach.
- Kristian.
_
Marko Mäkelä via developers writes:
> For
> better testing of this, I think that we really need a 10.6 based
> branch that contains both this and MDEV-31482.
I did an initial merge to 10.6. The victim selection code is in
Deadlock::report() in lock0lock.cc.
I noticed one thing in the current 10
Marko Mäkelä writes:
> On Sun, Aug 6, 2023 at 6:59 PM Kristian Nielsen
> wrote:
>> If so, seems there's a small mistake in the code. The current condition will
>> always be true for each new value of victim, so trx_pos will always be set
>> != 0. The first condition should probably have been "
Kristian Nielsen via developers writes:
> (For in-order parallel replication itself, the deadlock detection problem is
> much simpler, because we _know_ that any T_(i+1) will eventually have to
> wait for T_(i). So a deadlock will occur if-and-only-if there is some T_j
> that waits f
Kristian Nielsen via developers writes:
> I'm thinking it will be rare to have the same value of
> (undo_no + LENGTH(lock.trx_locks)) for two transactions, which is the only
> way this code can trigger. But I'm not familiar with the original reason for
> this piece of
Marko Mäkelä writes:
> On Fri, Aug 25, 2023 at 10:16 AM Kristian Nielsen via commits
> wrote:
>> Checksums cannot be pre-computed when binlog encryption is enabled, as
> Have you thought about a format change that would address these issues?
What I though about was how to pre-encrypt without
Marko Mäkelä writes:
> I am successfully using a dirty trick like this:
> static SHOW_VAR innodb_status_variables[]= {
> …
> {"ibuf_merges", &ibuf.n_merges, SHOW_SIZE_T},
> …
> {NullS, NullS, SHOW_LONG}
> };
>
> The underlying C-style cast simply assumes that the
> Atomic_counter can be read
I am implementing Binlog GTID Indexes, to fix an old performance regression
for GTID when slaves connect to the master. I now have a solid design and a
working prototype, so I wanted to describe the work to encourage early
comments and suggestions.
I'm hoping this will make it to the next release
Kristian Nielsen writes:
> From: Sergei Golubchik
> @@ -2724,6 +2725,10 @@ bool Item_func_encode::seed()
>hash_password(rand_nr, key->ptr(), key->length());
>sql_crypt.init(rand_nr);
>
> + push_warning_printf(thd, Sql_condition::WARN_LEVEL_WARN,
> ER_WARN_DEPRECATED_SYNTAX,
> +
Kristian Nielsen via developers writes:
> If you want to give a warning for these functions, then you need to create
> an SQL mode or some other handle for the DBA to disable the warning and keep
> their application running. And the warning should explain why it's there,
Ah, we h
Sergei Golubchik via developers writes:
> And yes, we expect her to rewrite the application before we read on
I think this is the core of the problem:
"we expect her to rewrite the application"
No, "we" have no such expectation. And if you do, then you have become too
far removed from the us
Sergei Golubchik via developers writes:
> But I definitely don't want any *new* application, written after 2023,
> to use ENCODE/DECODE. This is what the warning is for.
This is of course agreed.
https://lists.mariadb.org/hyperkitty/list/comm...@lists.mariadb.org/thread/UAKPM7C3NQHCXT7ILI2YH
Here is a case in point about the problem with unnecessary deprecation
warnings. It's not just me ;-):
https://mariadb.com/kb/en/suppress-mariadb-11-deprecation-warnings/
Is there a way to prevent deprecation warnings from appearing when
executing the 'mysql' and 'mysqldump' commands? There
Hi Sergei,
Sergei Golubchik writes:
> You've said that it's unclear how the release model works, when we
> release what and where a feature can go.
>
> I've documented the current release model in the knowledge base,
> https://mariadb.com/kb/en/mariadb-release-model/
> would you like to take a l
Sergei Golubchik writes:
> I've also created another page,
> https://mariadb.com/kb/en/mariadb-quality-development-rules/
Ok, thanks for the other link.
>> > https://mariadb.com/kb/en/mariadb-release-model/
>> > would you like to take a look and see if it answers your questions?
One detail I n
Hi Monty,
[Following up on review on IRC]
Kristian Nielsen via commits writes:
> Replace Log_event::writer with just passing the writer object as a
> function parameter to Log_event::write().
We wondered how the compiled code will look when passing the writer object
as a parameter to Log_event
Hi Monty,
Lots of good comments, thanks! Replies inline:
Michael Widenius writes:
> enum enum_binlog_checksum_alg
>
> In c++ we can drop the first 'enum'
> You can fix that by doing:
Ack, will fix.
> event.select_checksum_alg()
>
> This is called a lot. Would it not be easier to store the ch
Hi Serg,
I came upon this commit by you:
> commit 6b685ea7b0776430d45b095cb4be3ef0739a3c04
> Author: Sergei Golubchik
> Date: Wed Sep 28 18:55:15 2022 +0200
>
> correctness assert
>
> thd_get_ha_data() can be used without a lock, but only from the
> current thd thread, when c
Kristian Nielsen via developers writes:
> If it is just so that we can have this assertion, then that needs to be
> rolled back. We _really_ don't want to take/release N mutexes in release
> builds during LOCK_commit_ordered, just to have an assertion in debug
> builds.
I m
Sergei Golubchik writes:
>> Note that at this point, the group commit leader thread _is_
>> effectively acting as if it was each of the participating threads, the
>> other threads are blocked from running during commit_ordered.
>
> I'm not sure it's good enough. Practically it might work, but if
Kristian Nielsen writes:
Hi Andrei,
> commit 96bd9e6b780f3738b5008b89aae6b0b086f15943
> Author: Andrei
> Date: Sat Aug 19 19:49:25 2023 +0300
> XA-Prepare group of events
>
> XA START xid
> ...
> XA END xid
> XA PREPARE xid
>
> and its XA-"complete" terminator
>
> XA COMMIT or
>
Michael Widenius via developers writes:
> MDEV-31273: Refactor MYSQL_BIN_LOG::write_cache()
>>if (likely(length > LOG_EVENT_HEADER_LEN))
> The above can be replaced with:
>
> if (my_b_read(cache, header, LOG_EVENT_HEAD_LENGTH))
> goto error_in_read;
Agree, that's better, done.
Michael Widenius via developers writes:
> DBUG_RETURN(my_b_copy_to_cache(from_cache, to_cache, SIZE_T_MAX));
>
> You could use from_cache->end_of_file instead of SIZE_T_MAX
Fixed.
> uchar checksum_opt;
>
> Wouldn't it be better to have this as an "enum_binlog_checksum_alg" to
> avoid some
> ca
Stein Vidar Hagfors Haugan via developers
writes:
> So I am considering to contribute with a patch that will eliminate all
> sprintf() instances by converting them to snprintf(destination, N,
> ...). Of course, hunting down the correct N for each instance can be a
> *lot* of work (I presume this
Hi Marko,
Thanks for the patch. It looks good, just a few small comments inline.
Approved after fixing the check for !is_relay_log.
I have pushed an extra commit on top of bb-10.4-MDEV-32673 with a testcase
(feel free to squash it onto your commit). The tests pass with your patch
(but fails witho
Hi Monty,
> From: Michael Widenius
>
> commit 7abf83f86829ed94de618af4749eb96d5379bd90 (origin/bb-10.6-monty)
> Author: Michael Widenius
> Date: Wed Nov 8 16:57:58 2023 -0700
>
> MDEV-32551: "Read semi-sync reply magic number error" warnings on master
I read through the patch, looks good. A f
Hi Monty, here is my review of the patch for MDEV-31404:
> commit d51086a9f1b1b6a66c7ba8eb6a6876b433fa118f (origin/bb-11.4-MDEV-31404)
> Author: Monty
> Date: Sun Dec 3 21:42:44 2023 +0200
>
> MDEV-31404 Implement binlog_space_limit
>
> binlog_space_limit is a variable in Percona
Hi Monty,
Michael Widenius writes:
>> Two suggestions to make it easier for the DBAs to know how to handle this:
>>
>> 1. How about emitting a note or warning in the error log, if purge from
>> --log-expire-days=N gets delayed for more than 2*N because no slaves are
>> connected and --slave-conn
Sergei Golubchik writes:
> as you know, I've cherry-picked all your 11.4 features into one branch
> to assemble a preview release 11.4.0
Thanks, Serg!
> This has required some fixes to make buildbot greener.
Thanks. I think buildbot was not active on 11.4 branches when I tried
earlier, but now
Hi Monty,
As promised, here my thoughts around the issues with the implementation of
replication of external XA as implemented since MariaDB 10.5.
I see at least two architectural issues with the current implementation.
One is that it splits transactions in two separate GTIDs in the binlog (XA
andrei.el...@pp.inet.fi writes:
> Back in Aug I wrote a patch that converts XA:s to normal transactions at
> binlogging.
I don't think I saw that patch, but it sounds like exactly what I am
proposing as an alternate solution... ?
> Notice, that an initialization part of failover 'the few
> tr
> commit c37b2087b4abe576f1b0391c8d379dba6299dcb5 (origin/bb-11.4-MDEV-7850)
> Author: Brandon Nesterenko
> Date: Mon Jul 10 18:53:19 2023 +0300
>
> MDEV-7850: Extend GTID Binlog Events with Thread Id
>
> This patch augments Gtid_log_event with the user thread-id.
> In particul
This way, the value will be consistent with the Query_event (historically,
there used to be a BEGIN query event in place of the GTID event, which
provided the thread id for row events; MDEV-7850 is the desire to have that
back).
- Kristian.
Kristian Nielsen via devel
As we are discussing possible problems with XA parallel replication being
slow or hanging in 10.6, I just want to remind of these recently fixed bugs:
MDEV-31482: Lock wait timeout with INSERT-SELECT, autoinc, and
statement-based replication
This can cause slow or hanging parallel replicati
Brandon Nesterenko writes:
> I always appreciate learning the history of why some things exist as they
> are :)
Oh yes, there's a _lot_ of history in the replication code...
> is logged. Reading the whole comment really solidified it. I'll incorporate
> your feedback.
Thanks Brandon!
I think g
Hi Andrei,
It's not an easy review of the XA patches in bb-10.6-MDEV-31949.
One thing that would have helped is a clear design document that lists all
the different concerns and points that need to be considered around
recovery, backup, replication, possible conflicts, etc. This could then be
ref
Hi Andrei,
Here next part of my review.
First, I want to try to really explain a general problem I see several
places in these patches, here is one example:
> -static XID_cache_element *xid_cache_search(THD *thd, XID *xid)
> +XID_cache_element *xid_cache_search(THD *thd, XID *xid)
> {
>DBUG
Andrei via developers writes:
> So you're in this context
>
> 1 innobase_commit_by_xid(
> 18 thd_binlog_pos(thd, &trx->mysql_log_file_name,
> 19&trx->mysql_log_offset);
> 20 if (trx->mysql_log_offset > 0)
> 21 trx->flush_log_later = true;
Hi Andrei,
Here is the last part of my review of the changes in branch bb-10.6-MDEV-31949:
> --- a/sql/log_event_server.cc
> +++ b/sql/log_event_server.cc
> @@ -3324,6 +3324,11 @@ Gtid_log_event::Gtid_log_event(THD *thd_arg, uint64
> seq_no_arg,
>flags2|= thd->lex->sql_command == SQLCOM_
andrei.el...@pp.inet.fi writes:
> I see now that alternatively thd_binlog_format(thd) could be used
> which will always
>
> return BINLOG_FORMAT_UNSPEC when that's the case (or @@skip_log_bin=1).
>
> You think it's better to covert the block to use that?
I think it's better to define a proper A
Andrei Elkin writes:
> > I think it's better to define a proper API for this.
>
> It feels an overkill in the current case.
"Define a proper API" means that you think through how this should work for
different storage engines and TC_LOG implementations. And then you document
those thoughts.
Hi Marko,
I looked a bit more at the idea that we have discussed a couple times, of
storing the binlog in an InnoDB tablespace to avoid the need for two-phase
commit between binlog and InnoDB and save one (or potentially both) fsync()s
during a commit.
I managed to get some InnoDB code written th
Marko Mäkelä writes:
> I think that what you have written so far should be useful for an
> initial feasibility study, for measuring the performance. We do not
> need recovery to actually work when running the initial tests. I
Yes, agree. Thanks for your comments, it's good to know that I'm on th
As was discussed recently off-list, there is a desire to find a minimal fix
to the performance issues in 10.6 with parallel replication of user XA due
to non-optimal scheduling (MDEV-31949).
How about something like this two-patch series? It _only_ modifies the
scheduling of event groups to worker
Keep track of each recently active XID, recording which worker it was queued
on. If an XID might still be active, choose the same worker to queue event
groups that refer to the same XID to avoid conflicts.
Otherwise, schedule the XID freely in the next round-robin slot.
This way, XA PREPARE can n
When choosing the scheduling bucket for the next event group in
rpl_parallel_entry::choose_thread(), use an explicit FIFO for the
round-robin selection instead of a simple cyclic counter i := (i+1) % N.
This allows to schedule XA COMMIT/ROLLBACK dependencies explicitly without
changing the round-r
Kristian Nielsen via developers writes:
> The XA COMMIT will normally be scheduled on the same worker as the XA
> PREPARE, unless the two events are far apart in the replication stream. This
> is mostly unavoidable in the current XA replication design, since the XA
> PREPARE and XA
Marko Mäkelä writes:
> Hi Kristian,
>
> On Mon, Feb 26, 2024 at 8:31 PM Kristian Nielsen
> wrote:
>> > I would tweak the log checkpoint to ensure that all pages of the
>> > "previous" binlog tablespace must be written back before we can
>> > advance the log checkpoint. The tablespace ID (actuall
> commit c51636f254703602f6f6e2e4a260e607e737b9c1 (origin/10.6-MDEV-33551)
> Author: Brandon Nesterenko
> Date: Mon Feb 26 07:01:47 2024 -0700
>
> MDEV-33551: Semi-sync Wait Point AFTER_COMMIT Slow on Workloads with
> Heavy Concurrency
First some overall comments.
The approach of waking
Brandon Nesterenko writes:
>> > +wait_result= cond_timewait(front.thd, &abstime);
>> I'm wondering, is it safe here to wait on front.thd->COND_wakeup_ready?
>> Isn't there a possibility that this might go away during the wait?
> I thought about that originally, and I don't think it can go a
> From: Brandon Nesterenko
>
> When using semi-sync replication with
> rpl_semi_sync_master_wait_point=AFTER_COMMIT, the performance of the
> primary can significantly reduce compared to AFTER_SYNC's
> performance for workloads with many concurrent users executing
> transactions. This is because a
Andrei Elkin writes:
> I reviewed your branch to agree with the idea of xid conflicts
> handling and its implementation.
>
> I however could not understand the need of the refactoring part.
> In order to track the xid dependency couple functions and and
> rpl_parallel_entry::maybe_active_xid
>
Andrei Elkin writes:
> which makes a worker with dependent pieces of job be *effectively* placed at
> the
> tail of the available worker ('fifo') queue.
Indeed.
And this BTW is why a simple sliding window of size 2*workers is not enough,
because in principle a worker can sit in the fifo for ma
Brandon Nesterenko writes:
> Sure, I'll keep COND_binlog around and use that (the main thread doesn't
> have
> a THD, and creating one just to enqueue into the list would be more overhead
> than keeping COND_binlog).
Agree, no need to create another THD.
>> But once we fix the await_all_slave_r
Andrei Elkin writes:
> In normal cases, like that of not so many duplicate xids, the size
> of maybe_active_xid must remain constrained because of "continuous"
> relocation of elements from the tail to replace garbage (normally found
> in head indexes).
> Nevertheless as the array can be dynamic
Hi Brandon,
I only now got to check on MDEV-27512.
This bug seems to be about using --slave_skip_errors=ALL with optimistic
parallel replication.
I saw your patch for the bug. While the patch by itself is perhaps ok, I
think it's only fixing a minor thing, and not addressing the real problem,
le
Brandon Nesterenko writes:
> I see your line of thinking; agreed that --skip-slave-errors=all with
> optimistic parallel replication remains problematic. Though I think we
> should open it as a different JIRA, as the use cases differ, i.e.
Ok, that's fine. Right, I saw one of Roel's tests in MDE
Hi Andrei, Brandon,
What do you think of this patch to fix sporadic failure of
rpl.rpl_gtid_stop_start in buildbot, MDEV-33602? The test fails relatively
frequent, so would be good to get it fixed.
Two issues:
1. I have not so far been able to reproduce the failure, so this patch is
assumed to f
Andrei Elkin writes:
>> 1. I have not so far been able to reproduce the failure, so this patch is
>> assumed to fix the sporadic failure, but I have not been able to verify that
>> it does.
>
> I verified your analysis to confirm.
Thanks for checking!
>> But on the other hand this will not solv
Andrei Elkin writes:
>>> --- a/sql/rpl_rli.cc
>>> +++ b/sql/rpl_rli.cc
>>> @@ -1030,7 +1030,7 @@ void
>>> Relay_log_info::inc_group_relay_log_pos(ulonglong log_pos,
>>> rgi->last_master_timestamp > last_master_timestamp)
>>>last_master_timestamp= rgi->last_master_timestamp;
>>>
Kristian Nielsen via commits writes:
> From: Brandon Nesterenko
>
> This patch extends the command `SHOW REPLICA HOSTS` with three
> columns:
Hi Brandon, please find my review of MDEV-21322 below.
> This patch extends the command `SHOW REPLICA HOSTS` with three
> columns:
>
>
Brandon Nesterenko writes:
> were some additional
> synchronization changes that went alongside the use of LOCK_thd_data, so it
> would be good if
> you could go over at least the code changes again.
> diff --git a/sql/sql_repl.cc b/sql/sql_repl.cc
> index 18a52dc07ad..47f789de751 100644
> --- a
Here is my review of the MDEV-33487 / PR#3087 patch.
First, some general remarks.
This patch addresses a specific bottleneck when binlogging huge transactions
(eg. multi-gigabyte table updates logged in ROW mode).
The root cause is a fundamental limitation in the current binlog format that
requi
Hi Monty,
Here is my review of the patch for MDEV-34504. Looks good, just a bunch of
small suggestions:
> From: Monty
>
> PURGE BINARY LOGS did not always purge binary logs. This commit fixes
> some of the issues and adds notifications if a binary log cannot be
> purged.
> diff --git a/mysql-t
> commit 7a50135f3f908380e2dfb45e3f95c9fb10c01d62
> Author: Andrei
> Date: Mon Jul 15 17:50:37 2024 +0300
>
> MDEV-15393 part 2. Fixes to 'gtid_slave_pos duplicate key errors after
> mysqldump restore'
> MDEV-34615 mysqldump wipes off pre-existing gtid slave state
Hi Andrei, here my r
Andrei Elkin writes:
>> The most common case is the provisioning of a slave with a complete dump
>> from a master. In this case, it is required that the GTID position is set
>> correctly across all domains. Merging the existing and new GTID position as
>> attempted in this patch will break the pr
Hi Monty,
Here is my review of the MDEV-33856 patch:
> commit cc516f4d9913d732065c7abef983df42e5a8bab3
> (origin/bb-11.6-MDEV-33856-seconds_behind_master)
> Author: Monty
> Date: Tue May 14 23:47:59 2024 +0300
>
> MDEV-33856 New definition for Seconds_Behind_Master
If I understand the p
Brandon Nesterenko via developers writes:
>> 2. Why the condition on thd->user_time.val? What is the situation where we
>> are not replicating an event, but user_time is set and we do not want to
>> put
>> the current time in the XID_EVENT?
>
>
> When SET TIMESTAMP is set, the XID_EVENT should us
> From: Andrei
>
> This work partly implements a ROW binlog format MDEV-33455 part
> that is makes non-unique-index-only table XA replication safe in RBR.
> Existence of at least one non-null unique index has always guaranteed
> safety (no hang to error).
Hi Andrei,
A couple early comments on yo
Andrei Elkin writes:
>> Also, are you aware that when you skip a record like this, you may be
>> skipping the very record that needs to be changed?
> Yet luckily this is covered by the BASE (of the patch) logics.
> After(needless) scan the rest of duplicate key record set the third group
> of ev
Andrei Elkin writes:
> Kristian Nielsen writes:
>> You need to make sure that --slave_exec_mode=IDEMPOTENT is not used.
>> Otherwise you can get silent data corruption.
>
> IDEMPOTENT is always risky. Here it would add up another bit, in the
> parallel mode.
What do you mean "IDEMPOTENT is alw
Andrei Elkin writes:
> Indeed a combination of the engine locking protocol and the slave retry
> applies correctly to IDEMPOTENT mode.
>> The optimistic parallel replication should work correctly with
>> IDEMPOTENT,
> Indeed.
Ok good to know. It's definitely a tricky issue, but apparently no k
Otto Kekäläinen via developers writes:
> least the job amd64-fedora-38-last-N-failed is always failing and it
> would not have found its way into the codebase if a protected branch
> policy would require that all commits must have a passing CI status
> before getting pushed/merged.
This is not c
I am in the early stages of a project to hopefully implement a new binlog
format that is managed transactionally by InnoDB. This is a complex change,
and I want to solicit comments early, so I encourage feedback.
The TLDR; of this:
- The current binlog format stores events separately from InnoDB
Andrei Elkin writes:
>> This is not the way to communicate back from engine to server. Instead,
>> simply return a different error code than HA_ERR_LOCK_WAIT_TIMEOUT from
>> InnoDB that you can check for here. You can maybe use one of the existing
>> HA_ERR_* from include/my_base.h, or add a new
Hi Brandon, Andrei,
Does one of you want to review this patch for 10.5?
It fixes a real (and serious) issue in parallel replication that is seen as
sporadic failure of rpl.rpl_start_alter_4 in Buildbot. This is yet another
occurrence of the problem where mark_start_commit() is done too early, thi
Hi Bar,
I want to ask you about this fix of a sporadic failure of the test
rpl.rpl_create_drop_event, which is authored by you.
Not so much the test case fix, which should be good, but I want to ask
someone who knows the event scheduler code better than me to be sure I am
not merely hiding a real
Andrei Elkin writes:
> Howdy Kristian.
> I was going to review.
Thanks Andrei!
> Is the patch is any github branch? Looks so by the MDEV. It'd be good to
> have it there for reviewing either.
Yes, the entire patch series is in bb-10.5-knielsen:
https://github.com/MariaDB/server/commits/bb-
Andrei Elkin writes:
>> My question is if it is ok and by design that the event can continue running
>> after the scheduler is stopped and even after the event is dropped? That
> Should not be ok. The docs https://mariadb.com/kb/en/drop-event/
>
> are explicit
>
> Description
> This statement
Andrei Elkin writes:
> Kristian Nielsen via developers writes:
>> The already-started instance of the event happily continues to run after
>> being dropped. I wonder if that's a bug, or if the documentation is
>> wrong?
>
> To this question, I vaguely rememb
Hi Andrei, thanks a lot for looking at this patch!
andrei.el...@pp.inet.fi writes:
>> +if (rgi->killed_for_retry != rpl_group_info::RETRY_KILL_NONE)
>> + wait_for_pending_deadlock_kill(thd, rgi);
> Assuming my understanding, please correct me if anything, I left a question
> on
andrei.el...@pp.inet.fi writes:
>> Now consider the second case, where T_1 only sets rgi->killed_for_retry
>> _after_ T_2 has passed the above code point:
>>
>> 1. T_2 acquires some lock inside InnoDB
>>
>> 2. T_2 passes the above code point with the check for rgi->killed_for_retry,
>> it calls ma
> From: Libing Song
>
> Description
> ===
> When a transaction commits, it copies the binlog events from
> binlog cache to binlog file. Very large transactions
> (eg. gigabytes) can stall other transactions for a long time
> because the data is copied while holding LOCK_log, which blocks
>
Andrei Elkin writes:
>> So please do a small refactoring of trx_group_commit_leader() and keep
>> only ...
>
> and no need for refactoring really arises.
Well, the refactoring is good, even without the MDEV-32014 patch. The
function trx_group_commit_leader() is already too long and complicated,
Hi Libing Song,
Thanks for the explanations, all clear now.
"slb.songlibing--- via developers" writes:
> > The patch enables the feature by default, with a threshold of 128MB.
> > We need to consider if that is appropriate, or if the feature should be
> > disabled by default.
> That is accord
Hi Georg,
Following MDEV-34859, I wrote a small update for the documentation on the
new cmake option -DWITH_BOOST_CONTEXT=ON cmake option, patch included below.
However, I am not sure how I can include it in the documentation? Feel free
to just take it yourself, or let me know a preferred way to
I wanted to give an update on the progress of my work on MDEV-34705, which
is a task to implement a new binlog format that is stored as an InnoDB
tablespace (or other engine that chooses to implement it).
To recap, the motivation includes removing the costly 2-phase commit between
binlog and InnoD
Markus Mäkelä via developers writes:
> On 12/4/24 13:19, Kristian Nielsen via developers wrote:
>> 5. A more controversial thought is to drop support for semi-sync
>> replication. I think many users use semi-sync believing it does something
> As a (kind of) user of semi-s
Thanks a lot Markus for the additional explanations, very useful.
Markus Mäkelä via developers writes:
> From what I remember (in relation to MDEV-33465) having the master
> roll back the transactions caused some problems to happen if a quick
> restart happened. I think it was that if GTID 0-1-1
Markus Mäkelä via developers writes:
> I think that sounds like a good idea. In step 4, instead of briefly
> replicating the lost changes and resuming writes on the same node, I
> think MaxScale could just move all writes to the node with the newest
> GTID and turn off read-only there, essentiall
Kristian Nielsen via developers writes:
> What if the binlog code simply keeps track of whenever the current page of
> the binlog gets partially written to the file system? And when this happens,
> the next mtr_t write to that page will simply re-write all the data from the
> start
Hi Brandon (and other interested),
It is great that you want to look closer at the MDEV-34705, binlog-in-engine
project. I wanted to write up a high-level summary of the current status to
help you get an overview.
For reference, this is a project to implement a new binlog format that
solves some
Marko Mäkelä writes:
> Finally, I got some more time to think about this. I’m trying to
> summarize from the InnoDB point of view what we discussed today.
Thanks Marko! This is an interesting development. If we can bypass using the
buffer pool and associated machinery it could simplify the logic
Marko Mäkelä writes:
> On Wed, Jan 29, 2025 at 2:08 PM Kristian Nielsen
> wrote:
>> binlog_tablespace_truncate(tablespace, new_length_in_pages)
>> Truncate a binlog tablespace (like mtr.trim_pages() and
>> mtr.commit_shrink()). Can be independent, does not need to be part of a
>> logging
1 - 100 of 123 matches
Mail list logo
