Horton

RE: Timeout parameters

Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>

View thread View on postgr.es
From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: 'Robert Haas' <robertmhaas@gmail.com>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>, "Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>, "Jamison, Kirk" <k.jamison@jp.fujitsu.com>, Michael Paquier <michael@paquier.xyz>, "AYahorau@ibagroup.eu" <AYahorau@ibagroup.eu>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "MikalaiKeida@ibagroup.eu" <MikalaiKeida@ibagroup.eu>
Date: 2019-03-15T00:27:14Z
Lists: pgsql-hackers 
From: Robert Haas [mailto:robertmhaas@gmail.com]
> One other thing -- I looked a bit into the pgsql-jdbc implementation
> of a similarly-named option, and it does seem to match what you are
> proposing here.  I wonder what user experiences with that option have
> been like.

One case I faintly recall is that some SQL execution got stuck in NFS access in the server, and statement_timeout didn't work (probably due to inability to cancel NFS read/write operations).  The user chose to use PgJDBC's socketTimeout.  I'm not sure whether this use case is fundamental, because I wonder if NFS mount options could have been the solution.


Regards
Takayuki Tsunakawa

Commits

  1. Add support TCP user timeout in libpq and the backend server