7.4.1 ... slight change of scheduale ...

--On Friday, December 05, 2003 12:47:40 -0400 "Marc G. Fournier"
<scrappy@postgresql.org> 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: scrappy@hub.org 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: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

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.

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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

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

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.

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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

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

Peter Eisentraut <peter_e@gmx.net> 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

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> 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
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

"Marc G. Fournier" <scrappy@postgresql.org> 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

Neil Conway wrote:

"Marc G. Fournier" <scrappy@postgresql.org> 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
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Neil Conway <neilc@samurai.com> 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

Tom Lane wrote:

Neil Conway <neilc@samurai.com> 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
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> 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

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> 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
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> 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

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> 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
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> 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) * 1000000.0 + (int) (now.tv_usec - then.tv_usec);
sleep_secs = args->sleep_base_value + args->sleep_scaling_factor * diff / 1000000.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

Bruce Momjian wrote:

Tom Lane wrote:

Neil Conway <neilc@samurai.com> 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
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073