From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(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-20 11:33:05 |
Message-ID: | CAA4eK1+xu-4CdbLkyeEdaC1qvjC_mDMD6UhTBwC4EBjuU4mymA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 18, 2017 at 7:56 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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,
>
Yes, that's one of the main things I was indicating for making the
behavior same, but again that could be done as a separate patch as
well.
> 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.
>
Agreed.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-05-20 11:42:55 | Re: [PATCH v2] Progress command to monitor progression of long running SQL queries |
Previous Message | Cyril Auburtin | 2017-05-20 08:27:34 | Allowing dash character in LTREE |