Trying to use the "Object Explorer" in pgAdmin crashes server when pg-strom is installed
1
vote
0
answers
394
views
I'm trying to get to the bottom of some unusual behavior with pgAdmin4 when the GPU acceleration extension [pg-strom](https://heterodb.github.io/pg-strom/) is installed in PostgreSQL 14 and 15. Simple queries seem to work fine, but when trying to expand the "Schemas" section in pgAdmin4's "Object Explorer" window, it ***consistently*** crashes the whole database (trying to expand "Catalogues" or "Casts" has as similar effect).
I've tested it with a manual install on PostgreSQL 14 in a Debian 11 LXC container on Proxmox with an nVidia P1000 and on a native Debian 12 install using the unofficial [pg-strom/pg15 Docker image](https://github.com/murphye/pg-strom/tree/docker/docker) and an RTX 3060 Ti. Both had the same issues, my application's normal queries work fine, but trying to expand the "Schemas" section in pgAdmin4 crashes the whole database...
The other sections seem to open just fine so I'm not sure what's different with the "Schemas" section. Dropping the pg-strom extension ***and*** removing it from the "shared preload libraries" fixes the issue but disables GPU acceleration so it's not an ideal solution.
I've pulled the section from the logs where pgAdmin4 tries to execute whatever query it wants to when you try and expand the "Schemas" section:
2023-04-22 05:42:14.696 UTC LOG: server process (PID 3831) was terminated by signal 6: Aborted
2023-04-22 05:42:14.696 UTC DETAIL: Failed process was running: SELECT
nsp.oid,
nsp.nspname as name,
pg_catalog.has_schema_privilege(nsp.oid, 'CREATE') as can_create,
pg_catalog.has_schema_privilege(nsp.oid, 'USAGE') as has_usage
FROM
pg_catalog.pg_namespace nsp
WHERE
nspname NOT LIKE E'pg\\_%' AND
NOT (
(nsp.nspname = 'pg_catalog' AND EXISTS
(SELECT 1 FROM pg_catalog.pg_class WHERE relname = 'pg_class' AND
relnamespace = nsp.oid LIMIT 1)) OR
(nsp.nspname = 'pgagent' AND EXISTS
(SELECT 1 FROM pg_catalog.pg_class WHERE relname = 'pga_job' AND
relnamespace = nsp.oid LIMIT 1)) OR
(nsp.nspname = 'information_schema' AND EXISTS
(SELECT 1 FROM pg_catalog.pg_class WHERE relname = 'tables' AND
relnamespace = nsp.oid LIMIT 1))
)
ORDER BY nspname;
2023-04-22 05:42:14.696 UTC LOG: terminating any other active server processes
2023-04-22 05:42:14.698 UTC FATAL: the database system is in recovery mode
2023-04-22 05:42:14.717 UTC LOG: all server processes terminated; reinitializing
2023-04-22 05:42:15.215 UTC LOG: database system was interrupted; last known up at 2023-04-22 05:35:54 UTC
2023-04-22 05:42:15.216 UTC FATAL: the database system is in recovery mode
2023-04-22 05:42:15.233 UTC LOG: database system was not properly shut down; automatic recovery in progress
2023-04-22 05:42:15.236 UTC LOG: redo starts at 2/54CCC818
2023-04-22 05:42:15.236 UTC LOG: invalid record length at 2/54CCC850: wanted 24, got 0
2023-04-22 05:42:15.236 UTC LOG: redo done at 2/54CCC818 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
2023-04-22 05:42:15.239 UTC LOG: checkpoint starting: end-of-recovery immediate wait
2023-04-22 05:42:15.264 UTC LOG: checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.014 s, sync=0.004 s, total=0.028 s; sync files=2, longest=0.003 s, average=0.002 s; distance=0 kB, estimate=0 kB
2023-04-22 05:42:15.268 UTC LOG: CUDA Program Builder-1 with NVRTC version 12.0
2023-04-22 05:42:15.268 UTC LOG: CUDA Program Builder-0 with NVRTC version 12.0
2023-04-22 05:42:15.268 UTC LOG: database system is ready to accept connections
Trying to run "EXPLAIN" on the above query ***also*** causes the database to crash which seems a bit odd to me (something with the query planner maybe?)
Also notable: DBeaver has a similar(ish) object explorer to pgAdmin4 except ***their*** one works fine, although I really like the pgAdmin4 UI and the graphical query plan viewer so it'd be a shame to have to give that up.
## Does anyone know what would cause pgAdmin4 to crash the database with the above query only when pg-strom is installed? ##
The other sections seem to open just fine so I'm not sure what's different with the "Schemas" section. Dropping the pg-strom extension ***and*** removing it from the "shared preload libraries" fixes the issue but disables GPU acceleration so it's not an ideal solution.
I've pulled the section from the logs where pgAdmin4 tries to execute whatever query it wants to when you try and expand the "Schemas" section:
2023-04-22 05:42:14.696 UTC LOG: server process (PID 3831) was terminated by signal 6: Aborted
2023-04-22 05:42:14.696 UTC DETAIL: Failed process was running: SELECT
nsp.oid,
nsp.nspname as name,
pg_catalog.has_schema_privilege(nsp.oid, 'CREATE') as can_create,
pg_catalog.has_schema_privilege(nsp.oid, 'USAGE') as has_usage
FROM
pg_catalog.pg_namespace nsp
WHERE
nspname NOT LIKE E'pg\\_%' AND
NOT (
(nsp.nspname = 'pg_catalog' AND EXISTS
(SELECT 1 FROM pg_catalog.pg_class WHERE relname = 'pg_class' AND
relnamespace = nsp.oid LIMIT 1)) OR
(nsp.nspname = 'pgagent' AND EXISTS
(SELECT 1 FROM pg_catalog.pg_class WHERE relname = 'pga_job' AND
relnamespace = nsp.oid LIMIT 1)) OR
(nsp.nspname = 'information_schema' AND EXISTS
(SELECT 1 FROM pg_catalog.pg_class WHERE relname = 'tables' AND
relnamespace = nsp.oid LIMIT 1))
)
ORDER BY nspname;
2023-04-22 05:42:14.696 UTC LOG: terminating any other active server processes
2023-04-22 05:42:14.698 UTC FATAL: the database system is in recovery mode
2023-04-22 05:42:14.717 UTC LOG: all server processes terminated; reinitializing
2023-04-22 05:42:15.215 UTC LOG: database system was interrupted; last known up at 2023-04-22 05:35:54 UTC
2023-04-22 05:42:15.216 UTC FATAL: the database system is in recovery mode
2023-04-22 05:42:15.233 UTC LOG: database system was not properly shut down; automatic recovery in progress
2023-04-22 05:42:15.236 UTC LOG: redo starts at 2/54CCC818
2023-04-22 05:42:15.236 UTC LOG: invalid record length at 2/54CCC850: wanted 24, got 0
2023-04-22 05:42:15.236 UTC LOG: redo done at 2/54CCC818 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
2023-04-22 05:42:15.239 UTC LOG: checkpoint starting: end-of-recovery immediate wait
2023-04-22 05:42:15.264 UTC LOG: checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.014 s, sync=0.004 s, total=0.028 s; sync files=2, longest=0.003 s, average=0.002 s; distance=0 kB, estimate=0 kB
2023-04-22 05:42:15.268 UTC LOG: CUDA Program Builder-1 with NVRTC version 12.0
2023-04-22 05:42:15.268 UTC LOG: CUDA Program Builder-0 with NVRTC version 12.0
2023-04-22 05:42:15.268 UTC LOG: database system is ready to accept connections
Trying to run "EXPLAIN" on the above query ***also*** causes the database to crash which seems a bit odd to me (something with the query planner maybe?)
Also notable: DBeaver has a similar(ish) object explorer to pgAdmin4 except ***their*** one works fine, although I really like the pgAdmin4 UI and the graphical query plan viewer so it'd be a shame to have to give that up.
## Does anyone know what would cause pgAdmin4 to crash the database with the above query only when pg-strom is installed? ##
Asked by Sam
(111 rep)
Apr 22, 2023, 06:34 AM