MySQL Bugs: #14433: archive

Bug #14433	archive_gis test failing
Submitted:	28 Oct 2005 19:19	Modified:	20 Nov 2005 5:28
Reporter:	Brian Aker
Status:	Closed
Category:	Server	Severity:	S3 (Non-critical)
Version:	5.0 (may affect 4.1)	OS:
Assigned to:	Sergei Golubchik	Target Version:

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,
'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaa');
INSERT INTO t1 (id, stuff) VALUES
(2,
'bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbb');
INSERT INTO t1 (id, stuff) VALUES
(3,
'ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
cccccccccc');
INSERT INTO t1 (id, stuff) VALUES
(4,
'ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
dddddddddd');
INSERT INTO t1 (id, stuff) VALUES
(5,
'eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeee');
INSERT INTO t1 (id, stuff) VALUES
(6,
'fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffff');

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.