---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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 using
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
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
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,
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
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
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
[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?
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
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é'
(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 right,
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 the
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()
[ 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. The
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
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 VfdCache[0].fd.
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* should ever
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 code *blush*.
* 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
* 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
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 columns
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 day :)
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
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
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
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
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 every
28 matches
Mail list logo
