From: | nick(dot)bales(at)rackspace(dot)com |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | BUG #13962: transaction logs growing on standby |
Date: | 2016-02-15 22:29:48 |
Message-ID: | 20160215222948.2605.39385@wrigleys.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 13962
Logged by: Nick Bales
Email address: nick(dot)bales(at)rackspace(dot)com
PostgreSQL version: 9.3.9
Operating system: CentOS 6.6
Description:
On several of my postgres 9.3.x clusters with streaming replication, the
number of transaction logs(files in pg_xlog, not the archived logs) on the
standby nodes are growing past the theoretical maximum(wal_keep_segments + 2
* checkpoint_segments + 1). Most are appropriately getting recycled at each
restartpoint, as can be seed with the log entry like:
restartpoint complete: wrote 128 buffers (0.0%); 0 transaction log file(s)
added, 0 removed, 1 recycled
However, at semi-regular intervals, no xlogs are added, removed, or
recycled:
restartpoint complete: wrote 135 buffers (0.0%); 0 transaction log file(s)
added, 0 removed, 0 recycled
The number of orphaned files for a period directly matches the number of log
occurrences where no files are recycled during a restartpoint. There is
also no log that a new transaction log file is added, even though the number
of xlogs in the directory is growing. Furthermore, once a file is orphaned,
it sticks around for the life of the system, ultimately leading to
exhausting all disk space on long running systems.
Relevant settings:
wal_level = hot_standby
wal_keep_segments = 200
checkpoint_segments = 128
checkpoint_timeout = 5min
checkpoint_completion_target = 0.7
checkpoint_warning = 30s
log_checkpoints = on
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-02-16 04:15:58 | Re: [BUGS] BUG #13956: ODBC driver has a memory leak with TIMESTAMP(0) |
Previous Message | Pravin Carvalho | 2016-02-15 19:23:13 | Re: BUG #13961: Unexpected behaviour of JSONB_SET if the new_value is null |