vakaobr commented on issue #2588:
URL: https://github.com/apache/age/issues/2588#issuecomment-6077819033
Update: we ran the `jit = off` experiment we offered, and it does not help.
The issue body is amended with the figures.
```
documents failures per 100 documents
48h before (jit=on) 354 4 1.13
~49h after (jit=off) 208 10 4.81
```
The rate did not fall. We are not claiming `jit = off` made it worse, since
our mean document size grew over the same period and that independently raises
exposure. The conclusion we would draw is simply that **JIT is not the
trigger**. We have left `jit = off` in place, so anything we report from here
is from a `jit = off` instance.
Two other things worth flagging, both now in the body:
1. **The fault has a second client-visible form that is easy to miss.** In 7
of 39 occurrences the bytes in the invalid name are not valid UTF-8 at all, so
the driver raises a decode error while reading the error message itself and no
`does not exist` ever reaches the application. Anyone matching only on `does
not exist`, or on `invalid memory alloc request size`, will undercount this. We
made that mistake ourselves and concluded for two days that the fault had
stopped, when it was still running at roughly one occurrence per 20 documents.
2. **It persists at larger scale with the catalog still correct.** The graph
has grown from 531k to 737k vertices and from 1.49M to 1.93M edges since the
original report. Still exactly four labels, still correct. Edge property sizes
are essentially unchanged, so the growth changed the volume of work exposed to
the fault but not its character.
The offers in the original report still stand: a stack trace with debug
symbols if you can suggest where to break, `pg_stat_activity` or memory-context
dumps at the point of failure, or a specific patch tried against the live
workload. Tell us which would be most useful.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
