Andrew Dunstan [EMAIL PROTECTED] writes:
stark wrote:
So I hacked psql to issue queries asynchronously and allow multiple
database connections. That way you can switch connections while a blocked
or slow transaction is still running and issue queries in other
transactions.
[snip]
Am Donnerstag, 17. August 2006 17:17 schrieb stark:
Instead I just added a command to cause psql to wait for a time.
Do we need the full multiple-connection handling command set, or would
asynchronous query support and a wait command be enough?
--
Peter Eisentraut
On Fri, Aug 18, 2006 at 02:46:39PM +0200, Peter Eisentraut wrote:
Am Donnerstag, 17. August 2006 17:17 schrieb stark:
Instead I just added a command to cause psql to wait for a time.
Do we need the full multiple-connection handling command set, or would
asynchronous query support and a
stark wrote:
Alvaro Herrera alvherre ( at ) commandprompt ( dot ) com writes:
Maybe we could write a suitable test case using Martijn's concurrent
testing framework.
The trick is to get process A to commit between the times that process B
looks at the new and old versions of the
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Vacuum's always had a race condition: it makes a list of rel OIDs and
then tries to vacuum each one. It narrows the window for failure by
doing a SearchSysCacheExists test before relation_open, but there's
still a window for
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Maybe we could write a suitable test case using Martijn's concurrent
testing framework.
The trick is to get process A to commit between the times that process B
looks at the new and old versions of the pg_class row (and it has to
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
maybe the following buildfarm report means that we need a new theory :-(
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spongedt=2006-08-16%2021:30:02
Vacuum's always had a race condition: it makes a list of rel OIDs and
then tries to vacuum
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
maybe the following buildfarm report means that we need a new theory :-(
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spongedt=2006-08-16%2021:30:02
Vacuum's always had a race condition: it makes a list of rel OIDs and
Alvaro Herrera alvherre ( at ) commandprompt ( dot ) com writes:
Maybe we could write a suitable test case using Martijn's concurrent
testing framework.
The trick is to get process A to commit between the times that process B
looks at the new and old versions of the pg_class row (and it
stark wrote:
Actually I was already looking into a related issue and have some work here
that may help with this.
I wanted to test the online index build and to do that I figured you needed to
have regression tests like the ones we have now except with multiple database
sessions. So I
On Thu, Aug 17, 2006 at 04:17:01PM +0100, stark wrote:
I wanted to test the online index build and to do that I figured you needed to
have regression tests like the ones we have now except with multiple database
sessions. So I hacked psql to issue queries asynchronously and allow multiple
On Thu, Aug 17, 2006 at 03:09:30PM -0400, Alvaro Herrera wrote:
stark wrote:
Actually I was already looking into a related issue and have some work here
that may help with this.
I wanted to test the online index build and to do that I figured you needed
to
have regression tests
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Aug 17, 2006 at 03:09:30PM -0400, Alvaro Herrera wrote:
I have had an idea for some time that is actually much simpler -- just
launch several backends at once to do different things, and randomly
send SIGSTOP and SIGCONT to each. If they keep
On Sun, Jul 30, 2006 at 11:44:44AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Stefan Kaltenbrunner wrote:
FYI: lionfish just managed to hit that problem again:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2006-07-29%2023:30:06
The test alter_table,
Jim C. Nasby wrote:
On Sun, Jul 30, 2006 at 11:44:44AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Stefan Kaltenbrunner wrote:
FYI: lionfish just managed to hit that problem again:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2006-07-29%2023:30:06
The test
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Jim C. Nasby wrote:
On Sun, Jul 30, 2006 at 11:44:44AM -0400, Tom Lane wrote:
The path of least resistance might just be to not run these tests in
parallel. The chance of this issue causing problems in the real world
seems small.
It doesn't
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Jim C. Nasby wrote:
On Sun, Jul 30, 2006 at 11:44:44AM -0400, Tom Lane wrote:
The path of least resistance might just be to not run these tests in
parallel. The chance of this issue causing problems in the real
Andrew Dunstan wrote:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Jim C. Nasby wrote:
On Sun, Jul 30, 2006 at 11:44:44AM -0400, Tom Lane wrote:
The path of least resistance might just be to not run these tests in
parallel. The chance of this issue causing
Stefan Kaltenbrunner wrote:
Andrew Dunstan wrote:
How sure are we that this is the cause of the problem? The feeling I got
was this is a good guess. If so, do we want to prevent ourselves
getting any further clues in case we're wrong? It's also an interesting
case of a (low likelihood)
Alvaro Herrera [EMAIL PROTECTED] writes:
Maybe we could write a suitable test case using Martijn's concurrent
testing framework.
The trick is to get process A to commit between the times that process B
looks at the new and old versions of the pg_class row (and it has to
happen to do so in that
Tom Lane wrote:
As far as Andrew's question goes: I have no doubt that this race
condition is (or now, was) real and could explain Stefan's failure.
It's not impossible that there's some other problem in there, though.
If so we will still see the problem from time to time on HEAD, and
know that
Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
FWIW: lionfish had a weird make check error 3 weeks ago which I
(unsuccessfully) tried to reproduce multiple times after that:
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
FWIW: lionfish had a weird make check error 3 weeks ago which I
(unsuccessfully) tried to reproduce multiple times after that:
Alvaro Herrera [EMAIL PROTECTED] writes:
Stefan Kaltenbrunner wrote:
FYI: lionfish just managed to hit that problem again:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2006-07-29%2023:30:06
The test alter_table, which is on the same parallel group as limit (the
failing test),
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
FWIW: lionfish had a weird make check error 3 weeks ago which I
(unsuccessfully) tried to reproduce multiple times after that:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2006-05-12%2005:30:14
Weird.
Mark Wong wrote:
Now why are we failing on 7.3? What version of flex do you have? If
it's too modern we'll just need to take 7.3 out of the cobra and
stoat rotations - we'd really only make supercritical fixes on that
branch these days.
Flex is 2.5.33 on both systems. I'm assuming
On Thu, 2006-06-22 at 12:52 -0400, Andrew Dunstan wrote:
I believe our supported version is still 2.5.4, which is
what all my linux systems have.
Its not clear to me why some people have such antipathy toward recent
flex releases, but if our only supported flex version is 2.5.4, I think
this
Neil Conway [EMAIL PROTECTED] writes:
On Thu, 2006-06-22 at 12:52 -0400, Andrew Dunstan wrote:
I believe our supported version is still 2.5.4, which is
what all my linux systems have.
Its not clear to me why some people have such antipathy toward recent
flex releases, but if our only
Andrew Dunstan [EMAIL PROTECTED] writes:
Mark Wong wrote:
Flex is 2.5.33 on both systems. I'm assuming that's too modern so
I'll go ahead and stop building 7.3 for those systems.
You could be lucky the others build. I believe our supported version is
still 2.5.4, which is what all my
I can take other if that helps.
Larry, could you help me in the setup?
Regards,
On Thu, 8 Jun 2006, Andrew Dunstan wrote:
Date: Thu, 08 Jun 2006 10:54:09 -0400
From: Andrew Dunstan [EMAIL PROTECTED]
Newsgroups: pgsql.hackers
Subject: Re: Going for 'all green' buildfarm results
Larry
On Fri, 9 Jun 2006 ohp@pyrenet.fr wrote:
Date: Fri, 9 Jun 2006 11:12:07 +0200
From: ohp@pyrenet.fr
To: Andrew Dunstan [EMAIL PROTECTED], Larry Rosenman ler@lerctr.org
Newsgroups: pgsql.hackers
Subject: Re: Going for 'all green' buildfarm results
I can take other if that helps.
Ooops...
Larry Rosenman wrote:
well, the changes didn't help.
I've pulled ALL the cronjobs from firefly.
consider it dead.
Since it is an outlier, it's not useful.
OK, I am marking firefly as retired. That means we have no coverage for
Unixware.
cheers
andrew
Original Message
From: Tom Lane [EMAIL PROTECTED]
kudu HEAD: one-time failure 6/1/06 in statement_timeout test, never seen
before. Is it possible system was under enough load that the 1-second
timeout fired before control reached the exception block?
The load here was
Tom Lane wrote:
I've been making another pass over getting rid of buildfarm failures.
The remaining ones I see at the moment are:
firefly HEAD: intermittent failures in the stats test. We seem to have
fixed every other platform back in January, but not this one.
kudu HEAD: one-time
Tom Lane wrote:
I've been making another pass over getting rid of buildfarm failures.
The remaining ones I see at the moment are:
firefly HEAD: intermittent failures in the stats test. We seem to
have fixed every other platform back in January, but not this one.
firefly 7.4: dblink
Larry Rosenman said:
Tom Lane wrote:
I've been making another pass over getting rid of buildfarm failures.
The remaining ones I see at the moment are:
firefly HEAD: intermittent failures in the stats test. We seem to
have fixed every other platform back in January, but not this one.
Tom Lane wrote:
Or is
it worth improving buildfarm to be able to skip specific tests?
There is a session on buildfarm improvements scheduled for the Toronto
conference. This is certainly one possibility.
cheers
andrew
---(end of
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
FWIW: lionfish had a weird make check error 3 weeks ago which I
(unsuccessfully) tried to reproduce multiple times after that:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2006-05-12%2005:30:14
Weird.
SELECT ''::text AS eleven,
Andrew Dunstan [EMAIL PROTECTED] writes:
Larry Rosenman said:
If I generate fixes for firefly (I'm the owner), would they have a
prayer Of being applied?
Sure, although I wouldn't bother with 7.3 - just take 7.3 out of firefly's
build schedule. That's not carte blanche on fixes, of course -
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Larry Rosenman said:
If I generate fixes for firefly (I'm the owner), would they have a
prayer Of being applied?
Sure, although I wouldn't bother with 7.3 - just take 7.3 out of
firefly's build schedule. That's not carte blanche on
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
FWIW: lionfish had a weird make check error 3 weeks ago which I
(unsuccessfully) tried to reproduce multiple times after that:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lionfishdt=2006-05-12%2005:30:14
Weird.
Larry Rosenman wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Larry Rosenman said:
If I generate fixes for firefly (I'm the owner), would they have a
prayer Of being applied?
Sure, although I wouldn't bother with 7.3 - just take 7.3 out of
firefly's build schedule.
Larry Rosenman wrote:
Larry Rosenman wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Larry Rosenman said:
If I generate fixes for firefly (I'm the owner), would they have a
prayer Of being applied?
Sure, although I wouldn't bother with 7.3 - just take 7.3 out of
I've been making another pass over getting rid of buildfarm failures.
The remaining ones I see at the moment are:
firefly HEAD: intermittent failures in the stats test. We seem to have
fixed every other platform back in January, but not this one.
kudu HEAD: one-time failure 6/1/06 in
44 matches
Mail list logo
