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 issue. and vacuumdb. This is
all on 8.1.4 .

Yeah, system-wide statement_timeout is not much of a brilliant idea

Pozdrawiam
Marcin Mañk


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

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 AM, Marcin Mańk wrote:

> 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 issue. and vacuumdb.
> This is
> all on 8.1.4 .
>
> Yeah, system-wide statement_timeout is not much of a brilliant idea
>
> Pozdrawiam
> Marcin Mańk
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org/


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

Marcin Mañk <marcin.mank@gmail.com> 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).
>
> Ups... Now I checked that pg_dump has the same issue. and vacuumdb. This is
> all on 8.1.4 .
>
> Yeah, system-wide statement_timeout is not much of a brilliant idea

Ok so why don't you exempt user postgres and/or any other roles known
to run lengthy jobs?

alter role postgres set statement_timeout to 0;


> Pozdrawiam
> Marcin Mañk
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org/
>

--
-------------------------------------------------------------------------------
Jerry Sievers 305 854-3001 (home) Production Database Administrator
305 321-1144 (mobil WWW E-Commerce Consultant

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

=?iso-8859-2?Q?Marcin_Ma=F1k?= <marcin.mank@gmail.com> 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 for autovac to ignore statement_timeout? (Maybe it is,
but I suspect we'd get complaints about that too.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

> 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" solves my immediate problem (I did not
know about it, thanks guys). Maybe a comment in postgresql.conf, or docs:

# note: statement_timeout applies to autovacuum, pg_dump, vacuumdb etc.
# If you set it globally, consider "alter role postgres set
statement_timeout=0"


Greetings
Marcin Mañk


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly