Hi Jorgen,
I accept changes in the kernel code. I have some requests for the test case.
Rafal
Jorgen Loland wrote:
> #At file:///localhome/jl208045/mysql/mysql-6.0-backup-34902/
>
> 2673 Jorgen Loland 2008-07-30
> Bug#34902: "Backup: crash if view depends on dropped object"
>
> Pre-fix behavior: When adding a view to the backup image fails,
> the object representing the view is deleted but not removed
> from the database catalog. This view object is later tried deleted
> as part of catalog delete.
>
> Fix: Add the object and all its dependencies to dependency list
> before adding the object to the catalog. If any dependant objects
> fail to be added to dep list, the object is not added to the
> catalog.
> modified:
> mysql-test/lib/mtr_report.pl
> mysql-test/r/backup_views.result
> mysql-test/t/backup_views.test
> sql/backup/backup_info.cc
>
> per-file comments:
> mysql-test/lib/mtr_report.pl
> Views test deliberately triggers error "Backup: Failed to add view..." Ignore
> this error in the test.
> mysql-test/r/backup_views.result
> Added results from new test case: backup database with missing view
> dependencies.
> mysql-test/t/backup_views.test
> Added test case: backup database with missing view dependencies.
> sql/backup/backup_info.cc
> In Backup_info::add_db_object
> The object is added to catalog after the object and all dependencies have been
> added to the dependency list. If any of the dependent objects cannot be added to the dep
> list, the object is not added to the catalog.
> === modified file 'mysql-test/t/backup_views.test'
> --- a/mysql-test/t/backup_views.test 2008-06-12 09:55:35 +0000
> +++ b/mysql-test/t/backup_views.test 2008-07-30 07:42:08 +0000
> @@ -281,6 +281,58 @@ SELECT * FROM v3;
> USE bup_db1;
> SELECT * FROM t1;
>
> +
> +###############
> +--echo
> +--echo *** ENTER Backup of database with missing view dependency should fail but not
> crash server
> +--echo
> +
> +--echo initializing test
> +
> +# start with the backed up database
> +DROP DATABASE bup_db1;
> +DROP DATABASE bup_db2;
> +
> +replace_column 1 #;
> +RESTORE FROM 'bup_objectview.bak';
> +
> +# check that table t1 and v1 are initially correct
> +USE bup_db1;
> +SELECT * FROM t1;
> +SELECT * FROM v1;
> +
> +DROP TABLE t1;
> +
> +--echo
> +--echo Testing backup with missing view dependency in same db
> +--echo
> +
> +# v1 selects from t1, and select now reports error
> +--error 1356
I think we should use symbolic error constants, not error codes. The latter
option constantly triggers PB errors when someone forgets to update test scripts
during merge (very easy to miss that).
The error constants are defined in include/mysqld_error.h.
> +SELECT * FROM v1;
> +
> +# try to backup - v1 selects from t1 and backup should now fail
> +--error 1684
Similar here.
> +BACKUP DATABASE bup_db1 TO 'bup_shouldfail1.bak';
> +
> +--echo
> +--echo Testing backup with missing view dependency in other db
> +--echo
> +
> +USE bup_db2;
> +--error 1356
And here.
> +SELECT * from v3;
> +
> +# try to backup - v3 selects from bup_db1.t1 and backup should now fail
> +--error 1684
And here.
> +BACKUP DATABASE bup_db2 TO 'bup_shouldfail2.bak';
> +
However, if bup_db1.t1 exists, then bup_db2.v2 is a valid view and BACKUP will
succeed. On restore, if bup_db2 is gone, RESTORE will fail when trying to create v2.
I think this is an accepted behaviour for now. But, would be good to include
also this scenario in the test.
> +--echo
> +--echo *** EXIT Backup of database with missing view dependency
> +--echo
> +
> +###############
> +
> # Test cleanup section
>
> --echo
> @@ -298,4 +350,10 @@ DROP DATABASE bup_db2;
>
> --remove_file $MYSQLTEST_VARDIR/master-data/bup_objectview2.bak
> --remove_file $MYSQLTEST_VARDIR/master-data/bup_objectview3.bak
> +
> +--error 0,1
> +--remove_file $MYSQLTEST_VARDIR/master-data/bup_shouldfail1.bak
> +--error 0,1
> +--remove_file $MYSQLTEST_VARDIR/master-data/bup_shouldfail2.bak
> +
> #BUG#35249 Mysql server crash for delete operation followed by backup for Default
> Drivers.
>
