On Tue, Jul 6, 2010 at 11:03 AM, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> 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.
>
> I normally don't backpatch anything unless it is either a possible cause
> of data loss, or a problem that is reported by multiple people.
>
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company