
things appear to have quieted off nicely ... so would like to put out a
Beta5 for testing ...

Tom, I saw/read your proposal about the JOIN syntax, but haven't seen any
commit on it yet, nor any arguments against the changes ... so just
wondering where those stand right now?

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org




Fri, 16 Feb 2001 13:39:08 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
beta5 ... 
The Hermit Hacker <scrappy@hub.org> writes:
> things appear to have quieted off nicely ... so would like to put out a
> Beta5 for testing ...

> Tom, I saw/read your proposal about the JOIN syntax, but haven't seen any
> commit on it yet, nor any arguments against the changes ... so just
> wondering where those stand right now?

You must have been looking the other way ;-) ... it's committed.

What I'm currently thinking about is the discussion from last week where
Vadim reported that he could get "stuck spinlock" errors during btree
index crash recovery, because the backend fixing the index might hold
disk-buffer locks longer than the ~70 second timeout for spinlocks
(see "Btree runtime recovery. Stuck spins" thread on 2/8 and 2/9).

Vadim says (and I agree) that we really ought to implement a new
lightweight lock manager that would fall between spinlocks and regular
locks in terms of overhead and functionality.  But it's not reasonable
to try to do that for 7.1 at this late date.  So I was trying to pick a
stopgap solution for 7.1.  Unfortunately Vadim's off to Siberia and I
can't consult with him...

I'm currently thinking of modifying the buffer manager so that disk
buffer spinlocks use an alternate version of s_lock() with no timeout,
and perhaps longer sleeps (no zero-delay selects anyway).  This was one
of the ideas we kicked around last week, and I think it's about the best
we can do for now.  Comments anyone?

Other than that, I have nothing to hold up a beta5.  Anyone else?

			regards, tom lane

Fri, 16 Feb 2001 16:17:46 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: beta5 ... 
I am GO.  SET DIAGNOSTICS is my only open item left.


> The Hermit Hacker <scrappy@hub.org> writes:
> > things appear to have quieted off nicely ... so would like to put out a
> > Beta5 for testing ...
> 
> > Tom, I saw/read your proposal about the JOIN syntax, but haven't seen any
> > commit on it yet, nor any arguments against the changes ... so just
> > wondering where those stand right now?
> 
> You must have been looking the other way ;-) ... it's committed.
> 
> What I'm currently thinking about is the discussion from last week where
> Vadim reported that he could get "stuck spinlock" errors during btree
> index crash recovery, because the backend fixing the index might hold
> disk-buffer locks longer than the ~70 second timeout for spinlocks
> (see "Btree runtime recovery. Stuck spins" thread on 2/8 and 2/9).
> 
> Vadim says (and I agree) that we really ought to implement a new
> lightweight lock manager that would fall between spinlocks and regular
> locks in terms of overhead and functionality.  But it's not reasonable
> to try to do that for 7.1 at this late date.  So I was trying to pick a
> stopgap solution for 7.1.  Unfortunately Vadim's off to Siberia and I
> can't consult with him...
> 
> I'm currently thinking of modifying the buffer manager so that disk
> buffer spinlocks use an alternate version of s_lock() with no timeout,
> and perhaps longer sleeps (no zero-delay selects anyway).  This was one
> of the ideas we kicked around last week, and I think it's about the best
> we can do for now.  Comments anyone?
> 
> Other than that, I have nothing to hold up a beta5.  Anyone else?
> 
> 			regards, tom lane
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 16 Feb 2001 21:18:06 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: beta5 ...
At 04:17 PM 2/16/01 -0500, Tom Lane wrote:
>
>Vadim says (and I agree) that we really ought to implement a new
>lightweight lock manager that would fall between spinlocks and regular
>locks in terms of overhead and functionality.  But it's not reasonable

Will there be an arbitrary user locking feature? E.g. lock on arbitrary
text string. That would be great :). 

BTW, is 7.1 going to be a bit slower than 7.0? Or just Beta 5? Just
curious. Don't mind waiting for 7.2 for the speed-up if necessary.

Cheerio,
Link.



