Обсуждение: Clearing psql's input buffer after auto-reconnect
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > 3. Have CheckConnection do longjmp(sigint_interrupt_jmp) after resetting ... > 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? I like #3. If this were a more common event I might lean towards #1 but it's not so #3 seems fine. - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201005251113 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkv76TYACgkQvJuQZxSWSsiP6wCePU5TDpfFiv7MQpQ0vdIMms0d XZcAoMES58ilXZr2m5TEfeRUeiuuuss2 =36Z9 -----END PGP SIGNATURE-----
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 queriesafter reconnection * http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php * http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com