Tom Lane wrote:
> 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?
Added to TODO:
Prevent psql from sending remaining single-line multi-statement queries
after reconnection
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
