If the query is autocommit, or if your query was a COMMIT that was in-flight at the time you killed the client/lost the connection, it is possible for a transaction to be in an indeterminate state where the client doesn't know whether or not it committed. Possibly a nice feature, but not currently supported. Essentially you'd have to implement asynchronous/background queries. To change that you'd need some kind of query completion token that you could obtain at query start, then use to ask the server about the query via another connection later. As far as PostgreSQL is concerned if the client goes away its job is to terminate any queries the client was running. PostgreSQL checks for interrupts at each row it sends. If the client is killed by something like a sudden OS reboot, so that the client host suddenly knows nothing about the TCP connection but can still respond on the network, the query will probably get aborted the first time it triest to write a row, like Jeff said, because the client's host will send a TCP RST in response to the first packet sent by the server after the reboot. It'll pretty much always see the interrupt and abort before completing and committing if it's autocommit, though.
#SET QUERY TIMEOUT IN POSTICO CODE#
Sometimes a query might be doing CPU-heavy work within code that doesn't check for interrupts - some extensions, and a few places within the PostgreSQL core - in which case it might not notice the interrupt for a long time and keep on running. Next time the query checks for interrupts as it executes it will see the flag and abort. If the client is killed in a way that the client's operating system can report to the server via a TCP RST (like a client segfault/crash, SIGTERM, SIGKILL, etc), the PostgreSQL server will set the interrupt flag. If it completes before it fills the TCP send buffer it'll complete successfully, so if it's autocommit the query will commit. If the client vanishes due to network connection loss the query will generally run until it's retrieved enough rows to fill its network send buffer, then stop and get stuck until the TCP connection drops, at which point it'll abort.
0 kommentar(er)
