Prev: [HACKERS] libpq, PQexecPrepared, data size sent to FE vs. FETCH_COUNT
Next: Regression testing for psql
From: Tom Lane on 24 May 2010 22:30 We determined that $SUBJECT would be a good idea in this thread: http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php I looked a bit at what it would take to make this happen. The difficulty is that the input buffer is a local variable in MainLoop(), and so are a bunch of other subsidiary variables that would need to be reset along with it. The place where auto-reconnect presently happens is CheckConnection(), which is in a different file and is also several levels of subroutine call away from MainLoop. AFAICS there are three ways that we might attack this: 1. Massive restructuring of the code in common.c so that the fact of a connection reset having happened can be returned back to MainLoop. 2. Export much of MainLoop's internal state as globals, so that CheckConnection can hack on it directly. 3. Have CheckConnection do longjmp(sigint_interrupt_jmp) after resetting the connection, to force control to go back to MainLoop directly. MainLoop is already coded to clear its local state after catching a longjmp. Now #1 might be the best long-term solution but I have no particular appetite to tackle it, and #2 is just too ugly to contemplate. That leaves #3, which is a bit ugly in its own right but seems like the best fix we're likely to get. Comments, better ideas? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |