Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gp2sp-0002ci-A3 for pgsql-admin@arkaria.postgresql.org; Thu, 31 Jan 2019 03:19:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gp2sn-0001xV-OL for pgsql-admin@arkaria.postgresql.org; Thu, 31 Jan 2019 03:19:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gp2sn-0001x6-F3 for pgsql-admin@lists.postgresql.org; Thu, 31 Jan 2019 03:19:17 +0000 Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gp2sl-0000iN-9G for pgsql-admin@lists.postgresql.org; Thu, 31 Jan 2019 03:19:17 +0000 Received: by mail-ot1-x32d.google.com with SMTP id 32so1560981ota.12 for ; Wed, 30 Jan 2019 19:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=5qYL3HmPUk2dzh6c80px5eoQsfgPF1P77p+kALD+UNk=; b=ccyWsP2urscMA4tz/pCCVbPXmS8mAZqk0+r30WWi+RTA8qsKI80zRyT7d5RyU879Vm GPG470M5gOMBPll/hzJatJKq7XQ06RR11DgnwodgDbUwfa7YZUtlmieryltwqx4dIkeU KkoWaQRLOUcsKI+uXyMXdhH/g4b/jhpoNJ3wXFwUeWJKChCQK77KU5OQHTZcmcaPJ1vc MtiXgHg8WzoZtT3iWuFeCzIM+1Sq//YpJ3iUp+PxC8wdR35rVLUcCkPx5c4RvKJnTGnw cJt4D0+/n6JP4b6FyuZ4jkpp5N4WWK8oUDgvE4RZBNszjbT7rOy7zhUeDJ4RnY2Rf0Rg 1UhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=5qYL3HmPUk2dzh6c80px5eoQsfgPF1P77p+kALD+UNk=; b=LIBZnwFDHpyDFDfOpSXLAHuTnpZ/Hyq4J1Rpo8pjyKPRRhbxisA7At3yiiF9QhHJOa c+pZUWDroBj94gS+wEVb96UMgF+OPj7vqbWzJdvwwUsNgweqB5aiptqPvVNS+CoZ90pN aZebgJWSXg4AAbgfJWIchevBElDx5yFiERv1S6E01Dbhih3mKBbqE8A34GK+oq/gyhcB 4wbJxFa9l9/ixaVHsCgFMilfAYymRqz6mzZFcm45DgZz3W6nIooDUeWh+QawSFF6v2NR d5EY963cSjhg0g6yZKmXB+Xsw2ZAal834nccaIgXwc2qbFOL5TXTtHV2odBtmwdPT5Eo Oh9w== X-Gm-Message-State: AJcUukd5NeyuR3odQ6nX/0thwxC1UkIHer1HDPb51T4OIoCkceie6BtO oLd9d8fXcepUcDUOnX24V6UpN5c/ X-Google-Smtp-Source: ALg8bN6Df8egKnXbsJ9H3AiyF6F0UI0ke/kdtx2ZiHfNQ/LwOBtJMRJw7pBQXr+eQ2R6RtIzf0p0rA== X-Received: by 2002:a9d:5617:: with SMTP id e23mr22788252oti.151.1548904752671; Wed, 30 Jan 2019 19:19:12 -0800 (PST) Received: from [192.168.1.10] (ip70-171-116-89.no.no.cox.net. [70.171.116.89]) by smtp.googlemail.com with ESMTPSA id c19sm1339079otl.16.2019.01.30.19.19.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jan 2019 19:19:11 -0800 (PST) Subject: Re: Old WAL files under pg_xlog not getting delete To: Pgsql-admin References: <201901310000.fkapsf6clz5s@alvherre.pgsql> From: Ron Message-ID: Date: Wed, 30 Jan 2019 21:19:11 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A4F5CE0472B9CCDCB0F96A81" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------A4F5CE0472B9CCDCB0F96A81 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/30/19 9:09 PM, rammohan ganapavarapu wrote: > Thank you all, but irrespective of count i have why is it keeping old files? Because you're telling it to!! max_wal_size= 1GB wal_keep_segments=500 > and how is it using those files? Is there any processes that can flush or > remove those files? Change the parameter and restart the server... > > On Wed, Jan 30, 2019, 4:11 PM David G. Johnston > wrote: > > On Wed, Jan 30, 2019 at 5:00 PM Alvaro Herrera > > wrote: > > Hmm ... I would recommend to keep the xlog files in a subdir, not the > > root of the filesystem. > > They are in a subdir (under /opt/pgdata), and the OP seems likely to > have omitted the self/parent hidden directories during his check as > well.  Plus per the docs we actually expect 501 so there isn't a need > to account for 6 extra, just 5. > > Dave > -- Angular momentum makes the world go 'round. --------------A4F5CE0472B9CCDCB0F96A81 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 1/30/19 9:09 PM, rammohan ganapavarapu wrote:
Thank you all, but irrespective of count i have why is it keeping old files?

Because you're telling it to!!

max_wal_size= 1GB
wal_keep_segments=500

and how is it using those files? Is there any processes that can flush or remove those files?

Change the parameter and restart the server...


On Wed, Jan 30, 2019, 4:11 PM David G. Johnston <david.g.johnston@gmail.com wrote:
On Wed, Jan 30, 2019 at 5:00 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Hmm ... I would recommend to keep the xlog files in a subdir, not the
> root of the filesystem.

They are in a subdir (under /opt/pgdata), and the OP seems likely to
have omitted the self/parent hidden directories during his check as
well.  Plus per the docs we actually expect 501 so there isn't a need
to account for 6 extra, just 5.

Dave


--
Angular momentum makes the world go 'round.
--------------A4F5CE0472B9CCDCB0F96A81--