Sat, 17 Feb 2001 11:43:31 +0800
Lincoln Yeoh <lyeoh@pop.jaring.my>
Re: beta5 ... 
> BTW, is 7.1 going to be a bit slower than 7.0? Or just Beta 5? Just
> curious. Don't mind waiting for 7.2 for the speed-up if necessary.
> 

We expect 7.1 to be faster than 7.0.X.  We may have a small problem that
we may have to address.  Not sure yet.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 16 Feb 2001 22:47:03 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: beta5 ...
On Sat, 17 Feb 2001, Lincoln Yeoh wrote:

> At 04:17 PM 2/16/01 -0500, Tom Lane wrote:
> >
> >Vadim says (and I agree) that we really ought to implement a new
> >lightweight lock manager that would fall between spinlocks and regular
> >locks in terms of overhead and functionality.  But it's not reasonable
>
> Will there be an arbitrary user locking feature? E.g. lock on arbitrary
> text string. That would be great :).
>
> BTW, is 7.1 going to be a bit slower than 7.0? Or just Beta 5? Just
> curious. Don't mind waiting for 7.2 for the speed-up if necessary.

It is possible that it will be ... the question is whether the slow down
is unbearable or not, as to whether we'll let it hold things up or not ...

 From reading one of Tom's email's, it looks like the changes to 'fix' the
slowdown are drastic/large enough that it might not be safe (or desirable)
to fix it at this late of a stage in beta ...

Depending on what is involved, we might put out a v7.1 for March 1st, so
that ppl can feel confident about using the various features, but have a
v7.1.1 that follows relatively closely on its heels that addresses the
performance problem ...





Sat, 17 Feb 2001 00:56:24 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: beta5 ... 
> Other than that, I have nothing to hold up a beta5.  Anyone else?
> 
> 			regards, tom lane

I see a small problem with the regression test. If PL/pgSQL has been
already to template1, the regression scripts will fail because
createlang fails. Probably we should create the regression database
using template0?
--
Tatsuo Ishii

Sat, 17 Feb 2001 14:18:42 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: beta5 ... 
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> Probably we should create the regression database
> using template0?

Seems like a good idea.

			regards, tom lane

Sat, 17 Feb 2001 00:27:34 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: beta5 ... 
> >
> > BTW, is 7.1 going to be a bit slower than 7.0? Or just Beta 5? Just
> > curious. Don't mind waiting for 7.2 for the speed-up if necessary.
> 
> It is possible that it will be ... the question is whether the slow down
> is unbearable or not, as to whether we'll let it hold things up or not ...
> 
> >From reading one of Tom's email's, it looks like the changes to 'fix' the
> slowdown are drastic/large enough that it might not be safe (or desirable)
> to fix it at this late of a stage in beta ...
> 
> Depending on what is involved, we might put out a v7.1 for March 1st, so
> that ppl can feel confident about using the various features, but have a
> v7.1.1 that follows relatively closely on its heels that addresses the
> performance problem ...

The easy fix is to just set the delay to zero.  Looks like that will fix
most of the problem.  The near-committers thing may indeed be overkill,
and certainly is not worth holding beta.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sat, 17 Feb 2001 00:37:58 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: beta5 ...
On Sat, 17 Feb 2001, Bruce Momjian wrote:

> > >
> > > BTW, is 7.1 going to be a bit slower than 7.0? Or just Beta 5? Just
> > > curious. Don't mind waiting for 7.2 for the speed-up if necessary.
> >
> > It is possible that it will be ... the question is whether the slow down
> > is unbearable or not, as to whether we'll let it hold things up or not ...
> >
> > >From reading one of Tom's email's, it looks like the changes to 'fix' the
> > slowdown are drastic/large enough that it might not be safe (or desirable)
> > to fix it at this late of a stage in beta ...
> >
> > Depending on what is involved, we might put out a v7.1 for March 1st, so
> > that ppl can feel confident about using the various features, but have a
> > v7.1.1 that follows relatively closely on its heels that addresses the
> > performance problem ...
>
> The easy fix is to just set the delay to zero.  Looks like that will fix
> most of the problem.

