On Mon, Jul 21, 2014 at 11:32 AM, Sergey Konoplev gray...@gmail.com wrote:
On Mon, Jul 21, 2014 at 10:16 AM, David G Johnston
david.g.johns...@gmail.com wrote:
So, If I separate the commands everything will will work as expected,
correct?
I would assume so.
If you wait to send the
On Fri, Jul 18, 2014 at 6:15 PM, David G Johnston
david.g.johns...@gmail.com 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
Sergey Konoplev-2 wrote
On Fri, Jul 18, 2014 at 6:15 PM, David G Johnston
lt;
david.g.johnston@
gt; 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
On Mon, Jul 21, 2014 at 10:16 AM, David G Johnston
david.g.johns...@gmail.com 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
No hope here?
On Tue, Jul 15, 2014 at 9:49 PM, Sergey Konoplev gray...@gmail.com 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
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 function call
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
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
Hardwick, Joe joe.hardw...@fnis.com 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
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
Hello. Is it possible to set a statement_timeout by host, such that
requests from only that host will be limited?
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
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_timeout
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
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
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).
=?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 idea
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
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 `SET
19 matches
Mail list logo
