Обсуждение: [HACKERS] 6.1 issues resolved
At this point, I think we have everything resolved for 6.1. The regression tests look good. We have GEQO active for more than six tables. Vadim has fixed the btree bug. The datetime types are working on all platforms. Documentation looks good. There have been very few bug reports this week. The only item that seems open is a possible memory leak problem, and the problems someone reported from Purify. If we can resolve these last items in the next few days, that would be great. If not, we should probably dig into this after 6.1 is released, and think about a cleanup release if the memory problems get bad. I know Vadim has fixed some of them, but there may be more. I know Marc is using 6.1 beta in production, so perhaps the memory problems are fixed, or he is not tickling the problem. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
I ran purify yesterday on psql, and it found several memory leaks in
libpq. I fixed a couple of them and will post a patch in a couple of
hours. Unfortunately I only have a signle terminal window for now so I
can't work on the backend but libpq is significant too..BTW: There is a
bug right now in psql:
run psql.
do \m to turn on monitor style output.
select * from some table...You should see (NULL) instead of
the row separator....
I fixed it too and will send a patch for it together with memory leak
patch (they are actually related)...
=+=------------------------/\---------------------------------=+=
Igor Natanzon |**| E-mail: igor@sba.miami.edu
=+=------------------------\/---------------------------------=+=
On Sun, 1 Jun 1997, Bruce Momjian wrote:
> At this point, I think we have everything resolved for 6.1.
>
> The regression tests look good. We have GEQO active for more than six
> tables. Vadim has fixed the btree bug. The datetime types are working
> on all platforms. Documentation looks good. There have been very few
> bug reports this week.
>
> The only item that seems open is a possible memory leak problem, and the
> problems someone reported from Purify.
>
> If we can resolve these last items in the next few days, that would be
> great.
>
> If not, we should probably dig into this after 6.1 is released, and
> think about a cleanup release if the memory problems get bad. I know
> Vadim has fixed some of them, but there may be more.
>
> I know Marc is using 6.1 beta in production, so perhaps the memory
> problems are fixed, or he is not tickling the problem.
>
> --
> Bruce Momjian
> maillist@candle.pha.pa.us
>
------------------------------
> > I ran purify yesterday on psql, and it found several memory leaks in > libpq. I fixed a couple of them and will post a patch in a couple of > hours. Unfortunately I only have a signle terminal window for now so I > can't work on the backend but libpq is significant too..BTW: There is a > bug right now in psql: > run psql. > do \m to turn on monitor style output. > select * from some table...You should see (NULL) instead of > the row separator.... > > I fixed it too and will send a patch for it together with memory leak > patch (they are actually related)... That's great. Glad you can help out. psql/libpq are certainly important to Purify. The backend Purify is going to be ugly, I would guess, because it is so big. Those memory issues are hard to find, and most of use don't have Purify to help. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
I would guess purifying the backend should be an effor of every developer
who has purify....BTW: I just ran purify on pg_dump and it came out with a
ton of memory leaks (and 40% of potential leaks)...I 'll work on that
today...
=+=------------------------/\---------------------------------=+=
Igor Natanzon |**| E-mail: igor@sba.miami.edu
=+=------------------------\/---------------------------------=+=
On Sun, 1 Jun 1997, Bruce Momjian wrote:
> >
> > I ran purify yesterday on psql, and it found several memory leaks in
> > libpq. I fixed a couple of them and will post a patch in a couple of
> > hours. Unfortunately I only have a signle terminal window for now so I
> > can't work on the backend but libpq is significant too..BTW: There is a
> > bug right now in psql:
> > run psql.
> > do \m to turn on monitor style output.
> > select * from some table...You should see (NULL) instead of
> > the row separator....
> >
> > I fixed it too and will send a patch for it together with memory leak
> > patch (they are actually related)...
>
> That's great. Glad you can help out. psql/libpq are certainly
> important to Purify.
>
> The backend Purify is going to be ugly, I would guess, because it is so
> big. Those memory issues are hard to find, and most of use don't have
> Purify to help.
>
> --
> Bruce Momjian
> maillist@candle.pha.pa.us
>
------------------------------
On Sun, 1 Jun 1997, Igor wrote:
> I would guess purifying the backend should be an effor of every developer
> who has purify....BTW: I just ran purify on pg_dump and it came out with a
> ton of memory leaks (and 40% of potential leaks)...I 'll work on that
> today...
Igor...
Before you hit any more 'Purify bugs'...have you addressed the
problem I reported earlier concerning:
# diff expected/boolean.out results/boolean.out | head
6a7,12
> psql in free(): warning: chunk is already free.
> psql in free(): warning: chunk is already free.
> psql in free(): warning: chunk is already free.
> psql in free(): warning: chunk is already free.
> psql in free(): warning: chunk is already free.
> psql in free(): warning: page is already free.
This goes on for about 337 lines, and is *after* applying your
previous psql related patch.
>
> =+=------------------------/\---------------------------------=+=
> Igor Natanzon |**| E-mail: igor@sba.miami.edu
> =+=------------------------\/---------------------------------=+=
>
> On Sun, 1 Jun 1997, Bruce Momjian wrote:
>
> > >
> > > I ran purify yesterday on psql, and it found several memory leaks in
> > > libpq. I fixed a couple of them and will post a patch in a couple of
> > > hours. Unfortunately I only have a signle terminal window for now so I
> > > can't work on the backend but libpq is significant too..BTW: There is a
> > > bug right now in psql:
> > > run psql.
> > > do \m to turn on monitor style output.
> > > select * from some table...You should see (NULL) instead of
> > > the row separator....
> > >
> > > I fixed it too and will send a patch for it together with memory leak
> > > patch (they are actually related)...
> >
> > That's great. Glad you can help out. psql/libpq are certainly
> > important to Purify.
> >
> > The backend Purify is going to be ugly, I would guess, because it is so
> > big. Those memory issues are hard to find, and most of use don't have
> > Purify to help.
> >
> > --
> > Bruce Momjian
> > maillist@candle.pha.pa.us
> >
>
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
------------------------------
This certainly sucks....I posted the wrong patch...I'll put up the patch
for a patch in a few minutes...I tested regression with old patch and with
the one I am about to post..boolean failed on old one but succeded on
second...So I think this won't be a problem anymore...
=+=------------------------/\---------------------------------=+=
Igor Natanzon |**| E-mail: igor@sba.miami.edu
=+=------------------------\/---------------------------------=+=
On Sun, 1 Jun 1997, The Hermit Hacker wrote:
> On Sun, 1 Jun 1997, Igor wrote:
>
> > I would guess purifying the backend should be an effor of every developer
> > who has purify....BTW: I just ran purify on pg_dump and it came out with a
> > ton of memory leaks (and 40% of potential leaks)...I 'll work on that
> > today...
>
> Igor...
>
> Before you hit any more 'Purify bugs'...have you addressed the
> problem I reported earlier concerning:
>
> # diff expected/boolean.out results/boolean.out | head
> 6a7,12
> > psql in free(): warning: chunk is already free.
> > psql in free(): warning: chunk is already free.
> > psql in free(): warning: chunk is already free.
> > psql in free(): warning: chunk is already free.
> > psql in free(): warning: chunk is already free.
> > psql in free(): warning: page is already free.
>
> This goes on for about 337 lines, and is *after* applying your
> previous psql related patch.
>
>
> >
> > =+=------------------------/\---------------------------------=+=
> > Igor Natanzon |**| E-mail: igor@sba.miami.edu
> > =+=------------------------\/---------------------------------=+=
> >
> > On Sun, 1 Jun 1997, Bruce Momjian wrote:
> >
> > > >
> > > > I ran purify yesterday on psql, and it found several memory leaks in
> > > > libpq. I fixed a couple of them and will post a patch in a couple of
> > > > hours. Unfortunately I only have a signle terminal window for now so I
> > > > can't work on the backend but libpq is significant too..BTW: There is a
> > > > bug right now in psql:
> > > > run psql.
> > > > do \m to turn on monitor style output.
> > > > select * from some table...You should see (NULL) instead of
> > > > the row separator....
> > > >
> > > > I fixed it too and will send a patch for it together with memory leak
> > > > patch (they are actually related)...
> > >
> > > That's great. Glad you can help out. psql/libpq are certainly
> > > important to Purify.
> > >
> > > The backend Purify is going to be ugly, I would guess, because it is so
> > > big. Those memory issues are hard to find, and most of use don't have
> > > Purify to help.
> > >
> > > --
> > > Bruce Momjian
> > > maillist@candle.pha.pa.us
> > >
> >
>
> Marc G. Fournier
> Systems Administrator @ hub.org
> primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>
------------------------------
On Sun, 1 Jun 1997, Igor wrote:
> This certainly sucks....I posted the wrong patch...I'll put up the patch
> for a patch in a few minutes...I tested regression with old patch and with
> the one I am about to post..boolean failed on old one but succeded on
> second...So I think this won't be a problem anymore...
good show...just abotu to apply your other patches, and will test
compile/regress after seeing this new one :)
>
>
>
> =+=------------------------/\---------------------------------=+=
> Igor Natanzon |**| E-mail: igor@sba.miami.edu
> =+=------------------------\/---------------------------------=+=
>
> On Sun, 1 Jun 1997, The Hermit Hacker wrote:
>
> > On Sun, 1 Jun 1997, Igor wrote:
> >
> > > I would guess purifying the backend should be an effor of every developer
> > > who has purify....BTW: I just ran purify on pg_dump and it came out with a
> > > ton of memory leaks (and 40% of potential leaks)...I 'll work on that
> > > today...
> >
> > Igor...
> >
> > Before you hit any more 'Purify bugs'...have you addressed the
> > problem I reported earlier concerning:
> >
> > # diff expected/boolean.out results/boolean.out | head
> > 6a7,12
> > > psql in free(): warning: chunk is already free.
> > > psql in free(): warning: chunk is already free.
> > > psql in free(): warning: chunk is already free.
> > > psql in free(): warning: chunk is already free.
> > > psql in free(): warning: chunk is already free.
> > > psql in free(): warning: page is already free.
> >
> > This goes on for about 337 lines, and is *after* applying your
> > previous psql related patch.
> >
> >
> > >
> > > =+=------------------------/\---------------------------------=+=
> > > Igor Natanzon |**| E-mail: igor@sba.miami.edu
> > > =+=------------------------\/---------------------------------=+=
> > >
> > > On Sun, 1 Jun 1997, Bruce Momjian wrote:
> > >
> > > > >
> > > > > I ran purify yesterday on psql, and it found several memory leaks in
> > > > > libpq. I fixed a couple of them and will post a patch in a couple of
> > > > > hours. Unfortunately I only have a signle terminal window for now so I
> > > > > can't work on the backend but libpq is significant too..BTW: There is a
> > > > > bug right now in psql:
> > > > > run psql.
> > > > > do \m to turn on monitor style output.
> > > > > select * from some table...You should see (NULL) instead of
> > > > > the row separator....
> > > > >
> > > > > I fixed it too and will send a patch for it together with memory leak
> > > > > patch (they are actually related)...
> > > >
> > > > That's great. Glad you can help out. psql/libpq are certainly
> > > > important to Purify.
> > > >
> > > > The backend Purify is going to be ugly, I would guess, because it is so
> > > > big. Those memory issues are hard to find, and most of use don't have
> > > > Purify to help.
> > > >
> > > > --
> > > > Bruce Momjian
> > > > maillist@candle.pha.pa.us
> > > >
> > >
> >
> > Marc G. Fournier
> > Systems Administrator @ hub.org
> > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> >
>
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
------------------------------
End of hackers-digest V1 #372
*****************************
Bruce Momjian wrote:
>
> At this point, I think we have everything resolved for 6.1.
>
> The regression tests look good.
Yes, but a small issue...
The horology "expected" patches Bruce applied just recently to fix the
timezone behavior for 3 rows of results from calculating
datetime-minus-timespan cause my regression test to fail, as you would
expect.
But looking into it further, I found the following behavior:
If you set TZ="PST8PDT" on my machine, you get Bruce's results.
If you set TZ="PST8PDT7,M04.01.00,M10.05.03" on my machine, you get my
original regression results!
Conclusions:
1) The public-domain localtime package used by _many_ systems has
signed-math trouble for timezones but only when interpreting a full TZ.
2) The PST8PDT timezone database supplied on many systems has the
correct information.
3) Bruce was not following the directions for the regression test :))
(or his USE_POSIX_TIME but !HAVE_INT_TIMEZONE machine does not exhibit
the bug, a more likely scenerio but it's more fun to needle Bruce...)
OK, so here is the question:
Should we assume that every installation environment has a PST8PDT
timezone database installed, or should we have the regression tests use
the full-length TZ assignment which produces a few bad-but-consistant
values on many/most platforms??
I'd be inclined to go with the bad-but-consistant solution, because a
failed regression test on a system without the problem is obviously
correct by inspection; that is not true the other way around.
I'll go either way, and can patch either the regression results or the
instructions to be self-consistant.
We should _especially_ hear from anyone who might have a problem with
the PST8PDT timezone database (e.g. Easter Europe or southern hemisphere
where the default rules are likely to be different).
- Tom
------------------------------
> If you set TZ="PST8PDT" on my machine, you get Bruce's results. > > If you set TZ="PST8PDT7,M04.01.00,M10.05.03" on my machine, you get my > original regression results! > 3) Bruce was not following the directions for the regression test :)) > (or his USE_POSIX_TIME but !HAVE_INT_TIMEZONE machine does not exhibit > the bug, a more likely scenerio but it's more fun to needle Bruce...) Correct. I have never seen such a long TZ string, nor would I expect it to work, but I am probably wrong. I think PST8PDT is pretty simple, and I would think all platforms we support use it in a similar manner. > OK, so here is the question: > Should we assume that every installation environment has a PST8PDT > timezone database installed, or should we have the regression tests use > the full-length TZ assignment which produces a few bad-but-consistant > values on many/most platforms?? PST8PDT - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
maillist@candle.pha.pa.us said: :- The backend Purify is going to be ugly, I would guess, because it is :- so big. Those memory issues are hard to find, and most of use don't :- have Purify to help. I have automated the process of FTP, build, regress, purify so that I can run it in a cron job every night. I've offered to send the output to wherever it would do the best good. I could, for example, send it to an alias (or majordomo list), or it could be ftp'd somewhere. That way people without purify can still see the results of their work. - ----------------------------------------------------------------------------- Robert Withrow, Tel: +1 617 592 8935, Net: witr@rwwa.COM ------------------------------
On Tue, 3 Jun 1997, Robert Withrow wrote:
>
> maillist@candle.pha.pa.us said:
> :- The backend Purify is going to be ugly, I would guess, because it is
> :- so big. Those memory issues are hard to find, and most of use don't
> :- have Purify to help.
>
> I have automated the process of FTP, build, regress, purify so that I
> can run it in a cron job every night. I've offered to send the output
> to wherever it would do the best good. I could, for example, send it
> to an alias (or majordomo list), or it could be ftp'd somewhere.
How about sending in patches to clean up the problems that you state
are so crucial to your work? :)
Marc G. Fournier scrappy@hub.org
Systems Administrator @ hub.org scrappy@freebsd.org
------------------------------
Marc wrote: > How about sending in patches to clean up the problems that you state > are so crucial to your work? :) Hey, don't be so harsh. Not everyone has access to purify, and some people might appreciate the facility. Though to be honest, making it available on a Web page would be preferable to mailing it. Secondly, how would you feel about putting a notice at the top of the README, saying that 6.1 has been tested with Purify, and fails a number of tests. While it remains a substantial improvement on 6.0, and is well tested in practice, people who are concerned about such things might like to wait for 6.2. If you're happy with that, there's surely little reason not to release 6.1. If you're not, you ought to wait until at least the array bounds errors are fixed. Cheers, Anthony ------------------------------
On Tue, 3 Jun 1997, Robert Withrow wrote: > > I have automated the process of FTP, build, regress, purify so that I > can run it in a cron job every night. I've offered to send the output > to wherever it would do the best good. I could, for example, send it > to an alias (or majordomo list), or it could be ftp'd somewhere. > > That way people without purify can still see the results of their work. > Perhaps a web page somewhere, so that people could user their browsers search feature. - -james [ James A. Hillyerd (JH2162) james@blarg.net - Perl Programmer ] [ http://www.blarg.net/~james/ http://www.pimedia.com/ ] [ 1024/B11C3751 CA 1C B3 A9 07 2F 57 C9 91 F4 73 F2 19 A4 C5 88 ] ------------------------------