On Thu, Jan 30, 2020 at 9:04 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Jan 29, 2020 at 8:29 PM Robert Haas <robertmh...@gmail.com> wrote: > > > > On Wed, Jan 29, 2020 at 6:04 AM vignesh C <vignes...@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
