diff -ruN postgresql-8.4.8_orig/src/bin/psql/common.c postgresql-8.4.8_new/src/bin/psql/common.c
--- postgresql-8.4.8_orig/src/bin/psql/common.c	2011-04-15 05:17:14.000000000 +0200
+++ postgresql-8.4.8_new/src/bin/psql/common.c	2011-05-04 17:19:16.000000000 +0200
@@ -345,6 +345,7 @@
 		}
 
 		fputs(_("The connection to the server was lost. Attempting reset: "), stderr);
+		bool oldInTransaction = (PQtransactionStatus(pset.db) == PQTRANS_INTRANS || PQtransactionStatus(pset.db) == PQTRANS_INERROR);
 		PQreset(pset.db);
 		OK = ConnectionUp();
 		if (!OK)
@@ -356,7 +357,18 @@
 			UnsyncVariables();
 		}
 		else
+		{
 			fputs(_("Succeeded.\n"), stderr);
+			/* If we were in a db transaction then the queries before re-connection will be rolled back; the only consistent situation
+				(from being-executed script point of view) is if the queries issued by it after automatic reconnection also fail
+				up until this script issues commit/rollback. I.e. the next queries should be executed in a context of a rolled-back
+				db transaction: */
+			if ( oldInTransaction )
+			{
+				PQexec(pset.db, "BEGIN");
+				PQexec(pset.db, "SELECT 1/0"); /* FIXME: what is a more decent way to raise an exception with comments "old trans rolled back due to backend re-connect"? */
+			}
+		}
 	}
 
 	return OK;
diff -ruN postgresql-8.4.8_orig/src/interfaces/libpq/fe-connect.c postgresql-8.4.8_new/src/interfaces/libpq/fe-connect.c
--- postgresql-8.4.8_orig/src/interfaces/libpq/fe-connect.c	2011-05-04 15:10:46.000000000 +0200
+++ postgresql-8.4.8_new/src/interfaces/libpq/fe-connect.c	2011-05-04 17:19:40.000000000 +0200
@@ -3537,7 +3537,7 @@
 PGTransactionStatusType
 PQtransactionStatus(const PGconn *conn)
 {
-	if (!conn || conn->status != CONNECTION_OK)
+	if (!conn /*|| conn->status != CONNECTION_OK*/)
 		return PQTRANS_UNKNOWN;
 	if (conn->asyncStatus != PGASYNC_IDLE)
 		return PQTRANS_ACTIVE;