Skip to content
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

chore: friendly OOM message #223

Merged
merged 1 commit into from
Jan 5, 2024
Merged

chore: friendly OOM message #223

merged 1 commit into from
Jan 5, 2024

Conversation

usamoi
Copy link
Collaborator

@usamoi usamoi commented Jan 2, 2024

I'm not sure if it really works. On my machine, OOM Killer kills Postgres directly when OOM occurs so there is no chance to print a nice message, but I think users can view kernel logs on this condition.

If OOM is detected by our code, only the OOM thread (probably an optimizing thread) will be killed. Then optimizing stops. Users will view our logs to know OOM occurs.

If the background process is killed but Postgres is not killed, the background process just restarts after 1 second. OOM probably occurs again (since it's raisen from an optimizing).

Will it close #208 ?

Signed-off-by: usamoi <usamoi@outlook.com>
@cutecutecat
Copy link
Member

cutecutecat commented Jan 4, 2024

If the OOM is caused by insert instead of optimize, which thread would be killed, and would it restart?

@usamoi
Copy link
Collaborator Author

usamoi commented Jan 4, 2024

@cutecutecat The session thread (the thread who communicate with a session process) panics and users can just restart the transaction (in theory).

@usamoi usamoi added this pull request to the merge queue Jan 5, 2024
Merged via the queue into tensorchord:main with commit dde112a Jan 5, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted 🆘 Extra attention is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

chore: Friendly OOM error
3 participants