Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YEhT0-0006ae-Hf for pgsql-admin@arkaria.postgresql.org; Fri, 23 Jan 2015 16:52:18 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YEhT0-0007zg-2h for pgsql-admin@arkaria.postgresql.org; Fri, 23 Jan 2015 16:52:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YEhSz-0007za-Ad for pgsql-admin@postgresql.org; Fri, 23 Jan 2015 16:52:17 +0000 Received: from mail-yh0-x230.google.com ([2607:f8b0:4002:c01::230]) by magus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YEhSr-0001Jx-Nw for pgsql-admin@postgresql.org; Fri, 23 Jan 2015 16:52:16 +0000 Received: by mail-yh0-f48.google.com with SMTP id a41so3825520yho.7 for ; Fri, 23 Jan 2015 08:52:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=RJPFpQFb7vDH0Yf4Dy15YG+swyYZZelRg27QjVKJuLs=; b=JD7aJJu+0sMee770RG+0j1LFBhGXyuRoRNo8Pc4ySZhHaWKKPATPNsMkitSxKr0qq/ NrCKrvlNJ3yedsuYMz5Q1pyL0yksg1crIEN9ataDsg/ah75EoZE8vI2bA5OoMDiu3+x9 Lo+b6IZrMR4fuHHpCZjqBDi4JyG8c1bCcKIsh8utPft7YAzTFv2GeQGFuvR3gfgcJa9Q eUJEafYv55R1dLD4iW1CZiQIizzRGUqbuvJmBFYbSegHV7gOA2ghV1k9Np25h0HMGrGY bavr/Rkq2VzUQHvWhtOaNG9BD72zuIEc9mmlSPQTyQjpYybegOjk8/VIhS/M1CHhA9Nl wu2A== X-Received: by 10.170.194.137 with SMTP id l131mr2114955yke.96.1422031926876; Fri, 23 Jan 2015 08:52:06 -0800 (PST) Received: from [192.168.254.3] (h77.89.102.166.static.ip.windstream.net. [166.102.89.77]) by mx.google.com with ESMTPSA id o48sm1142570yhb.56.2015.01.23.08.52.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jan 2015 08:52:06 -0800 (PST) Message-ID: <54C27C34.5040503@gmail.com> Date: Fri, 23 Jan 2015 11:52:04 -0500 From: John Scalia User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jeff Frost CC: "pgsql-admin@postgresql.org" Subject: Re: What to do when pg_xlog directory has filled up the filesystem References: <54C2701F.1020505@gmail.com> <08DE332B-60AE-4B3D-8D82-7EEBDDCCB6CF@pgexperts.com> In-Reply-To: <08DE332B-60AE-4B3D-8D82-7EEBDDCCB6CF@pgexperts.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org On 1/23/2015 11:33 AM, Jeff Frost wrote: >> On Jan 23, 2015, at 08:00, John Scalia wrote: >> >> Hi all, >> >> Just curious about this issue as it has occurred on my 9.4.0 sandbox primary server. The link to the directory specified in archive_command had disappeared, so the command specified in archive_command kept failing overnight. This resulted in many WAL segments piling up in the pg_xlog directory and a bunch of .ready files appearing in the pg_xlog/archive.status directory. The filesystem had reached 100% full so the database quit and would not restart. I've thought about just moving some of the WAL segments temporarily to another filesystem, but which ones, oldest or newest? And is that really the best way to deal with this or what is the best way to deal with this kind of issue? > If you are on ext4, you can just: > > tune2fs -m 0 /dev/sda1 > > Or whatever device you're talking about. > > That will reset the reserved space to 0. > > Then you can start up PostgreSQL and let it do the archiving. After it's done: > > tune2fs -m 5 /dev/sda1 > > To put it back to the default. > Thanks, Jeff! -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin