On 31 Mar 2015, at 08:33, Dr Josef Karthauser <[email protected]>
wrote:
>
> [cut]
> I can only assume that something like the following happened. In the lead up
> to an ‘out of file handles crash’ a spatially indexed node was added to the
> database with id 874121, and then added to the spatial index. During the
> crash, restart, transaction unwind node 874121 was wound back, but the
> spatial node referencing it was not. Then, during the next run a new node
> with id 874121 was created, but this was an index node, not a data node.
>
> That sounds crazy, but plausible. But, if true suggests then the transaction
> protection isn’t absolute. Running out of file handles is a likely outcome
> and transactions should protect against corruption in this scenario, right?
> Why isn’t the spatial index also getting wound back after a transaction
> failure?
>
> This is with neo4j-2.1.6 and neo4j-spatial 0.13
>
This is the extent of the problem:
match (:ReferenceNode)--(m {layer: "topography"})
match m-[*]->(n) where has(n.id)
with n as referencing
match q<-[*]-(m) where id(q) = referencing.id
return count(q)
count(q)
114
<>
Returned 1 row in 1285 ms
That looks like 114 cross links within the index to me.
Is my interpretation right? I’m minded to just delete all of these
‘referencing’ nodes, and hopefully that will fix the index.
Joe
--
You received this message because you are subscribed to the Google Groups
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