Except that Vadim had a reason for setting it to 5, and I'm loath to see
that changed unless someone actaully understands the ramifications other
then increasing performance ...

> The near-committers thing may indeed be overkill, and certainly is not
> worth holding beta.

What is this 'near-committers thing'??



Sat, 17 Feb 2001 13:23:49 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: Re: beta5 ...
The Hermit Hacker <scrappy@hub.org> writes:
>> The easy fix is to just set the delay to zero.  Looks like that will fix
>> most of the problem.

> Except that Vadim had a reason for setting it to 5,

He claimed to have seen better performance with a nonzero delay.
So far none of the rest of us have been able to duplicate that.
Perhaps he was using a machine where a 5-microsecond select() delay
actually is 5 microseconds?  If so, he's the outlier, not the
rest of us ...

			regards, tom lane

Sat, 17 Feb 2001 12:30:02 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: beta5 ... 
> > The easy fix is to just set the delay to zero.  Looks like that will fix
> > most of the problem.
> 
> Except that Vadim had a reason for setting it to 5, and I'm loath to see
> that changed unless someone actaully understands the ramifications other
> then increasing performance ...

See post from a few minutes ago with analysis of purpose and actual
affect of Vadim's parameter.  I objected to the delay when it was
introduced because of my analysis, but Vadim's argument is that 5
microseconds is very small delay, just enough to yield the CPU.  We now
see that is much longer than that.

> 
> > The near-committers thing may indeed be overkill, and certainly is not
> > worth holding beta.
> 
> What is this 'near-committers thing'??

Other backends about to commit.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sat, 17 Feb 2001 13:14:59 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: beta5 ...
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> I see a small problem with the regression test. If PL/pgSQL has been
> already to template1, the regression scripts will fail because
> createlang fails. Probably we should create the regression database
> using template0?

Done ...

			regards, tom lane

Sun, 18 Feb 2001 13:04:38 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: beta5 ... 
The Hermit Hacker <scrappy@hub.org> writes:
> things appear to have quieted off nicely ... so would like to put out a
> Beta5 for testing ...

Unless Peter E. has some more commits up his sleeve, I think we're
good to go.

			regards, tom lane

Sun, 18 Feb 2001 13:15:10 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: beta5 ... 
Tom Lane writes:

> The Hermit Hacker <scrappy@hub.org> writes:
> > things appear to have quieted off nicely ... so would like to put out a
> > Beta5 for testing ...
>
> Unless Peter E. has some more commits up his sleeve, I think we're
> good to go.

Just uploaded freshly baked man pages, including your createdb change.
That'd be it.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Sun, 18 Feb 2001 19:45:35 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: beta5 ... 
On Sun, 18 Feb 2001, Tom Lane wrote:

> The Hermit Hacker <scrappy@hub.org> writes:
> > things appear to have quieted off nicely ... so would like to put out a
> > Beta5 for testing ...
>
> Unless Peter E. has some more commits up his sleeve, I think we're
> good to go.

okay, I'll put one out Mon aft, just in case of any strays that come up
tonight, or any final commits from our overseas committers ...

thanks ;:)


Sun, 18 Feb 2001 15:00:51 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: beta5 ... 
Quoting The Hermit Hacker <scrappy@hub.org>:

> On Sun, 18 Feb 2001, Tom Lane wrote:
> 
> > The Hermit Hacker <scrappy@hub.org> writes:
> > > things appear to have quieted off nicely ... so would like to put
> out a
> > > Beta5 for testing ...
> >
> > Unless Peter E. has some more commits up his sleeve, I think we're
> > good to go.
> 
> okay, I'll put one out Mon aft, just in case of any strays that come up
> tonight, or any final commits from our overseas committers ...

I'm not planning on doing any until after Beta5 is out ;-)

Peter

> 
> thanks ;:)
> 
> 



-- 
Peter Mount peter@retep.org.uk
PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/

Mon, 19 Feb 2001 04:05:58 -0500 (EST)
Peter T Mount <peter@retep.org.uk>
Re: beta5 ...