Christopher Kings-Lynne [EMAIL PROTECTED] writes:
With the recent talk of RULE regression failures, I thought I'd bring back
up that I _always_ have a rule failure on Freebsd/alpha.
Hm, what do you get from
explain SELECT * FROM shoe_ready WHERE total_avail = 2;
in the regression
U...how do I make the regression database!? Do I have to do
installcheck instead of check?
Chris
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, 30 August 2002 2:31 PM
To: Christopher Kings-Lynne
Cc: Hackers
Subject: Re: [HACKERS] RULE regression
On Fri, 30 Aug 2002, Christopher Kings-Lynne wrote:
U...how do I make the regression database!? Do I have to do
installcheck instead of check?
yes
Database is 'regression'
g
---(end of broadcast)---
TIP 1: subscribe and unsubscribe
An aside.
In the fulltextindex code I'm trying to figure out what's breaking the
attached code segment.
Basically the data-vl_len line causes a segfault on the second time thru
the while loop. I can't figure it out. I can't write to the value, but
why? Basically with a word like 'john', it
Attached.
Chris
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, 30 August 2002 2:31 PM
To: Christopher Kings-Lynne
Cc: Hackers
Subject: Re: [HACKERS] RULE regression test failure
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
With the recent
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
struct varlena *data;
char*word = NULL;
char*cur_pos= NULL;
int cur_pos_length = 0;
data = (struct varlena *) palloc(column_length);
while(cur_pos word)
{
cur_pos_length = strlen(cur_pos);
/*
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Hm, what do you get from
explain SELECT * FROM shoe_ready WHERE total_avail = 2;
in the regression database?
[this plan]
That seems substantially the same plan as I see here. I guess
that the different output order must reflect a
That seems substantially the same plan as I see here. I guess
that the different output order must reflect a platform-specific
difference in qsort()'s treatment of equal keys.
Probably the best answer is to add ORDER BY shoename to the test
query to eliminate the platform dependency. Any
OK, I was probably a little aggressive in my pruning...BTW, this code was
not written by me...
struct varlena *data;
char*word = john;
char*cur_pos= NULL;
int cur_pos_length = 0;
data = (struct varlena *) palloc(VARHDRSZ +
I proved that you can reclaim on disk space after a DROP COLUMN with toast
tables:
test=# create table toast_test(a text, b text);
CREATE TABLE
test=# insert into toast_test values (repeat('XX', 100),
repeat('XX', 100));
INSERT 246368 1
test=# insert into toast_test
On Fri, 30 Aug 2002, Christopher Kings-Lynne wrote:
struct varlena *data;
char*word = john;
char*cur_pos= NULL;
int cur_pos_length = 0;
data = (struct varlena *) palloc(VARHDRSZ + column_length + 1);
word_length =
Please correct me if I've got this wrong, but it appears from the SRF
API, that a SRF cannot readily refer to the TupleDesc to which it is
expected to conform (i.e. the TupleDesc derived from the FROM clause of
an original SELECT statement) because that is held in the executor state
and not
Please correct me if I've got this wrong, but it appears from the SRF
API, that a SRF cannot readily refer to the TupleDesc to which it is
expected to conform (i.e. the TupleDesc derived from the FROM
clause of
an original SELECT statement) because that is held in the
executor state
and
On Thu, Aug 29, 2002 at 07:35:13PM -0400, Bruce Momjian wrote:
Andrew Sullivan wrote:
On Thu, Aug 29, 2002 at 01:27:41AM -0400, Neil Conway wrote:
Also, if anyone would like to contribute the results of doing the
benchmark on their particular system, that might provide some useful
On Thu, Aug 29, 2002 at 11:07:03PM -0400, Bruce Momjian wrote:
and that memset it faster than C MemSet. What compiler are you using?
Sorry. Should have included that.
$gcc --version
2.95.3
Is the memset() call being inlined by the compiler? You will have to
look at the assembler code
On Friday 30 August 2002 12:49 am, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is it ok if Florian and I submit the improvements to the fulltextindex
contrib during beta?
What improvements are we talking about here? FTI is sufficiently widely
depended on that I
Lamar Owen [EMAIL PROTECTED] writes:
On Friday 30 August 2002 12:49 am, Tom Lane wrote:
What improvements are we talking about here? FTI is sufficiently widely
depended on that I think it ought to follow the same quality standard
as the main backend ... viz, no new features during beta.
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
struct varlena *data;
char*word = john;
char*cur_pos= NULL;
int cur_pos_length = 0;
data = (struct varlena *) palloc(VARHDRSZ + column_length + 1);
word_length = strlen(word);
cur_pos = word[word_length - 2];
Hi,
I checked all the previous string handling errors and most of them were
already fixed by You. However there were a few left and attached patch
should fix the rest of them.
I used StringInfo only in 2 places and both of them are inside debug
ifdefs. Only performance penalty will come from
John Gray [EMAIL PROTECTED] writes:
Please correct me if I've got this wrong, but it appears from the SRF
API, that a SRF cannot readily refer to the TupleDesc to which it is
expected to conform (i.e. the TupleDesc derived from the FROM clause of
an original SELECT statement) because that is
On Friday 30 August 2002 09:29 am, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Does this mean we should be looking for a way to integrate [FTI] into the
main backend at this point? Isn't that what contrib is for?
Well, given that Chris also thinks that people should migrate to
Tom Lane wrote:
John Gray [EMAIL PROTECTED] writes:
Please correct me if I've got this wrong, but it appears from the SRF
API, that a SRF cannot readily refer to the TupleDesc to which it is
expected to conform (i.e. the TupleDesc derived from the FROM clause of
an original SELECT statement)
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Would you please retest this. I have attached my email showing a
simpler test that is less error-prone.
What did you consider less error-prone, exactly?
Neil's original test considered the case where both the value being
set and
Joe Conway [EMAIL PROTECTED] writes:
I suppose that ExecMakeTableFunctionResult could be changed to *always*
pass ReturnSetInfo, even if it's not expecting the function to return
a set. That seems even less clean; but it would work, at least in the
current implementation.
Hmmm. I hadn't
Tom Lane wrote:
I've been thinking more about this, and wondering if we should not
only make the tupdesc available but rely more heavily on it than we
do. Most of the C-coded functions do fairly substantial pushups to
construct tupdescs that are just going to duplicate what
nodeFunctionscan
Lamar Owen [EMAIL PROTECTED] writes:
On Friday 30 August 2002 09:29 am, Tom Lane wrote:
But yeah, in the long run I'd like to see one of these packages become
mainstream, just because full-text search is such a widely used feature.
Agreed. We don't really have guidelines for this process;
Tom has applied a patch to fix this.
---
Alvaro Herrera wrote:
Gordon Runkle dijo:
I'm using the current CVS (as of ~1930 EDT, 29AUG02) on RedHat's latest
beta (null). I find that I need to use the -U option when
Hello everybody,
There is an open question we need broad opinion on.
Currently pgaccess stores its own data in the database it works with.
Some people do not like that. To store it elsewhere invokes a number of
issues such as:
- where is this somewhere
- converting form all versions to the new
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
Actually, I left off trying to figure out how to pass the columndef to
ExecMakeFunctionResult in the first place.
That was hard yesterday, but it's easy today because nodeFunctionscan
isn't using ExecEvalExpr anymore --- we'd only have to
Joe Conway [EMAIL PROTECTED] writes:
On the other hand, your experience yesterday with debugging a mismatched
function declaration suggests that it's still a good idea to make the
functions build the tupdesc they think they are returning.
In a function which *can* know what the tupledec
Iavor Raytchev wrote:
Hello everybody,
There is an open question we need broad opinion on.
Currently pgaccess stores its own data in the database it works with.
Some people do not like that. To store it elsewhere invokes a number of
issues such as:
- where is this somewhere
-
I just sync'd up and am getting:
make[4]: Leaving directory `/opt/src/pgsql/src/port'
make[3]: PERL: Command not found
make[3]: *** [sql_help.h] Error 127
make[3]: Leaving directory `/opt/src/pgsql/src/bin/psql'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/opt/src/pgsql/src/bin'
On Fri, 30 Aug 2002, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
There may be more modules to consider
-- earthdistance, for instance, which has been with us for a long time.
Actually, that seems to have just disappeared completely. What the heck?
Marc, you're not physically
-Original Message-
From: Iavor Raytchev [mailto:[EMAIL PROTECTED]]
Sent: 30 August 2002 16:44
To: pgsql-hackers; pgsql-interfaces
Subject: [HACKERS] pgaccess - where to store the own data
Hello everybody,
There is an open question we need broad opinion on.
Currently
Joe Conway [EMAIL PROTECTED] writes:
I just sync'd up and am getting:
make[4]: Leaving directory `/opt/src/pgsql/src/port'
make[3]: PERL@: Command not found
Marc was overenthusiastic about removing perl support from configure.
I'll put it back.
regards, tom lane
-Original Message-
From: Joe Conway [mailto:[EMAIL PROTECTED]]
Sent: 30 August 2002 16:52
To: Iavor Raytchev
Cc: pgsql-hackers; pgsql-interfaces
Subject: Re: [HACKERS] [INTERFACES] pgaccess - where to store
the own data
Iavor Raytchev wrote:
Hello everybody,
There
Greets all,
While attempting to clean up some memory leaks, I have encountered some
difficulties. In the code for PQclear() we have the check:
if (!res)
return;
The problem arrises when the result object pointer you are passing to clear
contains not a null and not a valid result
Alvaro Herrera [EMAIL PROTECTED] writes:
On Fri, 30 Aug 2002, Tom Lane wrote:
-- earthdistance, for instance, which has been with us for a long time.
Actually, that seems to have just disappeared completely. What the heck?
Marc, you're not physically removing stuff from CVS when you move
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think the log entries should be separate: print the query text when
you start, print the duration when you're done. A little bit of
postprocessing can reassemble the two entries.
How would someone reassemble them? You would
I am seeing the same failure ... looking at it...
---
Joe Conway wrote:
I just sync'd up and am getting:
make[4]: Leaving directory `/opt/src/pgsql/src/port'
make[3]: PERL@: Command not found
make[3]: ***
OK, fixed. Marc removed the perl tests because he was removing
interfaces/perl5, but we still need it for pl/perl and psql's use of
perl for the help files.
Perhaps it can be paired down now by someone who understands the perl
builds but at this point I just put the configure.in part back,
Bruce Momjian wrote:
OK, fixed. Marc removed the perl tests because he was removing
interfaces/perl5, but we still need it for pl/perl and psql's use of
perl for the help files.
Perhaps it can be paired down now by someone who understands the perl
builds but at this point I just put the
Bruce Momjian [EMAIL PROTECTED] writes:
Perhaps it can be paired down now by someone who understands the perl
builds but at this point I just put the configure.in part back, and ran
autoconf.
I think all that ought to be done is change the description of the
--with-perl option to mention only
Done.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Perhaps it can be paired down now by someone who understands the perl
builds but at this point I just put the configure.in part back, and ran
What do people think about this. Is it so bad that the own
data is stored in the database pgaccess works with?
pgAdmin II no longer uses such tables, but to get over the problem as
best I could, I added a cleanup option to pgAdmin I that removed all
server side objects in one go.
What
Matthew T. OConnor wrote:
One thought is to use a completely separate database, but also allow it
to be stored in the current database if the user wants it too. This
also solves the case of a user that can't create a new database for his
admin tool (permissions etc...). Also, it might be
As someone else mentioned (I think), even using a separate schema is not
always an acceptable option. If you are using a packaged application
(whether commercial or open source), you usually don't want *any*
changes to the vendor provided database. Particularly with commercial
software, that
HI all,
Sorry to interrupt your busy list.
I was wondering if you could recomend a good source code db/indexer that
could be used to search through the postgresql code?
Thanks,
--
Laurette Cisneros
The Database Group
(510) 420-3137
NextBus Information Systems, Inc.
www.nextbus.com
Laurette Cisneros wrote:
HI all,
Sorry to interrupt your busy list.
I was wondering if you could recomend a good source code db/indexer that
could be used to search through the postgresql code?
I think the real pros use grep and emacs ;-)
But for us mere mortals, I find LXR very useful.
Ah. Great! I had download lxr and was starting to dig in to insatall it
and thought I would check with the pgers to see what they recommended.
Glad to see someone has done this.
Thanks,
L.
On Fri, 30 Aug 2002, Joe Conway wrote:
Laurette Cisneros wrote:
HI all,
Sorry to interrupt your
On Fri, 30 Aug 2002 11:57:17 -0700 (PDT), Laurette Cisneros
[EMAIL PROTECTED] wrote:
I was wondering if you could recomend a good source code db/indexer that
could be used to search through the postgresql code?
I use Source Navigator v5.1 http://sourceforge.net/projects/sourcenav/
Servus
Using current CVS sources (as of 1500 EDT), 'make check' fails at the
database initialization step.
This box is running RH 7.3 with all current RH updates, and has
successfully built Pg 7.2.1 and 7.2.2.
Here's how I'm configuring it (same as I'm doing under the RH Null Beta,
which works fine):
The alter_table regression test is now failing for me (RH Null).
It appears that the problem is that the backend is giving back a
different error message than expected when dropping a column from a
non-existent table:
-- try altering non-existent table, should fail
alter table foo drop column
Hi, I couldn't get any good answers off the ADMIN list, can you help me?
I haven't been able to finding information on this, or at least I
haven't known the right keywords to search for.
We are trying to make a fully contained, CD-runable version of postgres
for advocacy purposes.
The only
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
Preference of extending FunctionCallInfoData or ReturnSetInfo?
Definitely ReturnSetInfo. If we put it in FunctionCallInfoData then
that's an extra word to zero for *every* fmgr function call, not only
table functions.
Attached adds:
Tyler Mitchell wrote:
Hi, I couldn't get any good answers off the ADMIN list, can you help me?
Or at least not one that you liked, huh ;-)
You won't get a more authoritative answer than you've already gotten.
Joe
---(end of broadcast)---
TIP
Tyler Mitchell wrote:
Hi, I couldn't get any good answers off the ADMIN list, can you help me?
Or at least not one that you liked, huh ;-)
Ooops good is a relative term. I should phrase it I couldn't get any
answers that directly met my application needs :)
I know that I need to at least
On Thu, Aug 29, 2002 at 11:07:03PM -0400, Bruce Momjian wrote:
Would you please retest this. I have attached my email showing a
simpler test that is less error-prone.
Ok, here you go. Same machine as before, 2-way UltraSPARC-II @400
MHz, 2.5 G, gcc 2.95.3, Solaris 7. This gcc compiles 32
On Fri, Aug 30, 2002 at 02:08:59PM -0700, Tyler Mitchell wrote:
I know that I need to at least get some more understanding on the
process
that takes place.
The problem is that PostgreSQL doesn't have a read only mode. So
you can't really do it this way.
Okay, that answers one of my
On Fri, 2002-08-30 at 16:34, Tyler Mitchell wrote:
On Fri, Aug 30, 2002 at 02:08:59PM -0700, Tyler Mitchell wrote:
I know that I need to at least get some more understanding on the
process
that takes place.
The problem is that PostgreSQL doesn't have a read only mode. So
you can't
One more idea, is it possible to fake a read-write file system. I.e.
supply the files that postgresql will be looking for? (I know it's a
stretch, but hey, this IS the hackers list) :)
One of the tricks I use for diskless systems is to mount a ramdrive in a
union mount with a read only nfs
On Fri, 30 Aug 2002, Laurette Cisneros wrote:
HI all,
Sorry to interrupt your busy list.
I was wondering if you could recomend a good source code db/indexer that
could be used to search through the postgresql code?
I think I must be one of those 'old school' types. I use
find
Andrew Sullivan wrote:
On Thu, Aug 29, 2002 at 01:27:41AM -0400, Neil Conway wrote:
Also, if anyone would like to contribute the results of doing the
benchmark on their particular system, that might provide some useful
additional data points.
Linux 2.4.18 (preempt) gcc
[This is an email copy of a Usenet post to comp.databases.postgresql.hackers]
I just checked out another CVS snapshot onto a RH 7.2 box, and 'make
check' can successfully do the initdb.
I updated the source on the RH 7.3 box, and still get the initdb failure.
I updated the source on the RH
I just checked out another CVS snapshot onto a RH 7.2 box, and 'make
check' can successfully do the initdb.
I updated the source on the RH 7.3 box, and still get the initdb failure.
I updated the source on the RH Null box, and 'make check' can
successfully do the initdb.
Anyone else having
Joe Conway [EMAIL PROTECTED] writes:
Attached adds:
+ TupleDesc queryDesc; /* descriptor for planned query */
to ReturnSetInfo, and populates ReturnSetInfo for every function call to
ExecMakeTableFunctionResult, not just when fn_retset.
I thought expectedDesc was a more sensible choice
Gordon Runkle [EMAIL PROTECTED] writes:
Running with noclean mode on. Mistakes will not be cleaned up.
/home/gar/src/pgsql/src/test/regress/./tmp_check/install//opt/postgresql/bin/pg_encoding:
relocation error:
Thanks, Tom,
My /etc/ld.so.conf didn't have /opt/postgresql/lib in it, yet when I
renamed /opt/postgresql (which was v7.2.2) to something else, the initdb
succeeded. I'm not sure why it went looking up there...
Thanks again,
Gordon.
--
Far and away the best prize that life has to offer
is
Gordon Runkle [EMAIL PROTECTED] writes:
The alter_table regression test is now failing for me (RH Null).
It appears that the problem is that the backend is giving back a
different error message than expected when dropping a column from a
non-existent table:
-- try altering non-existent
Looks good now, all three environments (RH 7.2, RH 7.3, RH Null).
G.
On Fri, 2002-08-30 at 20:57, Tom Lane wrote:
Hmm, I don't get that here. In CVS tip the regression tests pass,
and a manual trial gives:
test73=# alter table foo drop column bar;
ERROR: Relation foo does not exist
I know this one has been a pain, but I'm getting regression failures on:
abstime ... FAILED
tinterval... FAILED
test horology ... FAILED
under RedHat 7.3 and RedHat Null Beta.
Thanks,
Gordon.
--
Far and away the best prize that life has to offer
I have moved my main computer to my new house. The DNS is still being
updated, but the new IP address is:
207.106.42.251
Vince, would you update the developer's page and change
'candle.pha.pa.us' to this fixed IP address. It may take a few days for
the IP to completely propogate.
--
Gordon Runkle wrote:
I know this one has been a pain, but I'm getting regression failures on:
abstime ... FAILED
tinterval... FAILED
test horology ... FAILED
under RedHat 7.3 and RedHat Null Beta.
That's due to a glibc change and is
On Fri, 2002-08-30 at 21:45, Joe Conway wrote:
That's due to a glibc change and is expected, if not desired. Complain
to Red Hat. For more info, see previous threads on HACKERS, notably this
one:
http://archives.postgresql.org/pgsql-hackers/2002-05/msg00740.php
Yeah, I remember that.
on RH 7.2, 7.3, and Null Beta.
Here's the important part of the diff of expected () and results ():
6a7
ERROR: Function iso8859_1_to_utf8 does not exist
11c12
ERROR: conversion name myconv already exists
---
ERROR: Function iso8859_1_to_utf8 does not exist
15a17
ERROR: Function
Gordon Runkle wrote:
On Fri, 2002-08-30 at 21:45, Joe Conway wrote:
That's due to a glibc change and is expected, if not desired. Complain
to Red Hat. For more info, see previous threads on HACKERS, notably this
one:
http://archives.postgresql.org/pgsql-hackers/2002-05/msg00740.php
Tom Lane has applied this patch and merged it into our code. Thanks.
---
David Van Wie wrote:
On Thu, 22 Aug 2002, Tom Lane wrote:
I believe our intention has been to modify the backend to offer that
behavior (with
77 matches
Mail list logo
