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
>
