Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have just seen this error again, this time on Cygwin. I did a trawl thought
> the buildfarm history looking for other occurrences and found it happening on
> many platforms:
[ yawning... ] I've got to go to bed now, but so far tonight my Fedora
Cor
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I have seen this failure several times, but not consistently, on the
buildfarm member otter (Debian/MIPS) and possible on others, and am
wondering if it indicates a possible race condition on DROP SCHEMA CASCADE.
Hard to see what
Bruce Momjian wrote:
well, I usually get results that differ by that much from run to run.
Probably you ran in to more checkpoints on the second test.
Also, did you reinitialize the bench database with pgbench -i ?
I destroyed the database and recreated it.
The only way I managed to contro
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> This result is now seen for HEAD on buildfarm member osprey:
Yeah, I was wondering about that. It should be easy to reproduce the
failure by hand (just run the tsearch regression test and then
re-execute that query) --- can we see a debugger stack trac
John Hansen wrote:
> > > > I ran some tests last week and can report results similar on Tom's test:
> > > >
> > > > pgbench -i -s 10 bench
> > > > pgbench -c 10 -t 1 bench
> > > >
>
> don't you have to specify the scaling factor for the benchmark as well?
> as in pgbench -c 1
> > > I ran some tests last week and can report results similar on Tom's test:
> > >
> > > pgbench -i -s 10 bench
> > > pgbench -c 10 -t 1 bench
> > >
don't you have to specify the scaling factor for the benchmark as well?
as in pgbench -c 10 -t 1 -s 10 bench ?
> I just tried and go
This result is now seen for HEAD on buildfarm member osprey:
= pgsql.23138/contrib/tsearch/regression.diffs ===
*** ./expected/tsearch.out Tue Dec 28 12:05:27 2004
--- ./results/tsearch.out Tue Dec 28 19:52:47 2004
***
*** 312,322
(1 row)
SELECT
On Tue, 2004-12-28 at 07:23, John Hansen wrote:
> > I ran some tests last week and can report results similar on Tom's test:
> >
> > pgbench -i -s 10 bench
> > pgbench -c 10 -t 1 bench
> >
> > The tests were on a machine with a single SCSI drive that doesn't lie
> > about fsync. I fo
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ISTM that libpq itself ought to default to localhost, rather than
>> failing, on machines that don't have Unix sockets.
> So then it would be picked up by pg_dump, createdb etc., plus third
> party clients? Not a bad idea. Are you go
Tom Lane wrote:
Isn't this fix in the wrong place?
2004-03-23 22:10 momjian
* src/bin/psql/startup.c: >>Also, what is the default connection
mode of psql? It should probably be
>>equivalent to "-h localhost", shouldn't it?
>>
>>
>
>Now that
Isn't this fix in the wrong place?
2004-03-23 22:10 momjian
* src/bin/psql/startup.c: >>Also, what is the default connection
mode of psql? It should probably be
>>equivalent to "-h localhost", shouldn't it?
>>
>>
>
>Now that is something I
Tom Lane wrote:
> Bruce Momjian writes:
> > John Hansen wrote:
> >> On another note, how do you know for sure, that your drive does not lie
> >> about fsync?
>
> > I just tried and got 115tps with fsync off vs 100 with fsync on, so
> > fsync is certainly doing something.
>
> [ raised eyebrow...
Bruce Momjian writes:
> John Hansen wrote:
>> On another note, how do you know for sure, that your drive does not lie
>> about fsync?
> I just tried and got 115tps with fsync off vs 100 with fsync on, so
> fsync is certainly doing something.
[ raised eyebrow... ] Something is wrong with that.
John Hansen wrote:
> > I ran some tests last week and can report results similar on Tom's test:
> >
> > pgbench -i -s 10 bench
> > pgbench -c 10 -t 1 bench
> >
> > The tests were on a machine with a single SCSI drive that doesn't lie
> > about fsync. I found 7.4.X got around 75tps wh
[EMAIL PROTECTED] wrote:
Are there any plans for modifying the message outputs from the programs to
support multiple languages?
Most of the messages (at least in things like the database engine and
utilities like initdb etc) have messages hard coded in English. This does
not affect me very much, b
Are there any plans for modifying the message outputs from the programs to
support multiple languages?
Most of the messages (at least in things like the database engine and
utilities like initdb etc) have messages hard coded in English. This does
not affect me very much, but I have at least 6 beta
Merlin Moncure wrote:
> Bruce Momjian wrote:
> > What are the open issues before we can release an RC3? I don't know
> of
> > any except the btree problem OSDL found. Is that fixed? Are their
> > others?
>
> There sill may be an issue with the statistics collector resetting
> randomly on a win3
Magnus Hagander wrote:
> > What are the open issues before we can release an RC3? I
> > don't know of any except the btree problem OSDL found. Is
> > that fixed? Are their others?
>
> There is the issue with shared mem on Win2003 that came up the other
> day. I don't think it's a general erro
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> There is the issue with shared mem on Win2003 that came up the other
> day. I don't think it's a general error, but rather something
> environment specific. (I've had several reports of ppl with fairly large
> databases in production on win2003 that d
Bruce Momjian writes:
> What are the open issues before we can release an RC3? I don't know of
> any except the btree problem OSDL found. Is that fixed?
No; we haven't seen a test case yet, or even any details except the
error message.
FWIW, I think it's highly likely that whatever bug Mark ha
> There is the issue with shared mem on Win2003 that came up the other
> day. I don't think it's a general error, but rather something
> environment specific. (I've had several reports of ppl with fairly
large
> databases in production on win2003 that don't have this problem). But
> it'd be good to
Bruce Momjian wrote:
> What are the open issues before we can release an RC3? I don't know
of
> any except the btree problem OSDL found. Is that fixed? Are their
> others?
There sill may be an issue with the statistics collector resetting
randomly on a win32 server under heavy load. I have not
> What are the open issues before we can release an RC3? I
> don't know of any except the btree problem OSDL found. Is
> that fixed? Are their others?
There is the issue with shared mem on Win2003 that came up the other
day. I don't think it's a general error, but rather something
environment
On Mon, Dec 27, 2004 at 03:11:11PM -0600, Jaime Casanova wrote:
Jaime,
> there is way to display all the values (fields) in a
> tree node like this? for debug purpouses.
>
> Query*query;
Have you tried gdb already? You attach it to a running backend and can
query the (err) Query struct.
Added to TODO:
* Improve the background writer
Allow the background writer to more efficiently write dirty buffers
from the end of the LRU cache and use a clock sweep algorithm to
write other dirty buffers to reduced checkpoint I/O
25 matches
Mail list logo
