Prev: Bug? Concurrent COMMENT ON and DROP object
Next: pgsql: Fix log_temp_files docs and comments to say bytes not kilobytes.
From: Tom Lane on 6 Jul 2010 11:25
Robert Haas <robertmhaas(a)gmail.com> writes:
> On Tue, Jul 6, 2010 at 11:10 AM, Tom Lane <tgl(a)sss.pgh.pa.us> 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 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.

Uh, no, the suggestion is to do *nothing* in the back branches. Yes
they're buggy, but without any field complaints, it's hard to argue that
anyone much cares. And I agree with Greg Smith that for anyone who does
care, a behavioral change in a minor release is much harder to deal with
than a change at a major release.

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:29
On Tue, Jul 6, 2010 at 11:25 AM, Tom Lane <tgl(a)sss.pgh.pa.us> 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 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 14:38
On Tue, Jul 6, 2010 at 11:25 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas(a)gmail.com> writes:
>> On Tue, Jul 6, 2010 at 11:10 AM, Tom Lane <tgl(a)sss.pgh.pa.us> 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 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.
>
> Uh, no, the suggestion is to do *nothing* in the back branches. �Yes
> they're buggy, but without any field complaints, it's hard to argue that
> anyone much cares. �And I agree with Greg Smith that for anyone who does
> care, a behavioral change in a minor release is much harder to deal with
> than a change at a major release.

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.
I'll go do that unless someone wants to argue further...

--
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: Robert Haas on 6 Jul 2010 16:01
On Tue, Jul 6, 2010 at 3:40 PM, Greg Smith <greg(a)2ndquadrant.com> 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 only thing that might be appropriate to backport is the docs fix, change
> "kilobytes" to "bytes" in config.sgml where the parameter is described. �The
> bug complaint here was mad at the documentation not matching the behavior,
> rather than the behavior itself. �I agree with the change to HEAD you've
> suggested though, that's the right way to do this for future releases.
>
> This change is something worth mentioning in the release notes for 9.0 too.

I talked about that with Bruce. It wouldn't actually be sufficient to
just say "it's in bytes", because if you do "show log_temp_files",
it'll tell you that it's in kB, but it's really not. So we'd need to
basically explain that it's a bug we're not fixing for fear of
breaking existing installations. 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.

--
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:06
Robert Haas <robertmhaas(a)gmail.com> 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, so
> either nobody's using it or they're not looking at what's actually
> happening too carefully.

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'm not dead set against doing what you propose, just think it needs
some discussion.

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

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Bug? Concurrent COMMENT ON and DROP object
Next: pgsql: Fix log_temp_files docs and comments to say bytes not kilobytes.