Allow wal_keep_segments to keep all segments
in [PgSql]
|
Prev: [HACKERS] Allow wal_keep_segments to keep all segments
Next: recovery getting interrupted is not so unusual as it used to be
From: Robert Haas on 2 Jun 2010 15:31 On Wed, Jun 2, 2010 at 3:20 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > Bruce Momjian wrote: >> Robert Haas wrote: >> > On Sat, May 8, 2010 at 10:40 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> > > Bruce Momjian <bruce(a)momjian.us> writes: >> > >> Uh, did we decide that 'wal_keep_segments' was the best name for this >> > >> GUC setting? ?I know we shipped beta1 using that name. >> > > >> > > I thought min_wal_segments was a reasonable proposal, but it wasn't >> > > clear if there was consensus or not. >> > >> > I think most people thought it was another reasonable choice, but I >> > think the consensus position is probably something like "it's about >> > the same" rather than "it's definitely better". We had one or two >> > people with stronger opinions than that on either side, I believe. >> >> Agreed the current name seems OK. However, was there agreement that >> wal_keep_segments = -1 should keep all WAL segements? I can see that as >> useful for cases where you are doing a dump to be transfered to the >> slave, and not using archive_command. This avoids the need for the "set >> a huge value" solution. > > The attached patch allows wal_keep_segments = -1 to keep all segements; > this is particularly useful for taking a base backup, where you need all > the WAL files during startup of the standby. I have documented this > usage in the patch as well. > > I am thinking of applying this after 9.0 beta2 if there is no objection. +1 for the patch, but why wait until after beta2? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 2 Jun 2010 15:36 On Wed, 2010-06-02 at 15:20 -0400, Bruce Momjian wrote: > The attached patch allows wal_keep_segments = -1 to keep all segements; > this is particularly useful for taking a base backup, where you need all > the WAL files during startup of the standby. I have documented this > usage in the patch as well. > > I am thinking of applying this after 9.0 beta2 if there is no objection. It's not clear to me why "keep all files until server breaks" is a good setting. Surely you would set this parameter to the size of your disk. Why allow it to go higher? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 2 Jun 2010 20:28 Simon Riggs wrote: > On Wed, 2010-06-02 at 15:20 -0400, Bruce Momjian wrote: > > > The attached patch allows wal_keep_segments = -1 to keep all segements; > > this is particularly useful for taking a base backup, where you need all > > the WAL files during startup of the standby. I have documented this > > usage in the patch as well. > > > > I am thinking of applying this after 9.0 beta2 if there is no objection. > > It's not clear to me why "keep all files until server breaks" is a good > setting. Surely you would set this parameter to the size of your disk. > Why allow it to go higher? Well, the -1 allows them to set it temporarily without having to compute their free disk space. Frankly, because the disk space varies, it is impossible to know exactly how large the disk is at the time it would fill up. I think the normal computation would be: 1) How long is my file system backup and restore to standby going to take 2) How often do I generate a 16MB WAL file You would do some computation to figure that out, then maybe multiply it by 10x and set that for wal_keep_segments. I figured allowing a simple -1 would be easier. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 2 Jun 2010 20:28 Robert Haas wrote: > > The attached patch allows wal_keep_segments = -1 to keep all segements; > > this is particularly useful for taking a base backup, where you need all > > the WAL files during startup of the standby. ?I have documented this > > usage in the patch as well. > > > > I am thinking of applying this after 9.0 beta2 if there is no objection. > > +1 for the patch, but why wait until after beta2? I wanted to give people enough time to review/discuss it. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 3 Jun 2010 00:35
On Wed, 2010-06-02 at 20:28 -0400, Bruce Momjian wrote: > Simon Riggs wrote: > > On Wed, 2010-06-02 at 15:20 -0400, Bruce Momjian wrote: > > > > > The attached patch allows wal_keep_segments = -1 to keep all segements; > > > this is particularly useful for taking a base backup, where you need all > > > the WAL files during startup of the standby. I have documented this > > > usage in the patch as well. > > > > > > I am thinking of applying this after 9.0 beta2 if there is no objection. > > > > It's not clear to me why "keep all files until server breaks" is a good > > setting. Surely you would set this parameter to the size of your disk. > > Why allow it to go higher? > > Well, the -1 allows them to set it temporarily without having to compute > their free disk space. Frankly, because the disk space varies, it is > impossible to know exactly how large the disk is at the time it would > fill up. > > I think the normal computation would be: > > 1) How long is my file system backup and restore to standby > going to take > 2) How often do I generate a 16MB WAL file > > You would do some computation to figure that out, then maybe multiply it > by 10x and set that for wal_keep_segments. I figured allowing a simple > -1 would be easier. I think its much easier to find out your free disk space than it is to calculate how much WAL might be generated during backup. Disk space doesn't vary significantly on a production database. If we encourage that laziness then we will get reports that replication doesn't work and Postgres crashes. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |