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.
>
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 windo
stark wrote:
Alvaro Herrera 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
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
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
http://developer.postgresql.
"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 the
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 regres
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
> d
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
> Alvaro Herrera 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 ord
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=sponge&dt=2006-08-16%2021:30:02
>
> Vacuum's always had a race condition: it makes a list of rel O
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=sponge&dt=2006-08-16%2021:30:02
Vacuum's always had a race condition: it makes a list of rel OIDs and
then tries to vacu
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 ha
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 w
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 th
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 lik
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.
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 w
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.
>>
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=lionfish&dt=2006-07-29%2023
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=lionfish&dt=2006-07-29%2023:30:06
>
> > The test
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=lionfish&dt=2006-07-29%2023:30:06
> The test alter_table, which is on the same parallel group as limit (the
> faili
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:
http://www.pgbuildfarm.org/cgi-bi
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:
> >
> >> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lio
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=lionfish&dt=2006-05-12%2005:30:14
>
> Weir
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
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
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 s
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 that
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
> Newsgroups: pgsql.hackers
> Subject: Re: Going for 'all green' buildfarm results
>
> I can take other if that helps.
Ooops... takeover
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
>
> Larr
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
---(e
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
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 -
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
>>> firefl
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=lionfish&dt=2006-05-12%2005:30:14
>
>
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
"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, o
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=lionfish&dt=2006-05-12%2005:30:14
Weird.
SELECT ''::text AS el
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 broadcast)-
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 on
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: db
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
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 statement_t
44 matches
Mail list logo
