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
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
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-----