PostgreSQL: SSL SYSCALL error: EOF detected

First, I've searched for and found several posts relating to this error, and most of them point either to a RAM issue or an SSL issue, I tried overcoming the SSL possibility by adding the sslmode=disabled in the command line:

psql -U waypoint -d waypoint -W -c "alter table telemetria_data.historico alter clase type smallint, alter valor type real[], alter power type smallint, alter voltaje type real;" -h localhost -v sslmode=disable

But the same message appeared:

SSL SYSCALL error: EOF detected
connection to server was lost

Regarding the possible memory issue, I don't know how to troubleshoot it.

The data structure is the one described in this question and, as you may found this would a very long running query to complete achieve the full alter table over all the inherited tables.

OS:

Linux ip-10-1-0-9 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux

PostgreSQL:

PostgreSQL 9.4.9 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit

Update 2017-06-01 13:50 GMT

Changed command to (due to @ Daniel Vérité 's recommendations):

time PGSSLMODE=disable psql -U waypoint -d waypoint -W -c "alter table telemetria_data.historico alter clase type smallint, alter valor type real[], alter power type smallint, alter voltaje type real;" -h localhost

Problem actually changed to the following:

server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request.
connection to server was lost

Update 2017-06-01 15:34 GMT

Found several log entries (in /var/log/postgresql/postgresql-9.4-main.log) like these:

2017-06-01 13:48:49 UTC [22899-357] LOG:  checkpoints are occurring too frequently (19 seconds apart)
2017-06-01 13:48:49 UTC [22899-358] HINT:  Consider increasing the configuration parameter "checkpoint_segments".

So I'll proceed with the suggested hint.

Also found this group of entri

My guess is that you're running PostgreSQL on AWS. If so, you need to identify this in the question and the tags.

The last process mentioned in the kernel dump is in fact aws so it seems like a safe bet

Jun  1 13:49:04 ip-10-1-0-9 kernel: [260956.963722] [16368]  1000 16368     7725     1044      19        0             0 aws

With regard to PostgreSQL, this just implies a connection failure

As far as trouble shooting it what is triggering aws's oom_killer, you have two options..

• Lower work_mem below the threshold that triggers oom_killer. Whatever query gets planned differently around the difference in memory or is slower is the one that is holding you up.

• Set log_statement and read the last queries issues before the out of memory crash.

StackExchange Database Administrators Q#175085, answer score: 7