On Thu, Jan 30, 2020 at 9:04 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Jan 29, 2020 at 8:29 PM Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > On Wed, Jan 29, 2020 at 6:04 AM vignesh C <vignesh21@gmail.com> wrote:
> > > Thanks for your review and suggestion. I have made a patch based on
> > > similar lines. Attached patch has the doc update with the explanation.
> > > Thoughts?
> >
> > Documenting this doesn't seem very useful to me.
> >
>
> I thought of documenting it because this has been reported/discussed
> multiple times (see some of the links of discussions at the end of the
> first email) and every time we need to spend time explaining the same
> thing. However, if we decide not to do that I am fine with it.
>
Does anybody else have any opinion on whether it makes sense to
document this behavior? To summarize for others, the behavior
difference as noted by Vignesh in his patch is:
+
+ <para>
+ You will get server closed the connection unexpectedly message while
+ trying to execute sql command on disconnected connection. The message is
+ slightly different in windows and non-windows. In non-windows, you will
+ see a FATAL message before the error message:
+<screen>
+FATAL: terminating connection due to idle-in-transaction timeout
+server closed the connection unexpectedly
+ This probably means the server terminated abnormally
+ before or while processing the request.
+The connection to the server was lost. Attempting reset: Succeeded.
+</screen>
+ In windows, you might not see the FATAL message:
+<screen>
+server closed the connection unexpectedly
+ This probably means the server terminated abnormally
+ before or while processing the request.
+The connection to the server was lost. Attempting reset: Succeeded.
We have spent a decent amount of time on this and it is due to windows
API behaving differently. By documenting, we might avoid the future
effort of explaining this to users.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com