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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
