On Thu, May 4, 2017 at 6:23 AM, tushar <tushar.ahuja@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