2010/7/8 Josh Berkus :
> On 7/6/10 8:06 AM, Tom Lane wrote:
>> It might be that nobody's using any values other than 0 and -1 ...
>> in which case it wouldn't matter anyway. I agree that the lack of
>> bug reports is notable. But still, don't we try to avoid behavioral
>> changes in stable branch
On 7/6/10 8:06 AM, Tom Lane wrote:
> It might be that nobody's using any values other than 0 and -1 ...
> in which case it wouldn't matter anyway. I agree that the lack of
> bug reports is notable. But still, don't we try to avoid behavioral
> changes in stable branches?
I think most people are
On Tue, Jul 6, 2010 at 5:49 PM, Greg Smith wrote:
> I was never arguing in favor of touching anything in the back branches; if
> you recall I didn't even voice an opinion here until I got concerned about
> too many changes happening in them. I think a proper fix in 9.0 combined
> with a release n
Robert Haas wrote:
Bruce felt it wasn't worth putting that amount of work into backbranch docs
that nobody's likely to read
anyway, but I suppose that view could be overruled if there's a strong
consensus.
I was never arguing in favor of touching anything in the back branches;
if you reca
On Tue, Jul 6, 2010 at 3:40 PM, Greg Smith wrote:
> Robert Haas wrote:
>>
>> OK, so I talked to Bruce about this and I guess I've been persuaded
>> that we should just apply the patch I sent upthread to HEAD and leave
>> the back-branches broken, for fear of creating an incompatibility.
>>
>
> The
Robert Haas wrote:
OK, so I talked to Bruce about this and I guess I've been persuaded
that we should just apply the patch I sent upthread to HEAD and leave
the back-branches broken, for fear of creating an incompatibility.
The only thing that might be appropriate to backport is the docs fix
On Tue, Jul 6, 2010 at 11:25 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 6, 2010 at 11:10 AM, Tom Lane wrote:
>>> 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 branch
On Tue, Jul 6, 2010 at 11:25 AM, Tom Lane wrote:
> without any field complaints,
I refer you to Simon's original commit message: "Bug found during
recent performance tuning for PostgreSQL user."
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent v
Robert Haas writes:
> On Tue, Jul 6, 2010 at 11:10 AM, Tom Lane wrote:
>> 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
On Tue, Jul 6, 2010 at 11:10 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 6, 2010 at 11:03 AM, Bruce Momjian wrote:
>>> Anything backpatched risks causing instability, and might discourage
>>> people from performing minor upgrades. Minor fixes are rarely worth the
>>> risk of causin
Robert Haas writes:
> On Tue, Jul 6, 2010 at 11:03 AM, Bruce Momjian 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 ca
Robert Haas writes:
> 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
On Tue, Jul 6, 2010 at 11:03 AM, Bruce Momjian 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
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 com
On Tue, Jul 6, 2010 at 10:42 AM, Tom Lane wrote:
> Robert Haas 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 t
Robert Haas wrote:
On Fri, Jun 25, 2010 at 1:56 PM, Josh Berkus 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 peopl
Robert Haas 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,
On Fri, Jun 25, 2010 at 1:56 PM, Josh Berkus 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 script
On Fri, 2010-06-25 at 10:56 -0700, Josh Berkus 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 ;-)
We can still output bytes, no problem. The issue is that the parameter
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
On Fri, 2010-06-25 at 17:25 +0300, Heikki Linnakangas wrote:
> On 25/06/10 16:11, Simon Riggs wrote:
> > Log Message:
> > ---
> > Fix log_temp_files docs and comments to say bytes not kilobytes.
> > stat(2) field st_size returns bytes not kilobytes.
> > Bug found during recent performance t
On 25/06/10 16:11, Simon Riggs wrote:
Log Message:
---
Fix log_temp_files docs and comments to say bytes not kilobytes.
stat(2) field st_size returns bytes not kilobytes.
Bug found during recent performance tuning for PostgreSQL user.
Modified Files:
--
pgsql/doc/src/sgm
22 matches
Mail list logo
