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
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
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
> 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
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
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 t
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
"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
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 tha
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 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
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
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
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
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
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 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
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 onl
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
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'
make[
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
> -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:
> 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,
>
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
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
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?
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
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
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
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
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
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.
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
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 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
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
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
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
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
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 ba
> -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
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
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
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
>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
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
>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, 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
> 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, 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
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 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
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
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
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-existen
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
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 e
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 i
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
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
75 matches
Mail list logo
