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
