Thread: BUG #16704: Segmentation Problem - SSL SYSCALL error: EOF detected

The following bug has been logged on the website:

Bug reference:      16704
Logged by:          Henryk Korulski
Email address:      hko@framelogic.pl
PostgreSQL version: 13.0
Operating system:   PostgreSQL 13.0 (Debian 13.0-1.pgdg90+1) on x86_64
Description:

We use PG12 Database. After upgrade it to version 13 we have problems with
random query - error SSL SYSCALL error: EOF detected.
It appears on many tables (when selecting data or when inserting). I watch
one select query causes this error. I copied sql query from script and
execute nativly in psql and the problem was the same result with error.

After VACUUM FULL ANALYZE my table, i executed once again my query and query
result was succes. It has been working about 25 minuts and then i got the
same error.

Problem is very similar like
https://www.postgresql.org/message-id/15219.1541773523%40sss.pgh.pa.us

Please HELP.

Best regards
Henryk


My query:
select distinct pam.dscr, p.pojazd_id, m.nazwa, model, nr_rejestracyjny,
                (
                    select array_to_string( array(
                        select distinct f.firma1_id || '::' || f.nazwa
                        FROM grupa_pojazdow_pojazd gpp
                        join grupa_pojazdow gp on gp.grupa_pojazdow_id =
gpp.grupa_pojazdow_id
                        join firma1 f on gp.firma1_id = f.firma1_id
                        where gpp.pojazd_id = p.pojazd_id
                        order by f.firma1_id || '::' || f.nazwa
                    )
                    , '|' )
                ) as firms
                from pojazd p
                join marka m on m.marka_id = p.marka_id
                join pojazd_admin_multi pam on (pam.pojazd_id = p.pojazd_id
and pam.datetime_to is null)
                where dscr is not null
                order by p.pojazd_id

2020-11-05 13:03:24.906 CET [28788] LOG:  background worker "parallel worker" (PID 30704) was terminated by signal 11: Segmentation fault
2020-11-05 13:03:24.906 CET [28788] DETAIL:  Failed process was running: ...
2020-11-05 13:03:24.906 CET [28788] LOG:  terminating any other active server processes
2020-11-05 13:03:24.906 CET [30688] crons_user@db01 WARNING:  terminating connection because of crash of another server process
2020-11-05 13:03:24.906 CET [30688] crons_user@db01 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.

The following bug has been logged on the website:

Bug reference:      16704
Logged by:          Henryk Korulski
Email address:      hko@framelogic.pl
PostgreSQL version: 13.0
Operating system:   PostgreSQL 13.0 (Debian 13.0-1.pgdg90+1) on x86_64
Description:        

We use PG12 Database. After upgrade it to version 13 we have problems with
random query - error SSL SYSCALL error: EOF detected.
It appears on many tables (when selecting data or when inserting). I watch
one select query causes this error. I copied sql query from script and
execute nativly in psql and the problem was the same result with error.

After VACUUM FULL ANALYZE my table, i executed once again my query and query
result was succes. It has been working about 25 minuts and then i got the
same error.

Problem is very similar like
https://www.postgresql.org/message-id/15219.1541773523%40sss.pgh.pa.us

Please HELP.

Best regards
Henryk


My query:
select distinct pam.dscr, p.pojazd_id, m.nazwa, model, nr_rejestracyjny,                (                    select array_to_string( array(                        select distinct f.firma1_id || '::' || f.nazwa                        FROM grupa_pojazdow_pojazd gpp                        join grupa_pojazdow gp on gp.grupa_pojazdow_id =
gpp.grupa_pojazdow_id                        join firma1 f on gp.firma1_id = f.firma1_id                        where gpp.pojazd_id = p.pojazd_id                        order by f.firma1_id || '::' || f.nazwa                    )                    , '|' )                ) as firms                from pojazd p                join marka m on m.marka_id = p.marka_id                join pojazd_admin_multi pam on (pam.pojazd_id = p.pojazd_id
and pam.datetime_to is null)                where dscr is not null                order by p.pojazd_id

On Thu, Nov 05, 2020 at 12:07:38PM +0000, PG Bug reporting form wrote:
> After VACUUM FULL ANALYZE my table, i executed once again my query and query
> result was succes. It has been working about 25 minuts and then i got the
> same error.
>
> Problem is very similar like
> https://www.postgresql.org/message-id/15219.1541773523%40sss.pgh.pa.us

Hard to tell if that's the same issue based on the amount of
information given.  Providing a stack trace would help:
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows

A self-contained test case is also nice to have.  Based on the query
given anybody looking at this report has to guess what is the schema
used in your application.
--
Michael

On Fri, Nov 06, 2020 at 10:14:56AM +0900, Michael Paquier wrote:
> Hard to tell if that's the same issue based on the amount of
> information given.  Providing a stack trace would help:
> https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
>
> A self-contained test case is also nice to have.  Based on the query
> given anybody looking at this report has to guess what is the schema
> used in your application.

Another thing that would be really helpful is to know the version of
OpenSSL you have here.  It could be possible that this reflects an
error triggered internally by OpenSSL.
--
Michael

On Fri, Nov 6, 2020 at 3:40 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Fri, Nov 06, 2020 at 10:14:56AM +0900, Michael Paquier wrote:
> > Hard to tell if that's the same issue based on the amount of
> > information given.  Providing a stack trace would help:
> > https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
> >
> > A self-contained test case is also nice to have.  Based on the query
> > given anybody looking at this report has to guess what is the schema
> > used in your application.
>
> Another thing that would be really helpful is to know the version of
> OpenSSL you have here.  It could be possible that this reflects an
> error triggered internally by OpenSSL.

I guess the Debian version is better for this:

https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD

Also, could we please see the query plan?  (EXPLAIN SELECT ...)