MySQL Bugs: #14433: archive

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

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.

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)

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.

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.

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.

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

pushed in 5.0.17

Note it's not only archive_gis, any filesort on the archive table could (not should!) trigger the bug.

Noted in 5.0.17 changelog.