On Thu, May 18, 2017 at 7:56 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, May 17, 2017 at 6:57 AM, Amit Kapila <amit.kapil...@gmail.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

> 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.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to