Some feature design and code questions. Maybe not all of them need to
be resolved right now.
- We need to know somehow if the current run is complete, i.e. if we
query some LSN interval, the last block we read should have the last
block bit set, if we silently output partial data, the user will not
know if he should re-query the last part of LSN interval or not. I
am not sure what would be the best way. Another column for last
block bit flag? That would be quite clumsy for users to use.
- Likewise I am not sure what should we do about corrupted blocks in
the middle of requested LSN intervals (and maybe missing LSN
interval data too). Another boolean column "this block is continuous
from the previous block"?
- In any case I guess we should diagnose bad block checksums we
encounter to the error log at least. That's easy, but it raises the
issue of what would happen if the I_S query would attempt to read the
last bitmap block while it's being written. Currently such block
would be ignored correctly, but in this case we would get false
errors. I think we should introduce a log online mutex for the last
written block protection. Acquire it in the log writer around the
block write + sync. Acquire it (and immediatelly release) in the
log iterator right before the read when (offset == file size - 1
block).
General comments:
- Please submit an MP against lp:percona-server/5.1, as the current
target branch has been merged.
- I guess the current code did not implement the index condition
pushdown yet?
- There is no decision on the I_S table row count limit system
variable in the blueprint, but the code has it, please update the
blueprint.
- Please add tests for LSNs too. Unfortunately, their values are not
that predictable, so the basic test would be to check that start lsn
< end lsn.
- Please add tests for the index condition pushdown, i.e. where
start_lsn > ... and end_lsn < .... The lsn values for this test can
be taken from the 1st query on I_S, and get the e.g. MIN, MAX, and
median values of the tracked interval.
- The new system var requires a new sys_var/var_name-basic.test. In
the current branch, isn't sys_vars/all_vars test failing due to that
test being missing?
- Code formatting issues (I know, these are very pedantic): the
/*=====*/ under function names should match the function name
length. The function arg comments should start with /*!< in: or /*!<
out: or /*!< in/out:
- Indentation issue around diff lines 308--312: both args and code
should be indented by 1 tab. Likewise in many other places in
log0online.c etc.. Also there should be 1 tab between var type and
name in the local var declarations.
- (srv_changed_pages_limit ? output_rows_num < srv_changed_pages_limit
: TRUE) can be simplified to (!srv_changed_pages_limit ||
output_rows_num < srv_changed_pages_limit)
- Maybe log_online_bitmap_iterator_init should set the rest of the
fields it does not touch now to some safe values?
- No need for the comment in diff lines 618--620, 646--648, it should
be enough to mention it once in log0online.c next to the first file
name printing place.
- In log_online_bitmap_iterator_next in the case of bitmap file
checksum error it makes sense to report it as a warning to the error
log.
- The naming convention for structs in InnoDB is that
st_log_bitmap_iterator should be called log_bitmap_iterator_struct
and st_log_bitmap_iterator should be log_bitmap_iterator_t.
- The comments for the struct st_log_bitmap_iterator should not
mention "bitmap output", but it's input there. Likewise with "out"
in the field names, i.e. out_offset should be read_offset or similar.
- Line 440: s/space/page
- What is the purpose of LOG_BITMAP_ITERATOR_* macros? Except for
LOG_BITMAP_ITERATOR_PAGE_NUM
Some feature design and code questions. Maybe not all of them need to
be resolved right now.
- We need to know somehow if the current run is complete, i.e. if we
query some LSN interval, the last block we read should have the last
block bit set, if we silently output partial data, the user will not
know if he should re-query the last part of LSN interval or not. I
am not sure what would be the best way. Another column for last
block bit flag? That would be quite clumsy for users to use.
- Likewise I am not sure what should we do about corrupted blocks in
the middle of requested LSN intervals (and maybe missing LSN
interval data too). Another boolean column "this block is continuous
from the previous block"?
- In any case I guess we should diagnose bad block checksums we
encounter to the error log at least. That's easy, but it raises the
issue of what would happen if the I_S query would attempt to read the
last bitmap block while it's being written. Currently such block
would be ignored correctly, but in this case we would get false
errors. I think we should introduce a log online mutex for the last
written block protection. Acquire it in the log writer around the
block write + sync. Acquire it (and immediatelly release) in the
log iterator right before the read when (offset == file size - 1
block).
General comments:
- Please submit an MP against lp:percona-server/5.1, as the current
target branch has been merged.
- I guess the current code did not implement the index condition
pushdown yet?
- There is no decision on the I_S table row count limit system
variable in the blueprint, but the code has it, please update the
blueprint.
- Please add tests for LSNs too. Unfortunately, their values are not
that predictable, so the basic test would be to check that start lsn
< end lsn.
- Please add tests for the index condition pushdown, i.e. where
start_lsn > ... and end_lsn < .... The lsn values for this test can
be taken from the 1st query on I_S, and get the e.g. MIN, MAX, and
median values of the tracked interval.
- The new system var requires a new sys_var/ var_name- basic.test. In
the current branch, isn't sys_vars/all_vars test failing due to that
test being missing?
- Code formatting issues (I know, these are very pedantic): the
/*=====*/ under function names should match the function name
length. The function arg comments should start with /*!< in: or /*!<
out: or /*!< in/out:
- Indentation issue around diff lines 308--312: both args and code
should be indented by 1 tab. Likewise in many other places in
log0online.c etc.. Also there should be 1 tab between var type and
name in the local var declarations.
- (srv_changed_ pages_limit ? output_rows_num < srv_changed_ pages_limit pages_limit || pages_limit)
: TRUE) can be simplified to (!srv_changed_
output_rows_num < srv_changed_
- Maybe log_online_ bitmap_ iterator_ init should set the rest of the
fields it does not touch now to some safe values?
- No need for the comment in diff lines 618--620, 646--648, it should
be enough to mention it once in log0online.c next to the first file
name printing place.
- In log_online_ bitmap_ iterator_ next in the case of bitmap file
checksum error it makes sense to report it as a warning to the error
log.
- The naming convention for structs in InnoDB is that bitmap_ iterator should be called log_bitmap_ iterator_ struct bitmap_ iterator should be log_bitmap_ iterator_ t.
st_log_
and st_log_
- The comments for the struct st_log_ bitmap_ iterator should not
mention "bitmap output", but it's input there. Likewise with "out"
in the field names, i.e. out_offset should be read_offset or similar.
- Line 440: s/space/page
- What is the purpose of LOG_BITMAP_ ITERATOR_ * macros? Except for ITERATOR_ PAGE_NUM
LOG_BITMAP_