=?utf-8?Q?J=C4=81nis_P=C5=ABris?= <janis@xxxxxxxx> writes: > I'm trying to do a simple health check for keepalived and other services via a python script and psycopg2 library. All seems to be all right, until I close the connection, at which point a packet with TCP reset is produced. Hm. It's fairly obvious from the postmaster log that the client side is not bothering to close the transaction it started: > 2019-04-23 16:27:45.306 CEST process=15615 c=BEGIN t=0 s=5cbf20e1.3cff monitoring@127.0.0.1:postgres app=[unknown] LOG: duration: 0.095 ms > 2019-04-23 16:27:45.306 CEST process=15615 c=SELECT t=0 s=5cbf20e1.3cff monitoring@127.0.0.1:postgres app=[unknown] LOG: duration: 0.234 ms > 2019-04-23 16:27:45.306 CEST process=15615 c=idle in transaction t=0 s=5cbf20e1.3cff monitoring@127.0.0.1:postgres app=[unknown] LOG: disconnection: session time: 0:00:00.006 user=monitoring database=postgres host=127.0.0.1 port=40797 There's no COMMIT or ROLLBACK to go with the BEGIN, and that's reflected in the fact that the disconnection message shows c=idle in transaction. Now, I doubt that would have any impact on the TCP-level session behavior, but it suggests that maybe the client isn't bothering to close the session cleanly either. The RST rather than FIN would then likely be caused by SSL having to do an unclean shutdown. regards, tom lane
