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@xxxxxxxxx> wrote in message news:7e974e490510130822q3a853039n4c96991179deae5a@xxxxxxxxxxxxxxxxx > 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
