Hi Hmm... a possible bug eh! I'll make sure that the log destination doesn't fill again This is what I have in the postgresql.conf file: log_destination = 'stderr' redirect_stderr = true log_directory = '/opt/postgres/admin/log' log_filename = 'PG-%Y-%m-%d_%H%M%S.log' Thanks, Nigel -----Original Message----- From: pgsql-admin-owner@xxxxxxxxxxxxxx [mailto:pgsql-admin-owner@xxxxxxxxxxxxxx] On Behalf Of Tom Lane Sent: 13 October 2005 17:12 To: Nigel Bishop Cc: pgsql-admin@xxxxxxxxxxxxxx Subject: Re: DB Cluster hanging Nigel Bishop <nigel.bishop@xxxxxxxxx> writes: > 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. How was the logging being done exactly? syslog? redirect_stderr? If redirect_stderr, this could well be a PG bug --- I kinda doubt anyone has tested that scenario. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend Communications on or through ioko's computer systems may be monitored or recorded to secure effective system operation and for other lawful purposes. Unless otherwise agreed expressly in writing, this communication is to be treated as confidential and the information in it may not be used or disclosed except for the purpose for which it has been sent. If you have reason to believe that you are not the intended recipient of this communication, please contact the sender immediately. No employee is authorised to conclude any binding agreement on behalf of ioko with another party by e-mail without prior express written confirmation. ioko365 Ltd. VAT reg 656 2443 31. Reg no 3048367. All rights reserved. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
