I'm not sure if one of the developers can make better sense of the trace files, but attached is the output of 2 traces where a table stopped returning rows for a simple (=) operator.

The "broken" trace file shows how the query returns no rows for something that exists. One thing to note, the top of the trace says that there are 8 rows in the table but there are only 4 rows in the table.

The second table (chnl2) was created and populated in the same way as the first table (chnl2). You can see that the same query is returning rows.

I'm using a nightly build. Anything else I can do to help troubleshoot, please let me know.

-Ross





On Mon, Oct 6, 2008 at 12:23 PM, Ross Bates <rbates@gmail.com> wrote:
Carl - this bug continues to bother me as well as I can't reproduce the exact steps.

Does your application populate the table in question using sql like this?

    insert into foo(col1,col2) (select col1,col2 from bar)

Also, do you run any delete statements before populating the data?

I was thinking that the bug was related to the addition/deletion of columns, but it appears to show up more often after a series of insert/delete statements which follow my alter/create table statements.




On Sun, Oct 5, 2008 at 4:19 PM, Stefan de Konink <stefan@konink.de> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ross Bates schreef:
> Stefan - what is occurring in the alignment bug you are referring to?

I had an issue before that occured after I had added an index (that in
MonetDB terms shouldn't do anything), where I was able to make mserver5
crash on a string comparison.

But I know that this was fixed even before I had reported it.


Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREKAAYFAkjpL2AACgkQYH1+F2Rqwn3k9gCeKg+p+n+nQE+dPTLDLnZe9OZ9
SIAAnimb0zS4XvWtiKncWEwh3RU7DMJe
=zHeG
-----END PGP SIGNATURE-----