Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw
Date
Msg-id CAA4eK1JNw0cqq4PGpMU1jszVRN9uWN=Xq-DYhTkWiJV1AgKAcw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, May 16, 2017 at 9:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sun, May 7, 2017 at 11:54 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I'm having second thoughts based on some more experimentation I did
>> this morning.  I'll update again once I've had a bit more time to poke
>> at it.
>
> So the issue that I noticed here is that this problem really isn't
> confined to abort processing.  If we ROLLBACK TO SAVEPOINT or ABORT
> TRANSACTION on an open connection, we really do not know what the
> state of that connection is until we get an acknowledgement that the
> command completed successfully.  The patch handles that.  However, the
> same is true if we're sending a SAVEPOINT or RELEASE SAVEPOINT
> command, and the patch that I posted doesn't do anything about those
> cases.  I think it would be best to fix all transaction control
> commands in a symmetric manner.
>

+1.  Why not similar behavior for any other statements executed in
this module by do_sql_command?

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



pgsql-hackers by date:

Previous
From: Jeevan Ladhe
Date:
Subject: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table