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: Heikki Linnakangas on 3 Jun 2010 08:31 On 03/06/10 15:15, Bruce Momjian wrote: > Simon Riggs wrote: >> 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. > > Well, we don't clean out the archive directory so I don't see this as > anything new. We leave that up to the DBA to clean out one way or another. We provide restartpoint_command and the %r option in restore_command to help with that. Surely we don't expect DBAs to delete old files in pg_xlog? I agree with Simon here, I think it would be better to not provide -1 as an option here. At least you better document well that you should only do that temporarily or you will eventually run out of disk space. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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 3 Jun 2010 08:36 Heikki Linnakangas wrote: > On 03/06/10 15:15, Bruce Momjian wrote: > > Simon Riggs wrote: > >> 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. > > > > Well, we don't clean out the archive directory so I don't see this as > > anything new. > > We leave that up to the DBA to clean out one way or another. We provide > restartpoint_command and the %r option in restore_command to help with that. > > Surely we don't expect DBAs to delete old files in pg_xlog? I agree with > Simon here, I think it would be better to not provide -1 as an option > here. At least you better document well that you should only do that > temporarily or you will eventually run out of disk space. Using this only temporarily is mentioned in the doc patch. Do I need more? -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
From: Bruce Momjian on 3 Jun 2010 10:10 Heikki Linnakangas wrote: > On 03/06/10 15:15, Bruce Momjian wrote: > > Simon Riggs wrote: > >> 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. > > > > Well, we don't clean out the archive directory so I don't see this as > > anything new. > > We leave that up to the DBA to clean out one way or another. We provide > restartpoint_command and the %r option in restore_command to help with that. > > Surely we don't expect DBAs to delete old files in pg_xlog? I agree with > Simon here, I think it would be better to not provide -1 as an option > here. At least you better document well that you should only do that > temporarily or you will eventually run out of disk space. I have updated the doc text to mention "temporarily" everywhere '-1' is mentioned. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
From: Tom Lane on 3 Jun 2010 10:22 Bruce Momjian <bruce(a)momjian.us> writes: > Heikki Linnakangas wrote: >> Surely we don't expect DBAs to delete old files in pg_xlog? I agree with >> Simon here, I think it would be better to not provide -1 as an option >> here. At least you better document well that you should only do that >> temporarily or you will eventually run out of disk space. > I have updated the doc text to mention "temporarily" everywhere '-1' is > mentioned. FWIW, I've come to agree with Simon. Allowing -1 doesn't do anything that you can't do with a large positive setting, and what it does do is to encourage people to set the variable to an unsafe value as a substitute for thinking. regards, tom lane -- 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 3 Jun 2010 08:15
Simon Riggs wrote: > 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. Well, we don't clean out the archive directory so I don't see this as anything new. -- 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 |