Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Bruce Momjian wrote: Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: The libpq SSL memory leak reported on -bugs would be good to fix. We don't know yet if that's our bug or not. BTW, is there a particular reason we're pushing out 7.4.1 so soon? ISTM there wouldn't be anything wrong with waiting a week or two... Well, we do have several important fixes in the 7.4 branch (probably the PANIC in FSM management is the most important). But I tend to agree that there's no real strong reason to put it out this week rather than next week; if we can accumulate a few more bug fixes, maybe we should wait. So we have SSL, information schema (bit), and autovacuum. The last one is an easy fix, not sure on the others. Agreed we should wait a week or two. If we don't, we might need to push 7.4.2 out a few weeks after that. We now only have the SSL bug open, and another pg_autovacuum patch pending. Tom, since you return Sunday, I can have 7.4.1 packaged up and ready for your review on Monday (Dec 15). That way, as soon as the SSL bug is resolved, we can move toward release. This also gives us a week to see what new bugs appear. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: A bug in the information schema concerning the bit types must be fixed. Does anyone have a patch for this? I suppose not, but it's being worked on. What's the bug exactly? Is it worth delaying the release for? Given that Bruce is out of town now and I'll be out of town later in the week, we are probably talking about slipping 7.4.1 a full week (to Monday next) if we can't wrap it Sunday or Monday. I don't have any strong compulsion to release 7.4.1 now --- if there's good stuff in the pipeline we could certainly wait a week. But you didn't say just what this bug is ... Tatsuo/SRA liked the new release item descriptions so I will have to do that for 7.4.1, or whoever gets does the release file. If they don't do it, I will update it when I am able and they will appear when we release 7.4.2. I am not online consistently enough to do it while I am in Japan. I return Wednesday night. (I am reading emails, but I am off-line for hours or a day and can't always be sure I am caught up regularly.) He even asked about 7.3.5 and I said I was traveling during that release and would start for 7.4.X. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Marc G. Fournier [EMAIL PROTECTED] writes: To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first The libpq SSL memory leak reported on -bugs would be good to fix. BTW, is there a particular reason we're pushing out 7.4.1 so soon? ISTM there wouldn't be anything wrong with waiting a week or two... -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Neil Conway wrote: Marc G. Fournier [EMAIL PROTECTED] writes: To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first The libpq SSL memory leak reported on -bugs would be good to fix. BTW, is there a particular reason we're pushing out 7.4.1 so soon? ISTM there wouldn't be anything wrong with waiting a week or two... Yes, the SSL memory growth has been confirmed. That might justify a quick push-out once we fix it, but it requires SSL library debugging via valgrind. Do we have anything of similar significance already fixed for 7.4.1? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Neil Conway [EMAIL PROTECTED] writes: The libpq SSL memory leak reported on -bugs would be good to fix. We don't know yet if that's our bug or not. BTW, is there a particular reason we're pushing out 7.4.1 so soon? ISTM there wouldn't be anything wrong with waiting a week or two... Well, we do have several important fixes in the 7.4 branch (probably the PANIC in FSM management is the most important). But I tend to agree that there's no real strong reason to put it out this week rather than next week; if we can accumulate a few more bug fixes, maybe we should wait. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: The libpq SSL memory leak reported on -bugs would be good to fix. We don't know yet if that's our bug or not. BTW, is there a particular reason we're pushing out 7.4.1 so soon? ISTM there wouldn't be anything wrong with waiting a week or two... Well, we do have several important fixes in the 7.4 branch (probably the PANIC in FSM management is the most important). But I tend to agree that there's no real strong reason to put it out this week rather than next week; if we can accumulate a few more bug fixes, maybe we should wait. So we have SSL, information schema (bit), and autovacuum. The last one is an easy fix, not sure on the others. Agreed we should wait a week or two. If we don't, we might need to push 7.4.2 out a few weeks after that. I can package up 7.4.1 when I return so we are ready whenever we want to go. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Bruce Momjian [EMAIL PROTECTED] writes: So we have SSL, information schema (bit), and autovacuum. The last one is an easy fix, not sure on the others. I thought you already applied those autovacuum patches? Is there something else pending for it? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: So we have SSL, information schema (bit), and autovacuum. The last one is an easy fix, not sure on the others. I thought you already applied those autovacuum patches? Is there something else pending for it? I am still reading email from yesterday, but this is a new patch in the past 2 days. The problem is that time differences were overflowing int values if the vacuum took a long time, or something like that. The fix is to cast one to long long. I haven't seen a patch yet, but I saw a sample code piece that could easily be added by me. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Bruce Momjian [EMAIL PROTECTED] writes: I am still reading email from yesterday, but this is a new patch in the past 2 days. The problem is that time differences were overflowing int values if the vacuum took a long time, or something like that. The fix is to cast one to long long. That's no fix --- it will break the code on compilers without long long. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am still reading email from yesterday, but this is a new patch in the
past 2 days. The problem is that time differences were overflowing int
values if the vacuum took a long time, or something like that. The fix
is to cast one to long long.
That's no fix --- it will break the code on compilers without long long.
Here are the emails describing the problem. Seems they should see how
we do time differences in the backend as an example.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
From [EMAIL PROTECTED] Thu Dec 4 16:24:50 2003
Return-path: [EMAIL PROTECTED]
Received: from hosting.commandprompt.com (192.commandprompt.com [207.173.200.192])
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id hB4LOfJ07438
for [EMAIL PROTECTED]; Thu, 4 Dec 2003 16:24:49 -0500 (EST)
Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
by hosting.commandprompt.com (8.11.6/8.11.6) with ESMTP id hB4LL6H26870;
Thu, 4 Dec 2003 13:21:48 -0800
X-Original-To: [EMAIL PROTECTED]
Received: from localhost (neptune.hub.org [200.46.204.2])
by svr1.postgresql.org (Postfix) with ESMTP id 3806AD1B491
for [EMAIL PROTECTED]; Thu, 4 Dec 2003 21:20:52 + (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
with ESMTP id 26242-05
for [EMAIL PROTECTED];
Thu, 4 Dec 2003 17:20:23 -0400 (AST)
Received: from yertle.kcilink.com (yertle.kcilink.com [216.194.193.105])
by svr1.postgresql.org (Postfix) with ESMTP id D9481D1B47A
for [EMAIL PROTECTED]; Thu, 4 Dec 2003 17:20:20 -0400 (AST)
Received: by yertle.kcilink.com (Postfix, from userid 100)
id 5AF5A2178A; Thu, 4 Dec 2003 16:20:22 -0500 (EST)
From: Vivek Khera [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: [EMAIL PROTECTED]
Date: Thu, 4 Dec 2003 16:20:22 -0500
To: Matthew T. O'Connor [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: [PERFORM] autovacuum daemon stops doing work after about anhour
In-Reply-To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
X-Mailer: VM 7.17 under 21.4 (patch 14) Reasonable Discussion XEmacs Lucid
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-performance
Precedence: bulk
Sender: [EMAIL PROTECTED]
Status: OR
MTO == Matthew T O'Connor [EMAIL PROTECTED] writes:
MTO Could this be the recently reported bug where time goes backwards on
MTO FreeBSD? Can anyone who knows more about this problem chime in, I know it
MTO was recently discussed on Hackers.
Time does not go backwards -- the now and then variables are properly
incrementing in time as you see from the debugging output.
The error appears to be with the computation of the diff. It is
either a C programming error, or a compiler error. I'm not a C cop
so I can't tell you which it is.
Witness this program, below, compiled as cc -g -o t t.c and the
output here:
% ./t
seconds = 3509
seconds1 = 350900
useconds = -452486
stepped diff = 3508547514
seconds2 = -785967296
seconds3 = 350900
diff = -786419782
long long diff = 3508547514
%
apperantly, if you compute (now.tv_sec - then.tv_sec) * 100 all at
once, it overflows since the RHS is all computed using longs rather
than long longs. Fix is to cast at least one of the values to long
long on the RHS, as in the computation of seconds3 below. compare
that to the computation of seconds2 and you'll see that this is the
cause.
I'd be curious to see the output of this program on other platforms
and other compilers. I'm using gcc 2.95.4 as shipped with FreeBSD
4.8+.
That all being said, you should never sleep less than the base time,
and never for more than a max amount, perhaps 1 hour?
--cut here--
#include sys/time.h
#include stdio.h
int
main()
{
struct timeval now, then;
long long diff = 0;
long long seconds, seconds1, seconds2, seconds3, useconds;
now.tv_sec = 1070565077L;
now.tv_usec = 216477L;
then.tv_sec = 1070561568L;
then.tv_usec = 668963L;
seconds = now.tv_sec - then.tv_sec;
printf(seconds = %lld\n,seconds);
seconds1 = seconds * 100;
printf(seconds1 = %lld\n,seconds1);
useconds = now.tv_usec - then.tv_usec;
printf(useconds = %lld\n,useconds);
diff = seconds1 + useconds;
printf(stepped diff = %lld\n,diff);
/* this appears to be the culprit... it should be same as seconds1 */
seconds2 = (now.tv_sec - then.tv_sec) * 100;
printf(seconds2 = %lld\n,seconds2);
/* seems we need to cast long's to long long's for this computation */
seconds3
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: That's no fix --- it will break the code on compilers without long long. Here are the emails describing the problem. Seems they should see how we do time differences in the backend as an example. Now that I look at it, the code is already depending on long long, which is silly given the low need for accuracy. For portability it should be double instead: double diff; ... gettimeofday(now, 0); diff = (int) (now.tv_sec - then.tv_sec) * 100.0 + (int) (now.tv_usec - then.tv_usec); sleep_secs = args-sleep_base_value + args-sleep_scaling_factor * diff / 100.0; (the (int) casts avoid assuming that the tv_sec and tv_usec fields are of signed integer types). There's a %lld format string to fix too. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] 7.4.1 ... slight change of scheduale ...
To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first ... we know of nothing outstanding right now ... This means it will be tag'd/bundled on Sunday ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
--On Friday, December 05, 2003 12:47:40 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first ... we know of nothing outstanding right now ... Possibly the C error in pg_autovacuum re: time calcs? (see the -performance list from yesterday, conversation between Vivek Khera(sp?) and myself). This means it will be tag'd/bundled on Sunday ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
On Fri, 5 Dec 2003, Peter Eisentraut wrote: Marc G. Fournier writes: To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first ... we know of nothing outstanding right now ... A bug in the information schema concerning the bit types must be fixed. Does anyone have a patch for this? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Marc G. Fournier writes: To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first ... we know of nothing outstanding right now ... A bug in the information schema concerning the bit types must be fixed. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Marc G. Fournier wrote: To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first ... we know of nothing outstanding right now ... This means it will be tag'd/bundled on Sunday ... I've got one I've been conversing about off-list with Tom. Fix for bytea LIKE. I think I'm just about done with the fix. If so, I'll commit tonight or tomorrow morning. Not sure if it's worth holding the release for though. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Marc G. Fournier wrote: A bug in the information schema concerning the bit types must be fixed. Does anyone have a patch for this? I suppose not, but it's being worked on. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
On Sat, 6 Dec 2003, Peter Eisentraut wrote: Marc G. Fournier wrote: A bug in the information schema concerning the bit types must be fixed. Does anyone have a patch for this? I suppose not, but it's being worked on. Is that the one that Joe just mentioned workign on? about BYTEA? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Marc G. Fournier wrote: On Sat, 6 Dec 2003, Peter Eisentraut wrote: I suppose not, but it's being worked on. Is that the one that Joe just mentioned workign on? about BYTEA? I don't think so. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
Peter Eisentraut [EMAIL PROTECTED] writes: A bug in the information schema concerning the bit types must be fixed. Does anyone have a patch for this? I suppose not, but it's being worked on. What's the bug exactly? Is it worth delaying the release for? Given that Bruce is out of town now and I'll be out of town later in the week, we are probably talking about slipping 7.4.1 a full week (to Monday next) if we can't wrap it Sunday or Monday. I don't have any strong compulsion to release 7.4.1 now --- if there's good stuff in the pipeline we could certainly wait a week. But you didn't say just what this bug is ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
