pgjdbc: OutOfMemoryError should not be wrapped
I’m submitting a …
- [X ] bug report
- feature request
Describe the issue A clear and concise description of what the issue is.
Driver Version? 42.6.0
Java Version? docker: amazoncorretto:17
OS Version? docker: amazoncorretto:17
PostgreSQL Version? N/A
To Reproduce
j.l.OutOfMemoryError: Java heap space
Wrapped by: o.p.u.PSQLException: Ran out of memory retrieving query results.
at o.p.c.v.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2372)
at o.p.c.v.QueryExecutorImpl.execute(QueryExecutorImpl.java:368)
at o.p.jdbc.PgStatement.executeInternal(PgStatement.java:498)
at o.p.jdbc.PgStatement.execute(PgStatement.java:415)
at o.p.j.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:190)
at o.p.j.PgPreparedStatement.executeQuery(PgPreparedStatement.java:134)
Expected behaviour Our AWS ECS instance would be killed if OOM Error was not wrapped in a PSQLException. We purposely use the Scala NonFatal in pattern matches but it won’t work if OOM Errors are nested under other exceptions. Best practices are not to try to handle fatal errors and let them kill the JVM/ECS container.
Logs If possible PostgreSQL logs surrounding the occurrence of the issue
About this issue
- Original URL
- State: closed
- Created 10 months ago
- Comments: 16 (8 by maintainers)
https://github.com/pgjdbc/pgjdbc/blob/650767d2a663ea4506dfc89018e770d6554be125/pgjdbc/src/main/java/org/postgresql/core/v3/QueryExecutorImpl.java#L2369
@vlsi I think we should just ignore this and let the app die
@BusyByte , even though I agree catching OOM is tricky, we have exact case when we know we can recover from the OOM.
We tried allocating an array, and we fail. That means we skip allocating the array, and we notify the user the results are incomplete.
I think that is a reasonable approach to handle OOM.
Of course, users can leverage
ExitOnOutOfMemoryErroror evenCrashOnOutOfMemoryError.@davecramer I can try but It’ll be probably next week.
OK, thanks for the info