pgsql: Fix log_temp_files docs and comments to say bytes not kilobytes.
in [PgSql]
|
Prev: Bug? Concurrent COMMENT ON and DROP object
Next: pgsql: Fix log_temp_files docs and comments to say bytes not kilobytes.
From: Robert Haas on 6 Jul 2010 10:21 On Fri, Jun 25, 2010 at 1:56 PM, Josh Berkus <josh(a)agliodbs.com> wrote: > >>> Shouldn't this be backpatched, or was this a new bug in 9.0? > > We've always output bytes. I'd have noticed the discrepancy myself if I'd > read the actual docs ;-) > > KB would be more useful. And I don't think people have enough scripts built > on this yet to make this break anything. We should backport to 8.4. log_temp_files was introduced in 8.3, so we'll need to backpatch this to 8.3, not just 8.4. Greg Smith tells me Simon has been busy with other things, so I'm going to pick this up. Barring objections, I'm going to revert Simon's patch and change the behavior instead, per the attached patch. I will also back-patch the fix to 8.4 and 8.3. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
From: Tom Lane on 6 Jul 2010 10:42 Robert Haas <robertmhaas(a)gmail.com> writes: > log_temp_files was introduced in 8.3, so we'll need to backpatch this > to 8.3, not just 8.4. Greg Smith tells me Simon has been busy with > other things, so I'm going to pick this up. Barring objections, I'm > going to revert Simon's patch and change the behavior instead, per the > attached patch. I will also back-patch the fix to 8.4 and 8.3. I agree with doing this for 9.0, but I'm much less sold that it's a good idea to change the meaning of the parameter in minor releases of 8.4 and 8.3. Aren't you risking breaking installations that work now? 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: Robert Haas on 6 Jul 2010 10:52 On Tue, Jul 6, 2010 at 10:42 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> log_temp_files was introduced in 8.3, so we'll need to backpatch this >> to 8.3, not just 8.4. �Greg Smith tells me Simon has been busy with >> other things, so I'm going to pick this up. �Barring objections, I'm >> going to revert Simon's patch and change the behavior instead, per the >> attached patch. �I will also back-patch the fix to 8.4 and 8.3. > > I agree with doing this for 9.0, but I'm much less sold that it's a good > idea to change the meaning of the parameter in minor releases of 8.4 and > 8.3. �Aren't you risking breaking installations that work now? I think my least favorite option is changing the behavior only in HEAD. I think the reasonable options are: 1. Change the behavior in HEAD, 8.4, and 8.3, per previous discussion. If we do this, we should do what I proposed in my previous email. 2. Change the comments and documentation in 8.4 and 8.3 along the lines that Simon already did in HEAD. If we do this, we also need to change the GUC units to something other than GUC_UNIT_KB, as noted upthread. I'm not sure what would be appropriate. The reason I think it's OK to change the behavior in the back-branches is that (a) the only thing it affects is logging, so it shouldn't really "break" anything, and (b) apparently nobody has noticed that the interpretation of the GUC is off by three orders of magnitude, so either nobody's using it or they're not looking at what's actually happening too carefully. But I'm OK with going the other way and changing the code and docs in the back-branches, too. I just think we should be consistent. -- 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: Tom Lane on 6 Jul 2010 11:10 Robert Haas <robertmhaas(a)gmail.com> writes: > On Tue, Jul 6, 2010 at 11:03 AM, Bruce Momjian <bruce(a)momjian.us> wrote: >> Anything backpatched risks causing instability, and might discourage >> people from performing minor upgrades. �Minor fixes are rarely worth the >> risk of causing instability in back-branches. > OK. Well, in that case, I think we should backpatch the changes Simon > already made, and also pick a new unit for the GUC. Changing the unit setting would also be a behavioral change. I think what Bruce is suggesting is that this is simply not worth worrying about in the back branches. 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: Robert Haas on 6 Jul 2010 11:17
On Tue, Jul 6, 2010 at 11:10 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Tue, Jul 6, 2010 at 11:03 AM, Bruce Momjian <bruce(a)momjian.us> wrote: >>> Anything backpatched risks causing instability, and might discourage >>> people from performing minor upgrades. �Minor fixes are rarely worth the >>> risk of causing instability in back-branches. > >> OK. �Well, in that case, I think we should backpatch the changes Simon >> already made, and also pick a new unit for the GUC. > > Changing the unit setting would also be a behavioral change. �I think > what Bruce is suggesting is that this is simply not worth worrying about > in the back branches. It seems pretty strange not to at least document it. And I'm not wild about adding documentation that says "Even though this value purports to be in kilobytes, it's really not", but I guess we can. -- 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 |