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

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

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.

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

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 ...

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

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

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

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'??

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

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

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

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

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/

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 ;:)

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 ...

Vadim originally intended 5 milliseconds, he only read the parameter wrong.
Then noticing, that the parameter is actually microseconds, he iirc decided to
leave it as is because the discussion at that time seemed to lead to the conclusion,
that a simple yield would be optimal in lack of some sort of detection, and
the select with 5 us seemed closest to that.

At least on AIX it looks like the select with 0 timeout is a noop, and does not
yield the processor. There was discussion, that other OS's (BSD) also does an
immediate return in case of 0 timeout.

Minimum select(2) delay is 1 msec on AIX (tested with Tom's test.c).

So, what was the case against using yield (2) ?

Andreas

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/

At least on AIX it looks like the select with 0 timeout is a noop, and does not
yield the processor. There was discussion, that other OS's (BSD) also does an
immediate return in case of 0 timeout.

Minimum select(2) delay is 1 msec on AIX (tested with Tom's test.c).

So, what was the case against using yield (2) ?

BSDi doesn't have yield(). It does have sched_yield(), but that
controls threads:

force the current pthread to be rescheduled

so there doesn't seem to be any portable way to do this. Sleeps of zero
do no kernel call, and sleeps > 0 sleep for a minimum of one tick.

If you really want a near-zero sleep, you need to do a no-op kernel
call, like umask(), but doing a simple kernel call usually is not enough
because kernels usually favor the last-running process because of the
CPU cache. We need a "try to schedule someone else if they are ready to
run, if not, return right away" call.

I think ultimately, we need the type of near-committers feedback, but
not for 7.1.

-- 
  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

Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:

So, what was the case against using yield (2) ?

$ man 2 yield
No entry for yield in section 2 of the manual.

Lack of portability :-(

regards, tom lane