PostgREST
Transient `SSL SYSCALL error: EOF detected`
Problem
Now that we no longer ignore errors on the LISTEN channel (https://github.com/PostgREST/postgrest/pull/3533) sometimes there are transient errors that shouldn't affect end users since PostgREST will recover immediately.
One example is SSL SYSCALL error: EOF detected:
Failed listening for notifications on the "pgrst" channel. SSL SYSCALL error: EOF detected
Retrying listening for notifications in 1 seconds...
Listening for notifications on the "pgrst" channel
The LISTEN connection might be interrupted by a proxy. We got the same report on https://github.com/PostgREST/postgrest/discussions/3313#discussioncomment-8777386.
Solution
Detect this error and indicate it's transient on the logs.
With that said, my own personal opinion is that a transient error with remaining retries does not warrant an error event. Maybe a warning. https://github.com/dotnet/efcore/issues/15269#issuecomment-483887135
I agree with the above. We should log the SSL error only at the warning level.
If the retrying delay goes beyond 1 second only then log an error? Or maybe just detect the SSL syscall message?
Hey guys I'm encountering this error in Supabase, which uses PostgREST so getting :
"Failed listening for notifications on the \"pgrst\" channel. SSL SYSCALL error: EOF detected"
and then
"HINT: In a moment you should be able to reconnect to the database and repeat your command."
followed by
"Retrying listening for notifications in 1 seconds..."
"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."
and the evilish
"WARNING: terminating connection because of crash of another server process"
which - for my Python backened - ends up in :
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) SSL connection has been closed unexpectedly
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.
That very much sounds like a problem with your PostgreSQL instance, not with PostgREST.
