On Wed, Jun 7, 2017 at 11:20 AM, Amit Kapila wrote:
> On Sat, Jun 3, 2017 at 1:03 AM, Robert Haas wrote:
>> On Fri, Jun 2, 2017 at 3:48 AM, Rafia Sabih
>> wrote:
>> I don't see how to do that. It could possibly be done with the TAP
>> framework, but that exceeds my abilities.
>>
>> Here's an up
On Sat, Jun 3, 2017 at 1:03 AM, Robert Haas wrote:
> On Fri, Jun 2, 2017 at 3:48 AM, Rafia Sabih
> wrote:
>
> I don't see how to do that. It could possibly be done with the TAP
> framework, but that exceeds my abilities.
>
> Here's an updated patch with a bunch of cosmetic fixes, plus I
> adjust
On Fri, Jun 2, 2017 at 3:48 AM, Rafia Sabih
wrote:
> I tried following the sketch stated above, and here's what I added to
> v2 of the patch. In begin_remote_xact when savepoint is send to the
> remote server through do_sql_command I set the changing_xact_state
> flag and when it successfully retu
On Tue, May 16, 2017 at 9:39 PM, Robert Haas wrote:
> On Sun, May 7, 2017 at 11:54 AM, Robert Haas 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
On Thu, May 18, 2017 at 7:56 PM, Robert Haas wrote:
> On Wed, May 17, 2017 at 6:57 AM, Amit Kapila 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 int
On Wed, May 17, 2017 at 6:57 AM, Amit Kapila 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, but there's no problem with a session
co
On Tue, May 16, 2017 at 9:39 PM, Robert Haas wrote:
> On Sun, May 7, 2017 at 11:54 AM, Robert Haas 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
On Wed, May 17, 2017 at 7:24 AM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Tue, 16 May 2017 12:45:39 -0400, Tom Lane wrote in
> <22556.1494953...@sss.pgh.pa.us>
>> Robert Haas writes:
>> > Concretely, I think we should replace the abort_cleanup_incomplete
>> > flag from my previous patch with a
Hello,
At Tue, 16 May 2017 12:45:39 -0400, Tom Lane wrote in
<22556.1494953...@sss.pgh.pa.us>
> Robert Haas writes:
> > Concretely, I think we should replace the abort_cleanup_incomplete
> > flag from my previous patch with a changing_xact_state flag and set
> > that flag around all transaction
Robert Haas writes:
> Concretely, I think we should replace the abort_cleanup_incomplete
> flag from my previous patch with a changing_xact_state flag and set
> that flag around all transaction state changes, clearing it when such
> changes have succeeded. On error, the flag remains set, so we kn
On Sun, May 7, 2017 at 11:54 AM, Robert Haas 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 processi
On Sun, May 7, 2017 at 12:42 AM, Amit Kapila wrote:
> On Sat, May 6, 2017 at 10:41 PM, Robert Haas wrote:
>> On Sat, May 6, 2017 at 12:55 PM, Robert Haas wrote:
>>> Oh! Good catch. Given that the behavior in question is intentional
>>> there and intended to provide backward compatibility, chan
On Sat, May 6, 2017 at 10:41 PM, Robert Haas wrote:
> On Sat, May 6, 2017 at 12:55 PM, Robert Haas wrote:
>> 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.
On Sat, May 6, 2017 at 12:55 PM, Robert Haas wrote:
> 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 e
On Fri, May 5, 2017 at 7:11 PM, Amit Kapila 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 intentional
On Sat, May 6, 2017 at 4:41 AM, Amit Kapila wrote:
> On Fri, May 5, 2017 at 9:32 PM, Robert Haas wrote:
>> On Fri, May 5, 2017 at 11:15 AM, Amit Kapila wrote:
>>> I am not saying to rip those changes. Your most of the mail stresses
>>> about the 30-second timeout which you have added in the pat
On Fri, May 5, 2017 at 9:32 PM, Robert Haas wrote:
> On Fri, May 5, 2017 at 11:15 AM, Amit Kapila wrote:
>> I am not saying to rip those changes. Your most of the mail stresses
>> about the 30-second timeout which you have added in the patch to
>> detect timeouts during failures (rollback proces
On Fri, May 5, 2017 at 11:15 AM, Amit Kapila wrote:
> I am not saying to rip those changes. Your most of the mail stresses
> about the 30-second timeout which you have added in the patch to
> detect timeouts during failures (rollback processing). I have no
> objection to that part of the patch e
On Fri, May 5, 2017 at 7:44 PM, Robert Haas wrote:
> On Fri, May 5, 2017 at 1:01 AM, Amit Kapila wrote:
>> I have tried to verify above point and it seems to me in such a
>> situation the transaction status will be either PQTRANS_INTRANS or
>> PQTRANS_INERROR. I have tried to mimic "out of memor
On Fri, May 5, 2017 at 1:01 AM, Amit Kapila wrote:
> I have tried to verify above point and it seems to me in such a
> situation the transaction status will be either PQTRANS_INTRANS or
> PQTRANS_INERROR. I have tried to mimic "out of memory" failure by
> making PQmakeEmptyPGresult return NULL (m
On Thu, May 4, 2017 at 10:40 PM, Robert Haas wrote:
> On Thu, May 4, 2017 at 1:04 PM, Amit Kapila wrote:
>> On Thu, May 4, 2017 at 10:18 PM, Robert Haas wrote:
>>> On Thu, May 4, 2017 at 12:18 PM, Amit Kapila
>>> wrote:
As soon as the first command fails due to timeout, we will set
'
On Thu, May 4, 2017 at 8:08 PM, Robert Haas wrote:
> On Thu, May 4, 2017 at 7:13 AM, Amit Kapila wrote:
>> In pgfdw_xact_callback, if the execution of ABORT TRANSACTION fails
>> due to any reason then I think it will close the connection. The
>> relavant code is:
>> if (PQstatus(entry->conn) !=
On Thu, May 4, 2017 at 1:04 PM, Amit Kapila wrote:
> On Thu, May 4, 2017 at 10:18 PM, Robert Haas wrote:
>> On Thu, May 4, 2017 at 12:18 PM, Amit Kapila wrote:
>>> As soon as the first command fails due to timeout, we will set
>>> 'abort_cleanup_failure' which will make a toplevel transaction to
On Thu, May 4, 2017 at 10:18 PM, Robert Haas wrote:
> On Thu, May 4, 2017 at 12:18 PM, Amit Kapila wrote:
>> As soon as the first command fails due to timeout, we will set
>> 'abort_cleanup_failure' which will make a toplevel transaction to
>> abort and also won't allow other statements to execut
On Thu, May 4, 2017 at 12:18 PM, Amit Kapila wrote:
> As soon as the first command fails due to timeout, we will set
> 'abort_cleanup_failure' which will make a toplevel transaction to
> abort and also won't allow other statements to execute. The patch is
> trying to enforce a 30-second timeout a
On Thu, May 4, 2017 at 8:08 PM, Robert Haas wrote:
> On Thu, May 4, 2017 at 7:13 AM, Amit Kapila wrote:
>
>>> - For bonus points, give pgfdw_exec_query() an optional timeout
>>> argument, and set it to 30 seconds or so when we're doing abort
>>> cleanup. If the timeout succeeds, it errors out (w
On Thu, May 4, 2017 at 7:13 AM, Amit Kapila wrote:
> In pgfdw_xact_callback, if the execution of ABORT TRANSACTION fails
> due to any reason then I think it will close the connection. The
> relavant code is:
> if (PQstatus(entry->conn) != CONNECTION_OK ||
> PQtransactionStatus(entry->conn) != PQT
On Thu, May 4, 2017 at 1:19 AM, Robert Haas wrote:
> On Thu, Apr 20, 2017 at 10:27 AM, Ashutosh Bapat
> wrote:
>> The logs above show that 34 seconds elapsed between starting to abort
>> the transaction and knowing that the foreign server is unreachable. It
>> looks like it took that much time fo
On Thu, May 4, 2017 at 6:23 AM, tushar wrote:
> We can see statement_timeout is working but it is taking some extra time,not
> sure this is an expected behavior in above case or not.
Yeah, that's expected. To fix that, we'd need libpq to have an async
equivalent of PQcancel(), which doesn't curr
On 05/04/2017 03:53 PM, tushar wrote:
We can see statement_timeout is working but it is taking some extra
time,not sure this is an expected behavior in above case or not.
This is only when remote server is involved . in case when both the
servers are on the same machine , then this is working a
On 05/04/2017 08:01 AM, Robert Haas wrote:
Patch attached.
I tried at my end after applying the patch against PG HEAD,
Case 1 - without setting statement_timeout i.e default
X machine -
create table test1(a int);
Y machine -
CREATE SERVER myserver_ppas FOREIGN DATA WRAPPER postgres_fdw OPTIO
On Wed, May 3, 2017 at 3:49 PM, Robert Haas wrote:
> It seems pretty clear to me that we are not going to fix all of these
> issues in one patch. Here's a sketch of an idea for how to start
> making things better:
Patch attached.
> - Add an in_abort_cleanup flag to ConnCacheEntry.
Ended up ren
On Thu, Apr 20, 2017 at 10:27 AM, Ashutosh Bapat
wrote:
> The logs above show that 34 seconds elapsed between starting to abort
> the transaction and knowing that the foreign server is unreachable. It
> looks like it took that much time for the local server to realise that
> the foreign server is
At Tue, 25 Apr 2017 15:43:59 +0530, Ashutosh Bapat
wrote in
> On Tue, Apr 25, 2017 at 1:31 PM, Kyotaro HORIGUCHI
> wrote:
> >>
> >> The logs above show that 34 seconds elapsed between starting to abort
> >> the transaction and knowing that the foreign server is unreachable. It
> >> looks like
On Tue, Apr 25, 2017 at 1:31 PM, Kyotaro HORIGUCHI
wrote:
>>
>> The logs above show that 34 seconds elapsed between starting to abort
>> the transaction and knowing that the foreign server is unreachable. It
>> looks like it took that much time for the local server to realise that
>> the foreign s
Hello,
At Thu, 20 Apr 2017 19:57:30 +0530, Ashutosh Bapat
wrote in
> On Thu, Apr 20, 2017 at 4:08 PM, Suraj Kharage
> wrote:
> > Hello All,
> >
> > The query on foreign table hangs due to network down of remote server for
> > near about 16 minutes before exiting.
> > statement_timeout is expe
On Thu, Apr 20, 2017 at 4:08 PM, Suraj Kharage
wrote:
> Hello All,
>
> The query on foreign table hangs due to network down of remote server for
> near about 16 minutes before exiting.
> statement_timeout is expected to work in this case as well but when i tried
> statement_timeout, it is not work
Hello All,
The query on foreign table hangs due to network down of remote server for
near about 16 minutes before exiting.
statement_timeout is expected to work in this case as well but when i tried
statement_timeout, it is not working as expected.
Below is test case to reproduce the issue: [I am
Thanks (once again!) for the valuable suggestions Robert.
The idea of chunking/buffering via cursors has been raised before for
another purpose - allowing multiple queries "concurrently" at the API level
(where concurrently means interleaving when reading the resultsets). This
would imply exposing
On Mon, Aug 10, 2015 at 5:25 AM, Shay Rojansky wrote:
> Thanks for the explanation Robert, that makes total sense. However, it seems
> like the utility of PG's statement_timeout is much more limited than I
> thought.
>
> In case you're interested, I dug a little further and it seems that
> Microso
Thanks for the explanation Robert, that makes total sense. However, it
seems like the utility of PG's statement_timeout is much more limited than
I thought.
In case you're interested, I dug a little further and it seems that
Microsoft's client for SQL Server implements the following timeout (sourc
On Sat, Aug 8, 2015 at 11:30 AM, Shay Rojansky wrote:
> the entire row in memory (imagine rows with megabyte-sized columns). This
> makes sense to me; Tom, doesn't the libpq behavior you describe of absorbing
> the result set as fast as possible mean that a lot of memory is wasted on
> the client
I'd also recommend adding a sentence about this aspect of statement_timeout
in the docs to prevent confusion...
On Sat, Aug 8, 2015 at 5:30 PM, Shay Rojansky wrote:
> Thanks for your responses.
>
> I'm not using cursors or anything fancy. The expected behavior (as far as
> I can tell) for a .NET
Thanks for your responses.
I'm not using cursors or anything fancy. The expected behavior (as far as I
can tell) for a .NET database driver is to read one row at a time from the
database and make it available. There's even a standard API option for
fetching data on a column-by-column basis: this a
Shay Rojansky writes:
> Hi everyone, I'm seeing some strange behavior and wanted to confirm it.
> When executing a query that selects a long result set, if the code
> processing the results takes its time (i.e.g more than statement_timeout),
> a timeout occurs. My expectation was that statement_ti
On Sat, Aug 8, 2015 at 5:31 AM, Shay Rojansky wrote:
> Hi everyone, I'm seeing some strange behavior and wanted to confirm it.
>
> When executing a query that selects a long result set, if the code
> processing the results takes its time (i.e.g more than statement_timeout), a
> timeout occurs. My
Hi everyone, I'm seeing some strange behavior and wanted to confirm it.
When executing a query that selects a long result set, if the code
processing the results takes its time (i.e.g more than statement_timeout),
a timeout occurs. My expectation was that statement_timeout only affects
query *proc
On Tuesday 20 February 2007 12:50, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > pagila=# create or replace function test() returns bool as $$ begin set
> > statement_timeout = 3000; perform pg_sleep(4) ; return true; end $$
> > language plpgsql;
> > CREATE FUNCTION
>
> statement_t
Robert Treat <[EMAIL PROTECTED]> writes:
> pagila=# create or replace function test() returns bool as $$ begin set
> statement_timeout = 3000; perform pg_sleep(4) ; return true; end $$ language
> plpgsql;
> CREATE FUNCTION
statement_timeout is measured across an entire interactive command, not
i
pagila=# select version();
version
-
PostgreSQL 8.2.3 on i386-pc-solaris2.10, compiled by cc -Xa
(1 row)
pagila=# create or replace function test() returns bool as $$ begin set
statement_timeout = 3000; perfor
Simon Riggs wrote:
> On Mon, 2005-09-19 at 13:21 -0400, Bruce Momjian wrote:
>
> > OK. I tested it and it actually works
>
> Gosh, that says a lot about my code quality. I will strive to improve
> from "actually works" to "works as expected" for future patches.
>
> > and I added documentation
>
On Mon, 2005-09-19 at 13:21 -0400, Bruce Momjian wrote:
> OK. I tested it and it actually works
Gosh, that says a lot about my code quality. I will strive to improve
from "actually works" to "works as expected" for future patches.
> and I added documentation
> suggesting its usage.
> !
Simon Riggs wrote:
> On Fri, 2005-09-16 at 20:48 -0400, Bruce Momjian wrote:
> > We can go three ways. We can add a boolean GUC to control printing of
> > the query during a timeout, but that seems like overkill. We can add a
> > new level for log_min_error_statement that is just above error, but
On Fri, 2005-09-16 at 20:48 -0400, Bruce Momjian wrote:
> We can go three ways. We can add a boolean GUC to control printing of
> the query during a timeout, but that seems like overkill. We can add a
> new level for log_min_error_statement that is just above error, but that
> seems confusing. I
Simon Riggs wrote:
> >Alvaro Herrera
> > On Fri, Sep 16, 2005 at 03:41:11PM -0400, Bruce Momjian wrote:
> > > > I have updated the message to:
> > > >
> > > > errmsg("canceling query due to user request or
> > statement timeout")));
> > >
> > > Oops. Did we freeze the message strings already
Simon Riggs wrote:
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > I don't see why printing the query cancel from a timeout is any more
> > special than a user request for cancel or a simple query error. If
> > users want statements to be printed on error, they will
> > configure things
> >
>Alvaro Herrera
> On Fri, Sep 16, 2005 at 03:41:11PM -0400, Bruce Momjian wrote:
> > > I have updated the message to:
> > >
> > > errmsg("canceling query due to user request or
> statement timeout")));
> >
> > Oops. Did we freeze the message strings already for this release?
>
> Not yet.
>
>
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> I don't see why printing the query cancel from a timeout is any more
> special than a user request for cancel or a simple query error. If
> users want statements to be printed on error, they will
> configure things
> that way, if not, we should not
On Fri, Sep 16, 2005 at 03:41:11PM -0400, Bruce Momjian wrote:
> pgman wrote:
> > I have updated the message to:
> >
> > errmsg("canceling query due to user request or statement timeout")));
>
> Oops. Did we freeze the message strings already for this release?
Not yet.
I'm not sure I agr
pgman wrote:
> Simon Riggs wrote:
> > Currently, when we set a statement_timeout and a query runs over that
> > time there is no log message to say that the statement has timed out. We
> > do get a message which says
> > ERROR: canceling query due to user request
> > and so in the server log
Simon Riggs wrote:
> Currently, when we set a statement_timeout and a query runs over that
> time there is no log message to say that the statement has timed out. We
> do get a message which says
> ERROR: canceling query due to user request
> and so in the server log it is impossible to tel
Currently, when we set a statement_timeout and a query runs over that
time there is no log message to say that the statement has timed out. We
do get a message which says
ERROR: canceling query due to user request
and so in the server log it is impossible to tell the difference between
a
In my original statement_timeout code, if a query string had multiple
statements, I would time the statements individually. I have modified
it so it now times the entire string collectively.
Do people realize that if you pass a single string to the backend, it
makes the string into a single tran
63 matches
Mail list logo
