We have a postgresql v14 database running on RHEL 7 server. I was able to connect to it using RPostgres 1.4.5 / R 4.2.3 from our HPC which runs on RHEL 8. Last night, we updated SSL certificates for postgresql v14 server as we were getting ee key too small error from an updated openssl library. Related thread. So, we updated SSL certificates signed using 2048 key length (instead of earlier 1024 key length). While postgresql server is running ok with new SSL and we can connect to it from R and other interfaces (pgadmin, pgweb, etc.), I get following error while connecting using RPostgres package v1.4.5 or an updated v1.4.6. This error only appears on our HPC running R 4.2.3 on RHEL 8 but not on my macbook where the same command can connect to postgres server though mac runs R 4.3.1.
library(RPostgres)
Loading required package: RPostgres
con <- dbConnect(drv = Postgres(),
host = "db.example.com",
port = xxxx,
user = "user1",
password = "xxxx",
sslmode = "require",
dbname = "sandbox")
*** caught segfault ***
address (nil), cause 'memory not mapped'
Traceback:
1: connection_create(names(opts), as.vector(opts), check_interrupts)
2: .local(drv, ...)
3: dbConnect(drv = Postgres(), host = "db.example.com", port = xxxx, user = "user1", password = "xxxx", sslmode = "require", dbname = "sandbox")
4: dbConnect(drv = Postgres(), host = "db.example.com", port = xxxx, user = "user1", password = "xxxx", sslmode = "require", dbname = "sandbox")
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
RPostgres:::client_version()
150002 # on HPC (versus 150004 on macbook)
session info on HPC
> sessionInfo()
R version 4.2.3 (2023-03-15)
Platform: x86_64-conda-linux-gnu (64-bit)
Running under: Red Hat Enterprise Linux 8.8 (Ootpa)
Matrix products: default
BLAS/LAPACK: .../hpcenv/opt/conda/env/yoda/lib/libopenblasp-r0.3.21.so
locale:
[1] LC_CTYPE=C.UTF-8 LC_NUMERIC=C LC_TIME=C.UTF-8
[4] LC_COLLATE=C.UTF-8 LC_MONETARY=C.UTF-8 LC_MESSAGES=C.UTF-8
[7] LC_PAPER=C.UTF-8 LC_NAME=C LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=C.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] bit_4.0.5 compiler_4.2.3 cli_3.6.2 hms_1.1.3
[5] DBI_1.1.3 bit64_4.0.5 vctrs_0.6.4 blob_1.2.4
[9] jsonlite_1.8.8 lifecycle_1.0.3 pkgconfig_2.0.3 rlang_1.1.3
[13] RPostgres_1.4.6
If I use RPostgres built under R 4.3.1 (on a different conda env) on the same HPC for my default conda env running R 4.2.3, I can connect to the same postgresql instance. I tried recompiling RPostgres for R 4.2.3 but error still persists. For time being, I am using lib.loc while loading RPostgres package in R 4.2.3, so that I can use a package built under R 4.3.1 to successfully connect to postgres in R 4.2.3!
# R 4.2.3
library("RPostgres", lib.loc = "...path/to/R.4.3.1_pkgs/")
We have a postgresql v14 database running on RHEL 7 server. I was able to connect to it using RPostgres 1.4.5 / R 4.2.3 from our HPC which runs on RHEL 8. Last night, we updated SSL certificates for postgresql v14 server as we were getting
ee key too small
error from an updated openssl library. Related thread. So, we updated SSL certificates signed using 2048 key length (instead of earlier 1024 key length). While postgresql server is running ok with new SSL and we can connect to it from R and other interfaces (pgadmin, pgweb, etc.), I get following error while connecting using RPostgres package v1.4.5 or an updated v1.4.6. This error only appears on our HPC running R 4.2.3 on RHEL 8 but not on my macbook where the same command can connect to postgres server though mac runs R 4.3.1.session info on HPC
session info on macbook
temporary fix
If I use RPostgres built under R 4.3.1 (on a different conda env) on the same HPC for my default conda env running R 4.2.3, I can connect to the same postgresql instance. I tried recompiling RPostgres for R 4.2.3 but error still persists. For time being, I am using
lib.loc
while loading RPostgres package in R 4.2.3, so that I can use a package built under R 4.3.1 to successfully connect to postgres in R 4.2.3!