Re: Perl DBD and an alarming problem

Поиск
Список
Период
Сортировка
От Michael Fuhr
Тема Re: Perl DBD and an alarming problem
Дата
Msg-id 20051118034631.GA70159@winnie.fuhr.org
обсуждение исходный текст
Ответ на Re: Performance PG 8.0 on dual opteron / 4GB / 3ware  ("Luke Lonergan" <llonergan@greenplum.com>)
Ответы Storage/Performance and splitting a table  ("Craig A. James" <cjames@modgraph-usa.com>)
Re: Perl DBD and an alarming problem  ("Craig A. James" <cjames@modgraph-usa.com>)
Список pgsql-performance
[Please copy the mailing list on replies.]

On Thu, Nov 17, 2005 at 05:38:13PM -0800, Craig A. James wrote:
> >You probably shouldn't set statement_timeout on a global basis
> >anyway
>
> The server is a "one trick pony" so setting a global timeout value is
> actually appropriate.

Beware that statement_timeout also applies to maintenance commands
like VACUUM; it might be more appropriate to set per-user timeouts
with ALTER USER.  If you do set a global timeout then you might
want to set a per-user timeout of 0 for database superusers so
maintenance activities don't get timed out.

> >... but did you reload the server after you made the change?
> >Setting statement_timeout in postgresql.conf and then reloading the
> >server works here in 8.0.4.
>
> Yes.  By "reload" I assume you mean restarting it from scratch.

Either a restart or a "pg_ctl reload", which sends a SIGHUP to the
server.  You can effect some changes by sending a signal to a running
server without having to restart it entirely.

> In this case, I use
>
>    /etc/init.d/postgresql restart
>
> It definitely had no effect at all.  I tried values clear down to 1
> millisecond, but the server never timed out for any query.

Did you use "SHOW statement_timeout" to see if the value was set
to what you wanted?  Are you sure you edited the right file?  As a
database superuser execute "SHOW config_file" to see what file the
server is using.  What exactly did the line look like after you
changed it?

--
Michael Fuhr

В списке pgsql-performance по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Hardware/OS recommendations for large databases (
Следующее
От: "Luke Lonergan"
Дата:
Сообщение: Re: Hardware/OS recommendations for large databases (