Re: DB Cluster hanging
От | codeWarrior |
---|---|
Тема | Re: DB Cluster hanging |
Дата | |
Msg-id | dilvje$13nr$1@news.hub.org обсуждение исходный текст |
Ответ на | DB Cluster hanging (Nigel Bishop <nigel.bishop@gmail.com>) |
Ответы |
Re: DB Cluster hanging
|
Список | pgsql-admin |
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 >
В списке pgsql-admin по дате отправления: