Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1egbCk-0001A5-VI for pgsql-admin@arkaria.postgresql.org; Tue, 30 Jan 2018 19:04:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1egbCi-00066n-Pl for pgsql-admin@arkaria.postgresql.org; Tue, 30 Jan 2018 19:04:24 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1egbCi-00066e-BL for pgsql-admin@lists.postgresql.org; Tue, 30 Jan 2018 19:04:24 +0000 Received: from mail-ot0-x22b.google.com ([2607:f8b0:4003:c0f::22b]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1egbCf-0004cU-LR for pgsql-admin@lists.postgresql.org; Tue, 30 Jan 2018 19:04:23 +0000 Received: by mail-ot0-x22b.google.com with SMTP id v5so10985885oth.5 for ; Tue, 30 Jan 2018 11:04:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgsqlrocket-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=ZQZ57zRsGMkxJHkDSuJlG98PZ6ubvw03PfaeydlLRBg=; b=o2cCkBcZo6cHMB1i8BYPnWGMQOoXlcn69Y05FryLuRiRIojl9FuwH+8UpBzres5XM/ iyQNC9HqiVb8YB+5dQgHQ1BUY42EjcULtgVHg8TTdIvzgVWNgSEXl3MT9IZj5RvXMXbX 5rK01q0K/FqK20DYnmTWFljtdRaVxX+Ms2jA1WPPkaC7SAxiKbSNi/vIdFEx73KjvC2c ldwkOsKt2BcUT9T8j8+LQv6qQ37eZGuxieZs+nfBv1Oh5W77v+xtEpzUexiRQYGTXC0C lmf9qZicqRcOYZE4buoYFPsz22Ps9X1Z9sMop10L3HBGENTXpNMf0WUkbxYtRCOTRf7E fBzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=ZQZ57zRsGMkxJHkDSuJlG98PZ6ubvw03PfaeydlLRBg=; b=GP6wC1AlC6yWWzMTw39l0qzEyb7Vb1h43PX87WoCUr05d3EmylZPSREw+Yw2IiimfD ZAjyPuAOB/Fw1s52WbXvgeP7tGlxxVKKosW9wgUfGUhh0eWTAQa4G+y609SMhIWpT+Nx UAZJqXWuh1h6+C6oEbhjdHF3SF7M0Qa97LuFGlD6Y5quaPI9/+oBLAu2yp1JvORoEC4N lcp9fGmsXB8sMyud6nOX2Cp3gqXIxJpSudUiV5SoOQbGESl5ARpWcPpjmr+PvYdoxC7z jN3nA9P68JGVaV9g/7HA91zC+mquFMD2gZCnZP/2ttcqVzSnKacArgMkwVWq6eWtCFbu 9ldw== X-Gm-Message-State: AKwxyteBn4QQBpsgG49j+35XDrA6aIta0sIr5TfUYLO5/fVAxLzQ+kIN S3sXOM1jsZUCdtgqpi/hYO1QN0E3r7A= X-Google-Smtp-Source: AH8x225aTGbP0yNPkBeyduQlyiBHfjYPBB768SWwZqd1X8jf0FhfuMAamg7rPfP0han97KO65BcgPg== X-Received: by 10.157.25.137 with SMTP id k9mr22562113otk.291.1517339059566; Tue, 30 Jan 2018 11:04:19 -0800 (PST) Received: from localhost.localdomain ([65.132.155.214]) by smtp.gmail.com with ESMTPSA id r7sm8495743otr.24.2018.01.30.11.04.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 11:04:18 -0800 (PST) To: pgsql-admin@lists.postgresql.org From: chris Subject: pg_xlog piling Message-ID: <575c1026-aabd-4854-55f7-1292c57b3da6@pgsqlrocket.com> Date: Tue, 30 Jan 2018 12:04:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, I have a standby that is in replication only mode but the pg_xlog directory is currently at 577GB utilized and is growing daily and I can't figure out why. This was a problem before when we were on postgresl 9.2 but changed some postgresql.conf parameters and then rebuilt it but still running into the same problem. Thanks in advance, Chris Here is some more info about the standby. # WRITE AHEAD LOG #------------------------------------------------------------------------------ # - Settings - wal_level = hot_standby            # minimal, archive, or hot_standby                     # (change requires restart) #fsync = off                # turns forced synchronization on or off #synchronous_commit = off        # synchronization level;                     # off, local, remote_write, or on #wal_sync_method = fsync        # the default is the first option                     # supported by the operating system:                     #   open_datasync                     #   fdatasync (default on Linux)                     #   fsync                     #   fsync_writethrough                     #   open_sync #full_page_writes = on            # recover from partial page writes #wal_buffers = -1            # min 32kB, -1 sets based on shared_buffers                     # (change requires restart) #wal_writer_delay = 200ms        # 1-10000 milliseconds #commit_delay = 0            # range 0-100000, in microseconds #commit_siblings = 5            # range 1-1000 # - Checkpoints - checkpoint_segments = 128        # in logfile segments, min 1, 16MB each checkpoint_timeout = 30min #checkpoint_timeout = 5min        # range 30s-1h #checkpoint_completion_target = 0.5    # checkpoint target duration, 0.0 - 1.0 checkpoint_warning = 30min #checkpoint_warning = 30s        # 0 disables # REPLICATION #------------------------------------------------------------------------------ # - Sending Server(s) - # Set these on the master and on any standby that will send replication data. max_wal_senders = 3        # max number of walsender processes                 # (change requires restart) wal_keep_segments = 256        # in logfile segments, 16MB each; 0 disables #wal_keep_segments = 500        # in logfile segments, 16MB each; 0 disables #replication_timeout = 60s    # in milliseconds; 0 disables # - Master Server - # These settings are ignored on a standby server. #synchronous_standby_names = ''    # standby servers that provide sync rep                 # comma-separated list of application_name                 # from standby(s); '*' = all #vacuum_defer_cleanup_age = 0    # number of xacts by which cleanup is delayed # - Standby Servers - # These settings are ignored on a master server. hot_standby = on            # "on" allows queries during recovery                     # (change requires restart) #max_standby_archive_delay = 30s    # max delay before canceling queries                     # when reading WAL from archive;                     # -1 allows indefinite delay #max_standby_streaming_delay = 30s    # max delay before canceling queries                     # when reading streaming WAL;                     # -1 allows indefinite delay #wal_receiver_status_interval = 10s    # send replies at least this often                     # 0 disables #hot_standby_feedback = off        # send info from standby to prevent                     # query conflicts postgres=# show checkpoint_segments;  checkpoint_segments ---------------------  128 (1 row) postgres=# show wal_keep_segments;  wal_keep_segments -------------------  256 (1 row)