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
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.p
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 i
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.
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 e
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.
--
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
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 exis
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-existen
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:
> 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:
>/home/gar/src/pgsql/src/test/regress/./tmp_check/install//opt/postgresql/bi
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
[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 Nu
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 issu
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
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
> 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 on
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
>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
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.
Is there a way to make a RAMDI
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 3
>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
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)---
TI
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 a
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 prob
> -Original Message-
> From: Matthew T. OConnor [mailto:[EMAIL PROTECTED]]
> Sent: 30 August 2002 18:59
> To: Dave Page
> Cc: Iavor Raytchev; pgsql-hackers; pgsql-interfaces
> Subject: Re: [HACKERS] pgaccess - where to store the own data
>
>
> > > What do people think about this. Is i
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 ba
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):
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
Ma
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 interrup
Grep just to find things.
Doxygen to see what is going on in exquisite detail.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get
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 us
Laurette Cisneros dijo:
Hi,
> I was wondering if you could recomend a good source code db/indexer that
> could be used to search through the postgresql code?
Some people here use something called glimpse AFAIR. I don't even know
it.
--
Alvaro Herrera ()
Officer Krupke, what are we to do?
Ge
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
--
> 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
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
> > 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.
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
> >
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
wade <[EMAIL PROTECTED]> writes:
> The problem arrises when the result object pointer you are passing to clear
> contains not a null and not a valid result object address, but a junk pointer.
> PQclear() seg faults when the address is outside of the data segment.
> (libpq bug?)
No, that's a bug
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 obj
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 pu
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, an
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
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]: *** [sql_he
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?
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 y
> -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,
>
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'
make[
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
>
> -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.
>
> Cu
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 tuple
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 p
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 onl
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:
> 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
> nodeFunction
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
Joe Conway <[EMAIL PROTECTED]> writes:
> John Gray wrote:
>> Does this sound completely crazy?
> Not crazy at all. I asked the same question a few days ago:
> http://archives.postgresql.org/pgsql-hackers/2002-08/msg01914.php
I've been thinking more about this, and wondering if we should not
only
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
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 pro
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 s
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 bein
John Gray wrote:
> 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 exec
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 migrat
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 tha
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
"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
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 b
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 t
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 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 som
> 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
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 copied
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_len
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 values
75 matches
Mail list logo
