Re: DB Cluster hanging

If you can't / won't / don't use syslog and want your logs rotated
anyway, look at apache's log rotator.  It works a charm, and rotates
every night at midnight the way I use it.  Quite simple to set up and
very reliable.

On Thu, 2005-10-13 at 10:48, codeWarrior wrote:
> Are you possibly running logrotate on the postgreSQL server logs ? Logrotate
> is usually set to signal (SIGHUP) the log owner (in this case -- postgreSQL)
> after rotating the log file...
>
> You normally can't just delete the logfiles and expect postgreSQL to
> continue wherever you left it... you normally need to pg_ctl reload or
> pg_ctl restart after dinking with the log files...
>
> "Nigel Bishop" <nigel.bishop@gmail.com> wrote in message
> news:7e974e490510130822q3a853039n4c96991179deae5a@mail.gmail.com...
> > Hi,
> >
> > I'm hoping that someone will be able to answer this query:
> >
> > Last night at 3am our Postgresql DB cluster hung.  At the time data
> > was being loaded.  The parameter log_statement_stats in the
> > postgresql.conf file was set to true.  This was churning out data into
> > the logfile which was switching every 10Mb.  Eventually the partition
> > where the logfiles are written to filled up  fair enough  this had
> > been going on since about 5.30pm the previous evening and the logfiles
> > were being generated at the rate of 4/5 a minute.  The partition was
> > cleared of old logs and I expected the DB to spring in to life, but no
> > it just sat there.  I could not connect with psql or pg_ctl to
> > shutdown the cluster.
> >
> > Eventually I had to issue a kill -9 on the postmaster, set
> > log_statement_stats to false and restarted the cluster, It recovered
> > itself and the data load carried on.
> >
> > My question is, is this normal behaviour when the logfile destination
> > fills up?  There was nothing in the logfile being used at the time of
> > the hang, just stats data.
> >
> > PG version 8.0.3 with archived WAL logs enabled
> >
> > O/S version RH ES4 with 2 CPUs & 2Gb RAM
> >
> > Thanks very much for any input.
> >
> >
> > Regards,
> >
> > Nigel Bishop
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>                http://archives.postgresql.org