Bug #14433 archive_gis test failing
Submitted: 28 Oct 2005 17:19 Modified: 20 Nov 2005 4:28
Reporter: Brian Aker Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.0 (may affect 4.1) OS:
Assigned to: Sergei Golubchik CPU Architecture:Any

[28 Oct 2005 17:19] Brian Aker
Description:
Hi!

The archive_gis test is failing on ORDER BY clauses on 32bit systems. I suspect that it is an issue in ::position and ::rnd_pos()

How to repeat:
Run the archive_gis test.
[2 Nov 2005 1:06] Patrick Galbraith
Dug into this further...

It has to do with ORDER BY and BLOB types. Wrote a simple test that uses blobs, and order by produces no result set. (note: geometry types are like these), hence ::rnd_pos and ::position. 

Note: passes on Mac OSX, Fails on Linux (both 32-bit)
[2 Nov 2005 3:12] Patrick Galbraith
I created a simple test:

create table t1 (
 `id` INT(32) NOT NULL,
 `stuff` BLOB
 ) ENGINE=archive;

INSERT INTO t1 (id, stuff) VALUES
(1, 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa');
INSERT INTO t1 (id, stuff) VALUES
(2, 'bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb');
INSERT INTO t1 (id, stuff) VALUES
(3, 'ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc');
INSERT INTO t1 (id, stuff) VALUES
(4, 'ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd');
INSERT INTO t1 (id, stuff) VALUES
(5, 'eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee');
INSERT INTO t1 (id, stuff) VALUES
(6, 'fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff');

SELECT * FROM t1;
SELECT * FROM t1 ORDER BY id;

On Mac OSX, Linux 64-bit, it passes. On Linux 32-bit, it fails. It seems to store the position just fine in ::position

>ha_archive::position
T@11221390: | | | | | | | | | | info: ref_length 8 current_position 2
T@11221390: | | | | | | | | | <ha_archive::position

Then, on ::rnd_pos, it retrieves it just fine:

T@11221390: | | | | | | | >ha_archive::rnd_pos
T@11221390: | | | | | | | | info: sizeof z_off_t 8 ref length 8 pos 8d9eba8 current_position 2
T@11221390: | | | | | | | <ha_archive::rnd_pos

But then fails to get the record from the file:

T@11221390: | | | | | | | >ha_archive::get_row
T@11221390: | | | | | | | | ha_archive::get_row: Read 0 bytes expected 15
T@11221390: | | | | | | | <ha_archive::get_row

My suspicion is that the line:

(void)gzseek(archive, current_position, SEEK_SET);

That it doesn't seek to the correct position in the gzip archive. In the 64-bit Linux and Mac versions, current position is 2, so I do not yet know why gzseek won't go to the correct position in the archive.
[2 Nov 2005 3:21] Patrick Galbraith
Ok, I'm thinking now it's not rnd_pos, or anything like that. I think it's real_write_row

Linux, 32-bit

patg@krsna:~/mysql-build/mysql-5.0.test2/mysql-test> grep real_write_row var/log/master.trace 
T@11221390: | | | | | | >ha_archive::real_write_row
T@11221390: | | | | | | | ha_archive::real_write_row: Wrote 16 bytes expected 0
T@11221390: | | | | | | <ha_archive::real_write_row
T@11221390: | | | | | | >ha_archive::real_write_row
T@11221390: | | | | | | | ha_archive::real_write_row: Wrote 16 bytes expected 0
T@11221390: | | | | | | <ha_archive::real_write_row
T@11221390: | | | | | | >ha_archive::real_write_row
T@11221390: | | | | | | | ha_archive::real_write_row: Wrote 16 bytes expected 0
and so forth and so on.

Mac and Linux 64-bit

radha:~/mysql-build/mysql-5.0.test1/mysql-test patg$ grep real_write_row var/log/master.trace 
T@4    : | | | | | | >ha_archive::real_write_row
T@4    : | | | | | | | ha_archive::real_write_row: Wrote 16 bytes expected 16
T@4    : | | | | | | <ha_archive::real_write_row
T@4    : | | | | | | >ha_archive::real_write_row
T@4    : | | | | | | | ha_archive::real_write_row: Wrote 16 bytes expected 16
T@4    : | | | | | | <ha_archive::real_write_row
T@4    : | | | | | | >ha_archive::real_write_row
T@4    : | | | | | | | ha_archive::real_write_row: Wrote 16 bytes expected 16
and so forth and so on.
[2 Nov 2005 3:30] Patrick Galbraith
Why would table->s->reclength be 0 on Linux 32-bit? I think that is the issue here. 

written= gzwrite(writer, buf, table->s->reclength);
  DBUG_PRINT("ha_archive::real_write_row", ("Wrote %d bytes expected %d", written, table->s->reclength));

I think the reason that it breaks order by with blobs (and this is just an idea) is that with blobs, you have to have exact positioning information since they are tacked onto the end of the record in the gzip file. If gzwrite's 3rd argument is 0, I'm guessing that would break that.

I need to trace this through with a debugger tomorrow.
[16 Nov 2005 14:17] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/32314
[16 Nov 2005 15:32] Sergei Golubchik
pushed in 5.0.17

Note it's not only archive_gis, any filesort on the archive table could (not should!) trigger the bug.
[20 Nov 2005 4:28] Paul Dubois
Noted in 5.0.17 changelog.