Hi, On 2020-09-30 21:16:10 -0500, Justin Pryzby wrote: > Sep 30 19:40:08 database7 abrt-hook-ccpp: Process 17905 (postgres) of user 26 > killed by SIGABRT - dumping core > Core was generated by `postgres: telsasoft ts 192.168.122.11(34608) SELECT > '. > > Unfortunately, the filesystem wasn't large enough and the corefile is > truncated.
Too bad. > |[pryzbyj@database7 ~]$ sudo gzip -dc > /var/log/postgresql/crash-postgresql-2020-09-30_194000.log.gz |head > |[sudo] password for pryzbyj: > |terminate called after throwing an instance of 'std::bad_alloc' > | what(): std::bad_alloc I think this shouldn't happen while we're inside LLVM. To detect / handle allocation failures in the middle of LLVM code in a halfway sensible way, we install an allocation error handler just while in LLVM code (c.f. llvm_enter_fatal_on_oom/llvm_leave_fatal_on_oom). It's possible of course the JIT somehow corrupted data that is passed somewhere to postgis, which then caused postgis to run out of memory. But it seems like that'd need a fair bit of bad luck to not cause an other error before that. > But the 2019 doesn't even include the geometry table. I'm not sure if these > are even the same crash, but if they are, I think it's maybe an JIT issue and > not postgis (??) It'd be good to get a backtrace - but this doesn't immediately scream out loud "I am a JIT bug" to me. Greetings, Andres Freund
