On Thu, May 4, 2017 at 6:23 AM, tushar <tushar.ah...@enterprisedb.com> wrote: > We can see statement_timeout is working but it is taking some extra time,not > sure this is an expected behavior in above case or not.
Yeah, that's expected. To fix that, we'd need libpq to have an async equivalent of PQcancel(), which doesn't currently exist. I think it would be a good idea to add that, but that's another discussion. With this patch: 1. If postgres_fdw is waiting for one of the cleanup queries to execute, you can cancel it, and things like statement_timeout will also work. 2. If the cancel fails or any of the cleanup queries fail, postgres_fdw will forcibly close the connection and force the current transaction and all subtransactions to abort. This isn't wonderful behavior, but if we can't talk to the remote server any more there doesn't seem to be any other real alternative. (We could improve this, I think, by tracking whether the connection had ever been use by an outer transaction level, and if not, allowing the transaction to commit if it never again tried to access the failed connection, but I left the design and installation of such a mechanism to a future patch.) 3. But if you're stuck trying to send the cancel request itself, you still have to wait for that to fail before anything else happens. Once it does, we'll proceed as outlined in point #2. This stinks, but it's the inevitable consequence of having no async equivalent of PQcancel(). My goal is to make things noticeably better with this patch, not to fix them completely. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
