Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 16034F765A for ; Wed, 11 Apr 2012 20:03:35 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SI6ZY-0001Mv-1u for pgsql-admin@postgresql.org; Wed, 11 Apr 2012 23:03:34 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id q3BN3HW9012917; Wed, 11 Apr 2012 19:03:17 -0400 (EDT) To: Wells Oliver cc: pgsql-admin@postgresql.org Subject: Re: Definitive logrotate solution? In-reply-to: References: Comments: In-reply-to Wells Oliver message dated "Wed, 11 Apr 2012 15:20:34 -0700" Date: Wed, 11 Apr 2012 19:03:17 -0400 Message-ID: <12916.1334185397@sss.pgh.pa.us> From: Tom Lane X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201204/62 X-Sequence-Number: 39398 Wells Oliver writes: > Might anyone share theirs? My log_rotation is set to 'stderr', and the log > files are being put into /var/log/postgresql. > My main concern is the postrotate action-- want to make sure the log is > properly rotated, unneeded older logs removed, and postgres... properly > bounced? Use the logging collector with its built-in rotation parameters, and you don't need anything else. If you insist on an external solution, there's basically no way except to shut down and restart postgres after any rotation, because there are going to be N processes all connected to the same stderr file descriptor. regards, tom lane