0

Currently I have only two tables - small one that works fine and another presumably large one. When I try to find out row count in pgAdmin I get the following error:

The application has lost the database connection:
⁃ If the connection was idle it may have been forcibly disconnected.
⁃ The application server or database server may have been restarted.
⁃ The user session may have timed out.
Do you want to continue and establish a new session?

I also checked the Postgres server logs:

2020-03-30 03:06:06.764 MSK [37356] LOG:  server process (PID 30712) was terminated by signal 9: Killed: 9
2020-03-30 03:06:06.764 MSK [37356] DETAIL:  Failed process was running: SELECT COUNT(*)::text FROM ios.task_info;
2020-03-30 03:06:06.764 MSK [37356] LOG:  terminating any other active server processes
2020-03-30 03:06:06.765 MSK [30810] WARNING:  terminating connection because of crash of another server process
2020-03-30 03:06:06.765 MSK [30810] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2020-03-30 03:06:06.765 MSK [30810] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2020-03-30 03:06:06.765 MSK [30709] WARNING:  terminating connection because of crash of another server process
2020-03-30 03:06:06.765 MSK [30709] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2020-03-30 03:06:06.765 MSK [30709] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2020-03-30 03:06:06.767 MSK [37356] LOG:  all server processes terminated; reinitializing
2020-03-30 03:06:06.776 MSK [30816] LOG:  database system was interrupted; last known up at 2020-03-30 02:51:14 MSK
2020-03-30 03:06:06.818 MSK [30817] FATAL:  the database system is in recovery mode
2020-03-30 03:06:06.853 MSK [30816] LOG:  database system was not properly shut down; automatic recovery in progress
2020-03-30 03:06:06.855 MSK [30816] LOG:  redo starts at 0/4F4DE850
2020-03-30 03:06:06.855 MSK [30816] LOG:  invalid record length at 0/4F4DE888: wanted 24, got 0
2020-03-30 03:06:06.855 MSK [30816] LOG:  redo done at 0/4F4DE850
2020-03-30 03:06:06.862 MSK [37356] LOG:  database system is ready to accept connections

I run everything on my OS X Catalina laptop and use PostgreSQL 12 EnterpriseDB.

Just in case if it is important - I created the large table sending several large CSV COPY queries in my Python script. What can be the reason of these errors?

Improve this question
6
  • 1
    Somebody or something killed your backend process with kill -9. If this were Linux, I'd point to the OOM killer. What is your work_mem and shared buffers set to? Can you look at the kernel logs?
    – Laurenz Albe
    Mar 30, 2020 at 4:30
  • 1
    I use OS X Catalina. I checked /var/log/system.log - nothing happened/appended there after count query crushes. Also I checked shared_buffers = 128MB in postgresql.conf. Thanks for trying to help!
    – Михаил Бабин
    Mar 30, 2020 at 9:18
  • Just to clarify - in postgresql.conf I see shared_buffers = 128MB and #work_mem = 4MB (commented).
    – Михаил Бабин
    Mar 30, 2020 at 9:25
  • 1
    Well, something external is killing your processes. That is not PostgreSQL's fault. You'll have to figure out who or what does that.
    – Laurenz Albe
    Mar 30, 2020 at 9:49
  • But it is killing the process right after every "SELECT COUNT(*)" query.
    – Михаил Бабин
    Mar 30, 2020 at 10:54

1 Answer 1

Reset to default
1

I run everything on my OS X Catalina laptop and use PostgreSQL 12 EnterpriseDB.

There is a JIT-related problem on this platform and version that leads to the kind of crash you're reporting. It's explained on mailing lists:

Re: PG v12.2 - Setting jit_above_cost is causing the server to crash

At the moment, the workaround seeems to be to set jit = off until EDB releases a new version with a fix, hopefully in PostgreSQL 12.3

Improve this answer
1
  • Thanks! Seems you are right! I tried SET jit_above_cost = -1; before query and it helped! Strange that even EXPLAIN ANALYSE SELECT COUNT(*) doesn't work if jit is on.
    – Михаил Бабин
    Mar 30, 2020 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.