Re: Perl DBD and an alarming problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux