Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
M
mariadb
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Kirill Smelkov
mariadb
Commits
08843dd1
Commit
08843dd1
authored
Jul 09, 2003
by
unknown
Browse files
Options
Browse Files
Download
Plain Diff
Merge bk-internal.mysql.com:/home/bk/mysql-4.0
into mashka.mysql.fi:/home/my/mysql-4.0
parents
075fd01f
3c268e59
Changes
5
Show whitespace changes
Inline
Side-by-side
Showing
5 changed files
with
48 additions
and
39 deletions
+48
-39
mysql-test/t/distinct.test
mysql-test/t/distinct.test
+5
-2
sql/log.cc
sql/log.cc
+5
-5
sql/slave.cc
sql/slave.cc
+28
-25
sql/sql_delete.cc
sql/sql_delete.cc
+9
-6
sql/sql_parse.cc
sql/sql_parse.cc
+1
-1
No files found.
mysql-test/t/distinct.test
View file @
08843dd1
...
...
@@ -273,11 +273,14 @@ CREATE TABLE t2 (a int primary key, b int, c int);
INSERT
t2
VALUES
(
3
,
4
,
5
);
SELECT
DISTINCT
t1
.
a
,
t2
.
b
FROM
t1
,
t2
WHERE
t1
.
a
=
1
ORDER
BY
t2
.
c
;
DROP
TABLE
IF
EXISTS
t1
,
t2
;
#
# Test of LEFT() with distinct
#
CREATE
table
t1
(
`id`
int
(
11
)
NOT
NULL
auto_increment
,
`name`
varchar
(
50
)
NOT
NULL
default
''
,
PRIMARY
KEY
(
`id`
))
TYPE
=
MyISAM
AUTO_INCREMENT
=
3
;
INSERT
INTO
t1
VALUES
(
1
,
'aaaaa'
);
INSERT
INTO
t1
VALUES
(
3
,
'aaaaa'
);
INSERT
INTO
t1
VALUES
(
2
,
'eeeeeee'
);
select
distinct
left
(
name
,
1
)
as
name
from
t1
;
drop
table
t1
;
sql/log.cc
View file @
08843dd1
...
...
@@ -141,7 +141,7 @@ void MYSQL_LOG::init(enum_log_type log_type_arg,
io_cache_type
=
io_cache_type_arg
;
no_auto_events
=
no_auto_events_arg
;
max_size
=
max_size_arg
;
DBUG_PRINT
(
"info"
,(
"log_type
=%d max_size=
%lu"
,
log_type
,
max_size
));
DBUG_PRINT
(
"info"
,(
"log_type
: %d max_size:
%lu"
,
log_type
,
max_size
));
if
(
!
inited
)
{
inited
=
1
;
...
...
@@ -909,7 +909,7 @@ bool MYSQL_LOG::append(Log_event* ev)
goto
err
;
}
bytes_written
+=
ev
->
get_event_len
();
DBUG_PRINT
(
"info"
,(
"max_size
=
%lu"
,
max_size
));
DBUG_PRINT
(
"info"
,(
"max_size
:
%lu"
,
max_size
));
if
((
uint
)
my_b_append_tell
(
&
log_file
)
>
max_size
)
{
pthread_mutex_lock
(
&
LOCK_index
);
...
...
@@ -943,7 +943,7 @@ bool MYSQL_LOG::appendv(const char* buf, uint len,...)
}
bytes_written
+=
len
;
}
while
((
buf
=
va_arg
(
args
,
const
char
*
))
&&
(
len
=
va_arg
(
args
,
uint
)));
DBUG_PRINT
(
"info"
,(
"max_size
=
%lu"
,
max_size
));
DBUG_PRINT
(
"info"
,(
"max_size
:
%lu"
,
max_size
));
if
((
uint
)
my_b_append_tell
(
&
log_file
)
>
max_size
)
{
pthread_mutex_lock
(
&
LOCK_index
);
...
...
@@ -1206,7 +1206,7 @@ bool MYSQL_LOG::write(Log_event* event_info)
}
}
/* We wrote to the real log, check automatic rotation; */
DBUG_PRINT
(
"info"
,(
"max_size
=
%lu"
,
max_size
));
DBUG_PRINT
(
"info"
,(
"max_size
:
%lu"
,
max_size
));
should_rotate
=
(
my_b_tell
(
file
)
>=
(
my_off_t
)
max_size
);
}
error
=
0
;
...
...
@@ -1337,7 +1337,7 @@ bool MYSQL_LOG::write(THD *thd, IO_CACHE *cache)
log_file
.
pos_in_file
)))
goto
err
;
signal_update
();
DBUG_PRINT
(
"info"
,(
"max_size
=
%lu"
,
max_size
));
DBUG_PRINT
(
"info"
,(
"max_size
:
%lu"
,
max_size
));
if
(
my_b_tell
(
&
log_file
)
>=
(
my_off_t
)
max_size
)
{
pthread_mutex_lock
(
&
LOCK_index
);
...
...
sql/slave.cc
View file @
08843dd1
...
...
@@ -1205,10 +1205,10 @@ int init_relay_log_info(RELAY_LOG_INFO* rli, const char* info_fname)
/*
The relay log will now be opened, as a SEQ_READ_APPEND IO_CACHE. It is
notable that the last kilobytes of it (8 kB for example) may live in
memory,
not on disk (depending on what the thread using it does). While this is
efficient, it has a side-effect one must know:
t
he size of the relay log on disk (displayed by 'ls -l' on Unix) can be a
notable that the last kilobytes of it (8 kB for example) may live in
memory, not on disk (depending on what the thread using it does). While
this is
efficient, it has a side-effect one must know:
T
he size of the relay log on disk (displayed by 'ls -l' on Unix) can be a
few kilobytes less than one would expect by doing SHOW SLAVE STATUS; this
happens when only the IO thread is started (not the SQL thread). The
"missing" kilobytes are in memory, are preserved during 'STOP SLAVE; START
...
...
@@ -1221,23 +1221,19 @@ int init_relay_log_info(RELAY_LOG_INFO* rli, const char* info_fname)
See how 4 is less than 7811 and 8192 is less than 9744.
WARNING: this is risky because the slave can stay like this for a long
time;
t
hen if it has a power failure, master.info says the I/O thread has read
until 9744 while the relay-log contains only until 8192 (the in-memory part
from 8192 to 9744 has been lost), so the SQL slave thread will miss some
events, silently breaking replication.
WARNING: this is risky because the slave can stay like this for a long
t
ime; then if it has a power failure, master.info says the I/O thread has
read until 9744 while the relay-log contains only until 8192 (the
in-memory part from 8192 to 9744 has been lost), so the SQL slave thread
will miss some
events, silently breaking replication.
Ideally we would like to flush master.info only when we know that the relay
log has no in-memory tail.
Note that the above problem may arise only when only the IO thread is
started, which is unlikely.
*/
if
(
open_log
(
&
rli
->
relay_log
,
glob_hostname
,
opt_relay_logname
,
"-relay-bin"
,
opt_relaylog_index_name
,
LOG_BIN
,
1
/* read_append cache */
,
1
/* no auto events */
,
/*
For the maximum
size, we choose max_relay_log_size if it is
For the maximum log
size, we choose max_relay_log_size if it is
non-zero, max_binlog_size otherwise. If later the user does SET
GLOBAL on one of these variables, fix_max_binlog_size and
fix_max_relay_log_size will reconsider the choice (for example
...
...
@@ -1245,6 +1241,11 @@ int init_relay_log_info(RELAY_LOG_INFO* rli, const char* info_fname)
switch to using max_binlog_size for the relay log) and update
rli->relay_log.max_size (and mysql_bin_log.max_size).
*/
if
(
open_log
(
&
rli
->
relay_log
,
glob_hostname
,
opt_relay_logname
,
"-relay-bin"
,
opt_relaylog_index_name
,
LOG_BIN
,
1
/* read_append cache */
,
1
/* no auto events */
,
max_relay_log_size
?
max_relay_log_size
:
max_binlog_size
))
{
sql_print_error
(
"Failed in open_log() called from init_relay_log_info()"
);
...
...
@@ -3445,23 +3446,25 @@ void rotate_relay_log(MASTER_INFO* mi)
/* If this server is not a slave (or RESET SLAVE has just been run) */
if
(
!
rli
->
inited
)
{
DBUG_PRINT
(
"info"
,
(
"rli->inited
=
0"
));
DBUG_PRINT
(
"info"
,
(
"rli->inited
==
0"
));
DBUG_VOID_RETURN
;
}
lock_slave_threads
(
mi
);
pthread_mutex_lock
(
&
rli
->
data_lock
);
/* If the relay log is closed, new_file() will do nothing. */
rli
->
relay_log
.
new_file
(
1
);
/*
We harvest now, because otherwise BIN_LOG_HEADER_SIZE will not immediately
be counted, so imagine a succession of FLUSH LOGS and assume the slave
threads are started:
relay_log_space decreases by the size of the deleted relay log, but does
not
increase, so flush-after-flush we may become negative, which is wrong.
Even if this will be corrected as soon as a query is replicated on the
slave
(because the I/O thread will then call harvest_bytes_written() which will
harvest all these BIN_LOG_HEADER_SIZE we forgot), it may give strange output
in SHOW SLAVE STATUS meanwhile. So we harvest now.
relay_log_space decreases by the size of the deleted relay log, but does
not
increase, so flush-after-flush we may become negative, which is wrong.
Even if this will be corrected as soon as a query is replicated on the
slave (because the I/O thread will then call harvest_bytes_written() which
will harvest all these BIN_LOG_HEADER_SIZE we forgot), it may give strange
output
in SHOW SLAVE STATUS meanwhile. So we harvest now.
If the log is closed, then this will just harvest the last writes, probably
0 as they probably have been harvested.
*/
...
...
sql/sql_delete.cc
View file @
08843dd1
...
...
@@ -145,12 +145,15 @@ int mysql_delete(THD *thd, TABLE_LIST *table_list, COND *conds, ORDER *order,
else
{
table
->
file
->
print_error
(
error
,
MYF
(
0
));
error
=
1
;
/* In < 4.0.14 we set the error number to 0 here, but that
/*
In < 4.0.14 we set the error number to 0 here, but that
was not sensible, because then MySQL would not roll back the
failed DELETE, and also wrote it to the binlog. For MyISAM
tables a DELETE probably never should fail (?), but for
InnoDB it can fail in a FOREIGN KEY error or an
out-of-tablespace error. (Comment by Heikki July 7, 2003) */
out-of-tablespace error.
*/
error
=
1
;
break
;
}
}
...
...
sql/sql_parse.cc
View file @
08843dd1
...
...
@@ -2178,7 +2178,7 @@ mysql_execute_command(void)
}
if
(
check_access
(
thd
,
SELECT_ACL
,
db
,
&
thd
->
col_access
))
goto
error
;
/* purecov: inspected */
if
(
!
thd
->
col_access
&&
grant_option
&&
check_grant_db
(
thd
,
db
))
if
(
!
thd
->
col_access
&&
check_grant_db
(
thd
,
db
))
{
net_printf
(
&
thd
->
net
,
ER_DBACCESS_DENIED_ERROR
,
thd
->
priv_user
,
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment