Tom Lane wrote:
OSDL has just come out with a set of open-source database benchmarks:
http://www.osdl.org/projects/performance/
The bad news:
"This tool kit works with SAP DB open source database versions 7.3.0.23
or 7.3.0.25."
(In fact, they seem to think they are testing kernel performance, not
d
OSDL has just come out with a set of open-source database benchmarks:
http://www.osdl.org/projects/performance/
The bad news:
"This tool kit works with SAP DB open source database versions 7.3.0.23
or 7.3.0.25."
(In fact, they seem to think they are testing kernel performance, not
database perfor
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> * Make CLUSTER error out if the target index is not of an 'amindexnulls'
>> index AM. This would amount to restricting CLUSTER to b-trees, which is
>> annoying.
> I think this solution is fine - we just need to fix GiST to index nulls
> one d
Rod Taylor <[EMAIL PROTECTED]> writes:
> I'm willing to do this:
I can handle it (was already working on it, in fact). I had hoped to
find someone who might want to do the more extensive fix, but erroring
out is easy enough.
> - Reject on partial or functional indexes
> - Reject when first colum
> * Make CLUSTER error out if the target index is not of an 'amindexnulls'
> index AM. This would amount to restricting CLUSTER to b-trees, which is
> annoying.
I'm willing to do this:
- Reject on partial or functional indexes
- Reject when first columns attnotnull is false and amindexnulls is
> * Make CLUSTER error out if the target index is not of an 'amindexnulls'
> index AM. This would amount to restricting CLUSTER to b-trees, which is
> annoying.
I think this solution is fine - we just need to fix GiST to index nulls
one day :)
> It occurs to me also that the same kind of pitfall
> device. As mentioned above I may want to be able to sequentially read records
> from the database to be able to recreate the data stream that I received and
> recored. I would need to be able to read the records back fast enough to
> replay the at the same rate at which I received them.
It's
>> > TRAP: FailedAssertion("!((VfdCache[0].fd == (-1)))", File: "fd.c", Line: 1113)
> If this is a system that supports hardware watchpoints (like Linux on
> x86), then you should be able to do a "watch VfdCache[0].fd".
That's exactly what I did, and tracked the problem down to a typo in
my cod
On Sun, 2003-03-02 at 18:52, Mark Jones wrote:
> Hello
>
> I am working on a project that acquires real-time data from an external
> device that I need to store and be able to search through and retrieve
> quickly. My application receives packets of data ranging in size from 300 to
> 5000 bytes ev
Hello
I am working on a project that acquires real-time data from an external
device that I need to store and be able to search through and retrieve
quickly. My application receives packets of data ranging in size from 300 to
5000 bytes every 50 milliseconds for the minimum duration of 24 hours be
Tom Lane wrote:
> Itai Zukerman <[EMAIL PROTECTED]> writes:
> > After recompiling with --enable-cassert, nserting into an empty table,
> > I get:
>
> > TRAP: FailedAssertion("!((VfdCache[0].fd == (-1)))", File: "fd.c", Line: 1113)
>
> Begins to look like a plain old wild store: ain't *nothing*
Itai Zukerman <[EMAIL PROTECTED]> writes:
> After recompiling with --enable-cassert, nserting into an empty table,
> I get:
> TRAP: FailedAssertion("!((VfdCache[0].fd == (-1)))", File: "fd.c", Line: 1113)
Begins to look like a plain old wild store: ain't *nothing* should ever
write into VfdCach
>> I'm still not having any luck tracking down my SEGV. If anyone is
>> interested in debugging or even just reproducing this, I'd be happy to
>> post or E-mail you my code. It looks like shortly after calling
>> gistSplit() there's maybe a double-free() somewhere?
>
> It might help to build with
[ repost, as original message of 28-Feb seems to have gotten lost ]
I said:
> I was able to reproduce a problem as follows: run the tsearch regression
> test, then do "cluster wowidx on test_txtidx". This appears to lose
> one row:
Ahh ... it took me way too long to realize what was happening.
Itai Zukerman <[EMAIL PROTECTED]> writes:
> I'm still not having any luck tracking down my SEGV. If anyone is
> interested in debugging or even just reproducing this, I'd be happy to
> post or E-mail you my code. It looks like shortly after calling
> gistSplit() there's maybe a double-free() some
Stef Telford <[EMAIL PROTECTED]> writes:
> This would seem to be a step backwards to me though, as
> now we cant even put triggers on the system tables. Is there any
> chance of this being lifted ?
Not unless you can explain to us how it can be safe to fire arbitrary
user-defined code when t
> (gdb) p (*newtup)[0]
> $147 = {t_tid = {ip_blkid = {bi_hi = 0, bi_lo = 34}, ip_posid = 1}, t_info = 136}
> (gdb) p (*newtup)[1]
> $148 = {t_tid = {ip_blkid = {bi_hi = 65510, bi_lo = 65535}, ip_posid = 65535},
> t_info = 24575}
> (gdb) p nlen
> $149 = 2
>
> (*newtup)[1] doesn't look r
Just before the return from gistSplit() I see this:
(gdb) p (*newtup)[0]
$147 = {t_tid = {ip_blkid = {bi_hi = 0, bi_lo = 34}, ip_posid = 1}, t_info = 136}
(gdb) p (*newtup)[1]
$148 = {t_tid = {ip_blkid = {bi_hi = 65510, bi_lo = 65535}, ip_posid = 65535},
t_info = 24575}
(gdb) p nlen
$
[3rd day of trying to track down a SEGV]
In gistSplit() I see:
newtup[0] = gistFormTuple(giststate, r, v.spl_rattr, v.spl_rattrsize,
v.spl_risnull);
but v.spl_rattrsize hasn't been initialized:
(gdb) p v.spl_rattrsize[0]
$136 = -1073749368
Is this going to be a problem? Eve
Hi Stef
I had the same problem some time ago. I wanted to define a trigger
firing on CREATE TABLE (pg_class). This won't work because in most cases
system tables are not accessed using the "standard" way for processing
queries (parse -> rewrite -> plan -> execute). Therefore triggers are
not a
Joseph Shraibman wrote:
Joseph Shraibman wrote:
After further experimenting I think the problem is in psql. When I try
update mytable set firstname = 'Oné' where ukey = 12911;
It works with a latin1 database, but when I try it on a unicode database:
utfowl=# update mytable set firstname = 'Oné'
On Fri, Feb 21, 2003 at 08:39:12PM -0600, Ross J. Reedstrom wrote:
>
> Every other validly formatted TZ variable that returns GMT should be
> caught be the datetktbl check.
>
> I'll play with it this weekend, see how hard it is to make it work.
O.K., the weekend's over, And I've created two diff
Tom,
I'm happy to see your attentions turning back to the FSM. I like the
design, but I do have a few suggestions, particularly about how to
handle oversubscription of the FSM.
1. When the FSM is oversubscribed and one is trying to decide which
pages to keep, remember that page info is stored
Hi,
I could see \ref{parsetree} ,\ref{transformed} and things like that in
PostgreSQL developers guide. But I couldn't see any figures in the
document. Can anyone please let me know, are there any figures like that
and if so, where can I find them?
Thanks and regards,
Radha
-
Tom Lane wrote:
Stephen Marshall <[EMAIL PROTECTED]> writes:
2. The histogram concept is a neat idea, but I think some reorganization
of the page information might make it unnecessary. Currently the FSM
pages are sorted by BlockNumber. This was particularly useful for
adding i
According to my sent folder, this went out Monday afternoon, but I
haven't seen it yet, so I'm resending to the list only, without the
attached patch. I'll send the patch over to patches.
Any comment on the behavior, specifically, the heuristic for deciding
tzset() failed, and the proposed order
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
>Joe Conway <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Hm, I just had regression tests pass earlier this evening on RHL 8.0
>>> (also HPUX 10.20). Are you using default config, or
>>> --enable-integer-datetimes?
>
>> I'm u
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
28 matches
Mail list logo