psycopg2.OperationalError: SSL SYSCALL error: EOF detected
I am running a Discord bot SSApp on Railway, and when I execute SQL to a Postgres DB, I get this error.
After that, the following error occurs and access to the DB becomes impossible.
psycopg2.InterfaceError: connection already closed
Project ID : 8153aade-2cb8-4e3e-a2c6-36ad01e8f5fd
Solution:Jump to solution
hi @たけ , I had that issue under circumstances very similar to yours and this seems to have fixed it:
* adding 'NullPool' to the engine: engine = create_engine(DATABASE_URL, echo=True, future=True, pool_pre_ping=True, poolclass=NullPool)
* using a sessionmaker to do all db-related operations inside context managers with session objects instantiated from sessionmaker
hope this helps...
9 Replies
Project ID:
8153aade-2cb8-4e3e-a2c6-36ad01e8f5fdmake sure you aren't keeping idle connections open
Regarding psycopg2, I changed the description in requirements.txt from psycopg2-binary to psycopg2 and this error no longer occurs.
Instead, the following error occurs periodically. What is the cause of this?
discord.errors.ConnectionClosed: Shard ID None WebSocket closed with 1000
I think it is a normal implementation, though I use psycopg2.connect to connect when the bot starts and close when the bot exits.
No, I still get the first error. Can someone tell me what's causing it?
you are keeping closed connections around
I'm asking because this is the error that triggered the disconnection.
After changing the Postgres operation from psycopg2 to asyncpg, the first error does not seem to occur now. However, the following errors occur periodically
make sure you aren't keeping idle connections open
I have tried connecting only when DB operations are required and disconnecting when done, but the error still occurs
Solution
hi @たけ , I had that issue under circumstances very similar to yours and this seems to have fixed it:
* adding 'NullPool' to the engine: engine = create_engine(DATABASE_URL, echo=True, future=True, pool_pre_ping=True, poolclass=NullPool)
* using a sessionmaker to do all db-related operations inside context managers with session objects instantiated from sessionmaker
hope this helps
not sure if only one of those changes or both did the trick though