| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Suraj Kharage <suraj(dot)kharage(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: statement_timeout is not working as expected with postgres_fdw |
| Date: | 2017-05-18 14:26:51 |
| Message-ID: | CA+TgmoZZstFsFw=cKjGWsndifqBakD-B_BNxt8rqsT9xhVoUeA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 17, 2017 at 6:57 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> +1. Why not similar behavior for any other statements executed in
> this module by do_sql_command?
The other cases are not quite the same situation. It would be good to
accept interrupts in all cases, but there's no problem with a session
continuing to be used after a failure in configure_remote_session()
because the connection hasn't been entered in the hash table at that
point yet, and the TRY/CATCH block in connect_pg_server() ensures that
the connection also gets closed. So we don't need to worry about
those statements leaving behind messed-up sessions; they won't; only
the transaction control commands have that part of the problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-05-18 14:30:38 | Re: [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur |
| Previous Message | Robert Haas | 2017-05-18 14:16:35 | Re: Get stuck when dropping a subscription during synchronizing table |