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-06 16:55:19 |
Message-ID: | CA+TgmoYeWjo36O07dVjVZ+K-dRGQk45--45=b_7HoNqs1M3kQw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 5, 2017 at 7:11 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> There is a comment in the code which explains why currently we ignore
> errors from DEALLOCATE ALL.
>
> * DEALLOCATE ALL only exists in 8.3 and later, so this
> * constrains how old a server postgres_fdw can
> * communicate with. We intentionally ignore errors in
> * the DEALLOCATE, so that we can hobble along to some
> * extent with older servers (leaking prepared statements
> * as we go; but we don't really support update operations
> * pre-8.3 anyway).
>
> It is not entirely clear to me whether it is only for Commit case or
> in general. From the code, it appears that the comment holds true for
> both commit and abort. If it is for both, then after this patch, the
> above comment will not be valid and you might want to update it in
> case we want to proceed with your proposed changes for DEALLOCATE ALL
> statement.
Oh! Good catch. Given that the behavior in question is intentional
there and intended to provide backward compatibility, changing it in
back-branches doesn't seem like a good plan. I'll adjust the patch so
that it continues to ignore errors in that case.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2017-05-06 16:56:27 | Re: Draft release notes for next week's back-branch releases |
Previous Message | Tom Lane | 2017-05-06 16:16:43 | Re: Draft release notes for next week's back-branch releases |