Attached patch fixes following problem: createlang.sh expects one handler
for each PL. If a handler function for a new PL is found in pg_languages,
PL won't be created. So you need to have plperl_call_handler and
plperlu_call_handler. This patch just does that.
-alex
Index: src/bin/scripts/crea
Finally figuring that enough is enough, I've been spending the past few
days working on the list archives ...
I've reformatted, so far, the following lists into a cleaner format:
pgsql-hackers
pgsql-sql
pgsql-bugs
pgsql-general
pgadmin-hackers
pga
> >From that error below it looks to me that you will need to recompile your
> kernel (or whatever) to add support for more shared memory and more shared
> semaphores.
My point is 7.1 or earlier behaves different from current. 7.1 or
earlier's postmaster won't start if there is not enough shared
>From that error below it looks to me that you will need to recompile your
kernel (or whatever) to add support for more shared memory and more shared
semaphores.
Try this URL:
http://www.ca.postgresql.org/devel-corner/docs/admin/kernel-resources.html
Chris
> -Original Message-
> From:
I have a fatal error message while connecting more than 32 users using
current:
Aug 29 11:25:18 srapc1474 postgres[12189]: [1] FATAL 1:
ProcGetNewSemIdAndNum: cannot allocate a free semaphore
rather than a more informative message:
Sorry, too many clients already
Does an
At 11:55 AM 28-08-2001 +0200, Karel Zak wrote:
> What implement base64 PostgreSQL datetype that use externaly base64 and
>internaly same things as bytea. It prevent FE and parser problems with
Another point:
I have no problems with base64[1]. However I was thinking that it might be
far easier fo
At 11:55 AM 28-08-2001 +0200, Karel Zak wrote:
>
> What implement base64 PostgreSQL datetype that use externaly base64 and
>internaly same things as bytea. It prevent FE and parser problems with
>"bad" chars and internaly for data storage save less space than text
>with base64. Of course it doesn'
* Peter Eisentraut <[EMAIL PROTECTED]> [010828 09:59]:
> Larry Rosenman writes:
>
> > in testing CVS tip(sort of), I found that you need -lcurses with
> > -ledit on NetBSD 1.5.1.
> >
> > _tputs in undefined otherwise.
>
> Fixed in current.
of NetBSD?
LER
>
> --
> Peter Eisentraut [EMAIL P
[EMAIL PROTECTED] (Bruno Mattarollo) wrote in message
news:<[EMAIL PROTECTED]>...
> Hello
>
> Thanks Peter! That solved the problem and I could get postgresql 7.1.3 to
> compile. Actually it works :) It seems that for my needs now, this GCC is
> enough... At least I could compile postgresql, pyt
>
> Ya, lets go with the 10th of Sept, which is a Monday, start of the week
> and all that, everyone has had a chance to relax once "the kids" are back
> in school and all that :)
>
Yes. I need to resolve all outstanding patches before we go beta and I
can use the extra time too. Can I sugges
Tom, I am sure it is an oversight. Can you fix it?
> Today I did something I usually do about once per release cycle: try to
> build the system with HP's vendor cc, rather than gcc which I prefer.
> This usually turns up some portability issues, and indeed I found some.
> One that I'm not enti
Aiiye. I'm sending a _large_ (60k) patch to add 'select * from cursor foo'
tonight. I'm hoping that it could possibly get included...
-alex
On Mon, 27 Aug 2001, Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > Do we want ADD PRIMARY KEY?
>
> If you can get it done in
Larry Rosenman writes:
> in testing CVS tip(sort of), I found that you need -lcurses with
> -ledit on NetBSD 1.5.1.
>
> _tputs in undefined otherwise.
Fixed in current.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)--
Bruno Mattarollo writes:
> Thanks Peter! That solved the problem and I could get postgresql 7.1.3 to
> compile.
Okay, the fix has been checked in for the next release.
> Actually it works :) It seems that for my needs now, this GCC is
> enough...
I'm referring to the note at http://freeware.sg
Tom Lane writes:
> I believe that ipcclean is no longer needed for preparing to start a new
> postmaster. It might possibly be useful if you wanted to clean up after
> a dead postmaster that you did *not* intend to restart.
>
> However, given the lack of portability and lack of robustness of the
Hello
Thanks Peter! That solved the problem and I could get postgresql 7.1.3 to
compile. Actually it works :) It seems that for my needs now, this GCC is
enough... At least I could compile postgresql, python, postfix and xemacs
and some other GNU software ... :)
Thanks again!
/B
On Tue, 28 Aug
> On Tue, 28 Aug 2001, Reinoud van Leeuwen wrote:
>
>> Can somebody explain to me:
>>
>> > radius=# explain select count (radiuspk) from radius ;
>> > NOTICE: QUERY PLAN:
>> >
>> > Aggregate (cost=12839.79..12839.79 rows=1 width=8)
>> > -> Seq Scan on radius (cost=0.00..11843.43 rows=39854
If full SQL92 implementation of INTERVAL would be a welcome addition,
could it be added as a TODO item? I would like to work on it, since I
want to use some features that are not currently supported.
SQL92 INTERVAL data type (also SQL99, I think):
::= INTERVAL {{ TO } |
On Tue, 28 Aug 2001, Reinoud van Leeuwen wrote:
> Can somebody explain to me:
>
> > radius=# explain select count (radiuspk) from radius ;
> > NOTICE: QUERY PLAN:
> >
> > Aggregate (cost=12839.79..12839.79 rows=1 width=8)
> > -> Seq Scan on radius (cost=0.00..11843.43 rows=398543 width=8)
Reinoud van Leeuwen writes:
> > radius=# select count (radiuspk) from radius ;
> > count
> >
> > 398543
> > (1 row)
>
> This query takes about 3 seconds. But the query plan *already* knows the
> number of rows ("rows=398543").
This is only an estimate which is only updated by VACUU
Can somebody explain to me:
> radius=# explain select count (radiuspk) from radius ;
> NOTICE: QUERY PLAN:
>
> Aggregate (cost=12839.79..12839.79 rows=1 width=8)
> -> Seq Scan on radius (cost=0.00..11843.43 rows=398543 width=8)
>
> EXPLAIN
This query answers me *instantly* after hitting r
Vince Vielhaber wrote:
> Everybody keeps saying bugzilla. What EXACTLY will bugzilla do for us
> that would make me want to learn it and install it? BTW, the current
> wheel was invented a year ago 'cuze nothing really fit what we needed.
I believe the greatest advantage for the PostgreSQL is
Tom Lane wrote:
> it does seem like a lot of people
> like Bugzilla. Might be worth at least a cursory look.
We do use Bugzilla and I believe is a very good tool, which should fit
nicely with the open development style of PostgreSQL community. New
version is due in a few weeks and it's been alr
On Tue, 28 Aug 2001, Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > The fundamental problem with bug tracking has been that the available
> > tools do not fit with our obviously successful mailing-list centered
> > development process. I certainly would consider it a distractio
On Tue, Aug 28, 2001 at 11:07:32AM +0200, Joerg Hessdoerfer wrote:
> Hi!
>
> Please find attached some very simple encoders/decoders for bytea and base64.
> Bytea encoder is very picky about what it leaves unescaped - basically the
> base64
> char set ;-)
>
> Since this seems to be a very poorl
Bruno Mattarollo writes:
> I am trying to get 7.1.3 to compile on IRIX 6.5.13 using GCC 3.0.1 ... I
> always end up having this error:
>
> gcc -Wall -Wmissing-prototypes -Wmissing-declarations
> -I../../../../src/include -U_NO_XOPEN4 -c -o s_lock.o s_lock.c s_lock.c:
> In function `s_lock': s_loc
Hi!
Please find attached some very simple encoders/decoders for bytea and base64.
Bytea encoder is very picky about what it leaves unescaped - basically the
base64
char set ;-)
Since this seems to be a very poorly documented but much asked-for thing, I
thought
you would maybe like to add this
Hello
I am trying to get 7.1.3 to compile on IRIX 6.5.13 using GCC 3.0.1 ... I
always end up having this error:
gcc -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../../src/include -U_NO_XOPEN4 -c -o s_lock.o s_lock.c s_lock.c:
In function `s_lock': s_lock.c:134: warning: passing arg
28 matches
Mail list logo
