[Bug] addInfo is (Datum) 0, which is expected to be not, coredump in func DatumGetByteaP about rum HOT 8 CLOSED

Do you use index with "USING rum (a rum_tsvector_ops); " or something else: rum_tsvector_addon_ops, rum_tsvector_hash_ops... ?

Thanks for the report.

from rum.

Do you use index with "USING rum (a rum_tsvector_ops); " or something else: rum_tsvector_addon_ops, rum_tsvector_hash_ops... ?

Thanks for the report.

"rum_individual_news_idx" rum (search_vector), which search_vector is tsvector

from rum.

When using a default indexing option (or specifying rum_tsvector_ops, which is the same) addinfo contain word positions that should be > 0 when addInfoIsNull == false. addInfoIsNull == true basically means that lexeme is not included in any of the table rows. Therefore varbyte encoding should not be read as it can contain only garbage. But this is only for the case of the index with default opclass (rum_tsvector_ops)

With rum_tsvector_addon_ops addinfo contains data from the attached column which can be legit 0 and we shouldn't confuse it with NULL. In this case addInfoIsNull == false when addinfo column contains 0 (or any other value). If addInfoIsNull == true then addinfo column contains NULL and the addinfo column doesn't need and isn't going to be read (very much like a NULL attribute in a table row, which is not stored in the tuple, just have nullmask bit set to true),

It is not easy to fix the former and don't break the latter. Your fix will probably suit your case, but if you apply it you should not create RUM index with options other than the default. Otherwise, you can silently get wrong select results due to confusion between 0 and NULL in the attached column.

from rum.

After further contemplation, I guess that having NULL in lexemes positions list is quite improbable. On the other hand, there is a possibility that the backtrace provided is due to a broken stack. I'd like to be sure the problem is related to RUM query, not something else below in the stack. Could you please turn on query logging and give me several queries just before the crash occurs?

If it is indeed due to RUM query, it then could be useful to add some debug checks in the code to check (addInfo[i] != NULL || addInfoIsNull[i] == true) for standard text search opclass on insert etc. Do you have possibility to build custom RUM builds from the source and try to repeat a crash on it? If so, I will create you appropriate debug branch.

from rum.

@markrui3 I've discovered a similar backtrace in a master rum build when run under valgrind. The issue is fixed and I'd appreciate it if you could check whether you can still see the bug you initially reported in this issue on a fresh master RUM build.

from rum.

@markrui3 I've discovered a similar backtrace in a master rum build when run under valgrind. The issue is fixed and I'd appreciate it if you could check whether you can still see the bug you initially reported in this issue on a fresh master RUM build.

Is this commit 1605f9eebe70278a60dac53476312dc6d66e39d0? I will try if it works.
Thanks.

from rum.

@markrui3 there were several fixes. Please try current master branch state (655f5b3) not just one commit. It is fully backward compatible, you should find no problems when checking with old indexes.

from rum.

I'll close the issue as per my comment #99 (comment)
Should not exist anymore.
If you can detect it again please do not hesitate to reopen the issue!

from rum.