-
Notifications
You must be signed in to change notification settings - Fork 59
Segmentation fault in decode_varbyte (src/rumtsquery.c:236) #63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hello Andrei, |
hi @za-arthur ! So this time unfortunately I don't have a test scenario which reproduces the issue. It occurs seemingly randomly and I was unable to pin down the root cause. All I can provide is a redacted query that was executed before the crash: 2019-08-06 14:45:41 UTC DETAIL: Failed process was running: SELECT *
FROM tablename
WHERE
(int_column1 = 188 OR int_column1 IS NULL) AND
int_column2 = 2 AND
sring_column1 IS NOT NULL AND
to_tsvector('simple', 'redacted search string') @@ tsquery_column1 AND
'redacted search string' ~* ('(^|A| +)' || string_column2 || '( +|Z|$)')
ORDER BY length(string_column2) DESC LIMIT 1; Note here that tsquery_column1 is a column of type |
Hi @za-arthur! Is there any progress on this? Are there any ways I can help to speed up the process? |
Hello! |
Ok, then meanwhile I will try to come up with repro steps
…On Sat, Aug 17, 2019 at 12:37 Artur ***@***.***> wrote:
Hello!
Unfortunately I couldn't reproduce it yet. And I have another urgent
project and it is hard to say when I'll fix the issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#63?email_source=notifications&email_token=AANQG32V6JTOLJFQSTQZ5LLQE7BGLA5CNFSM4IJ6M3M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QHTVY#issuecomment-522222039>,
or mute the thread
<https://github.com/notification
|
Hi @za-arthur, I have new insight regarding this bug. We found out that the server that was running the postgres instance with the extension had periods of time during the day when it was low on RAM due to other processes running on the same server. After we fixed the issue with free RAM, the issue was no longer reproducing. So I guess for us the problem is solved. Though I'm not sure that segfault is a proper behavior of a program when it is starving on memory |
the culprit was a malformed index. rebuilding it via |
Hi, this is a followup from #62. We upgraded our production systems, and while the rate of segmentation faults decreased, they are still occurring. Please advise on the next steps
System info
GDB backtrace
GDB full backtrace
The text was updated successfully, but these errors were encountered: