On Mon, Jul 21, 2014 at 11:32 AM, Sergey Konoplev wrote:
> On Mon, Jul 21, 2014 at 10:16 AM, David G Johnston
> wrote:
>>> 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
On Mon, Jul 21, 2014 at 10:16 AM, David G Johnston
wrote:
>> 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
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 se
On Fri, Jul 18, 2014 at 6:15 PM, 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
Sergey Konoplev-2 wrote
> Hi,
>
> PostgreSQL 9.2.7, Linux 2.6.32
>
> Several days ago I found one of my servers out of connections,
> pg_stat_activity showed that everything was waiting for the DROP/ALTER
> INDEX transaction (see the record 2 below), that, as I guess, was
> waiting for the functi
No hope here?
On Tue, Jul 15, 2014 at 9:49 PM, Sergey Konoplev wrote:
> Hi,
>
> PostgreSQL 9.2.7, Linux 2.6.32
>
> Several days ago I found one of my servers out of connections,
> pg_stat_activity showed that everything was waiting for the DROP/ALTER
> INDEX transaction (see the record 2 below),
Hi,
PostgreSQL 9.2.7, Linux 2.6.32
Several days ago I found one of my servers out of connections,
pg_stat_activity showed that everything was waiting for the DROP/ALTER
INDEX transaction (see the record 2 below), that, as I guess, was
waiting for the function call (record 1).
-[ RECORD 1 ]
"Hardwick, Joe" writes:
> I have a problem with fetching from cursors sometimes taking an
> extremely long time to run. I am attempting to use the
> statement_timeout parameter to limit the runtime on these.
> PostgreSQL 8.2.4
> Linux 2.6.22.14-72.fc6 #1 SMP Wed Nov 21 13:44:07 EST 2007 i686 i68
Somehow my previous message got grouped into the Amazon EC2 thread..
I have a problem with fetching from cursors sometimes taking an
extremely long time to run. I am attempting to use the
statement_timeout parameter to limit the runtime on these.
PostgreSQL 8.2.4
Linux 2.6.22.14-72.fc6 #1 SMP W
That's definitely an option, and that's what I had slated to use as my
backup plan. But I wanted to make sure there wasn't the ability to do it by
host before I went down that path, as it would be a somewhat cleaner fit in
our setup.
Thanks!
Dave
On Tue, Oct 21, 2008 at 1:57 PM, Jeff Davis <[EMA
On Mon, 2008-10-20 at 17:22 -0700, Dave Fry wrote:
> Hello. Is it possible to set a statement_timeout by host, such that
> requests from only that host will be limited?
>
Can you set it by user instead, and have different hosts connect using
different users?
ALTER USER foo SET statement_timeou
Hello. Is it possible to set a statement_timeout by host, such that
requests from only that host will be limited?
> If you have it set to less than the time needed to do a vacuum, then
> yes, autovac will fail. You expected differently? Do you think it's
> a good idea for autovac to ignore statement_timeout? (Maybe it is,
> but I suspect we'd get complaints about that too.)
>
"alter role set statement_time
=?iso-8859-2?Q?Marcin_Ma=F1k?= <[EMAIL PROTECTED]> writes:
> I have an unconfirmed feeling that autovac does not like system-wide
> statement_timeout.
If you have it set to less than the time needed to do a vacuum, then
yes, autovac will fail. You expected differently? Do you think it's
a good i
Marcin Mañk <[EMAIL PROTECTED]> writes:
> Hello.
> I have an unconfirmed feeling that autovac does not like system-wide
> statement_timeout. I.e. when I in some panic move set system-wide
> statement_timeout to 90 seconds, autovac stopped working (I do not know for
> 100% if there is a dependency)
When I configure statement_timeout globally, I typically override it
for superusers and other accounts used by dbas. Just issue:
ALTER USER postgres SET statement_timeout = 0;
Repeat for other superusers (slony, etc). Then the policy won't apply
to them.
-Casey
On Nov 16, 2006, at 6:46
Hello.
I have an unconfirmed feeling that autovac does not like system-wide
statement_timeout. I.e. when I in some panic move set system-wide
statement_timeout to 90 seconds, autovac stopped working (I do not know for
100% if there is a dependency).
Ups... Now I checked that pg_dump has the same i
Ivan Zolotukhin wrote:
> Hello,
>
> I've recently set up statement_timeout setting in postgresql.conf to
> terminate long running queries from web clients. When I run long
> maintance queries (that should not be terminated) like VACUUM FULL in
> psql client, I can specify per session setting like
Hello,
I've recently set up statement_timeout setting in postgresql.conf to
terminate long running queries from web clients. When I run long
maintance queries (that should not be terminated) like VACUUM FULL in
psql client, I can specify per session setting like `SET
statement_timeout TO 0` not t
19 matches
Mail list logo
