Hey folks...
The context of this message is sqlite library version 3.3.6, using the
shared-cache mode, effectively following the test_server.c example.
Immediately upon switching to shared-cache mode we started seeing errors
like so when preparing statements:
[ERROR] (lib/sqlite/src/build.c:1220) no such collation sequence: <random
garbage>
Drilling down, this is what I'm understanding to be the case... Collators
are attached to the individual sqlite* handles, remaining valid only while
the connection to which the handle refers is valid. On the other hand, it
appears that indexes are stored inside of the schema, and use a lookup
string ("BINARY", "NOCASE") to find the contained column collators. This
lookup string is actually in memory allocated as part of the collator, and
is freed when the connection is closed, leaving a dangling pointer in the
index.
From reading mozilla's docs on how they used the shared cache mode, I have
to guess this dangling pointer thing isn't normally a problem since the
"standard" thing to do is open a (dummy) connection at the beginning of the
server and maintain it until the server ends. In which case, the dummy
connection is the one containing default collator defs and that lookup
string's memory is always valid.
The error above surfaced in our initial implementation of the test_server.c
architecture, where we hadn't yet started using a dummy connection. We were
testing functionality and just opening and closing connections as needed
through the server thread, and noticed that if the first connection happened
to close after the second connection opened, we would end up with the above
error. Before realizing this was perhaps an artefact of not having a dummy
connection, we worked around it by doing a strcpy of the collator name into
malloc'd memory for the index, rather than just pointing at the collator..
Is this a correct interpretation of this situation? If there's a dependency
in shared cache mode where the client must maintain at least one persistent
connection, did I miss documentation on this fact?
I hope I explained myself properly. If not, let me know and I'll try
again. :-)
Thanks,
Pete.
