From: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: statement_timeout doesn't work |
Date: | 2014-07-21 17:16:19 |
Message-ID: | 1405962979850-5812243.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Sergey Konoplev-2 wrote
> On Fri, Jul 18, 2014 at 6:15 PM, David G Johnston
> <
> david.g.johnston@
> > wrote:
>>> query | BEGIN;
>>> SET LOCAL statement_timeout TO 1000;
>>> DROP INDEX public.idx1;
>>> ALTER INDEX public.idx2 RENAME TO idx1;
>>> END;
>>
>> If I read this correctly you sent the entire begin...end as a single
>> compound statement and so, depending on how you did this, the actual SET
>> LOCAL command never got executed since the entire command is waiting for
>> the
>> necessary locks before it can be executed.
>
> Right, I send it as a single command.
>
>> Your sample test doesn't appear to correctly exercise this behavior. Are
>> you maybe using -c in the problem case? Or a client library besides psql
>> that would behave in this manner?
>
> In this case I use DBD::Pg, but I haven't found any notes about such
> kind of behavior.
>
>> Note that the fact that "query" is a compound statement is why I claim
>> the
>> above...
>
> So, If I separate the commands everything will will work as expected,
> correct?
I would assume so.
If you wait to send the DROP/ALTER index commands until the SET LOCAL
command returns successfully then both of those commands will die if they
exceed the timeout specified.
Dave
--
View this message in context: http://postgresql.1045698.n5.nabble.com/statement-timeout-doesn-t-work-tp5811704p5812243.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | David G Johnston | 2014-07-21 17:28:39 | Re: cursor return null |
Previous Message | Tom Lane | 2014-07-21 16:16:43 | Re: postgres_fdw - push down conditionals for ENUMs |