Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
[snap]
> How do I get this to work?
>
> Chris
I think i did this:
CREATE FUNCTION "plpgsql_call_handler" () RETURNS opaque AS
'/usr/local/pgsql/lib/plpgsql.so', 'plpgsql_call_handler' LANGUAGE 'C';
CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' H
> On Thu, 2002-05-16 at 13:47, Joerg Hessdoerfer wrote:
> > So, my route would be to get it to run *somehow* without paying
> > attention to speed and not to change much of the existing code,
> > THEN see how we could get rid of fork() on windows.
>
What is the biggest problem here?
The
Joerg Hessdoerfer <[EMAIL PROTECTED]> wrote:
[snip]
> The problem is not the fork() call itself, this has been done (MinGW
> and cygwin I know of, possibly others) but the speed of fork() on
> windows, it's creepingly slow (due to usermode copy, I assume ;-).
>
> IPC needs to be done, I'm j
Tom Lane <[EMAIL PROTECTED]> wrote:
[snip]
>
> Exactly how much work (and code bulk) would we be taking on? I've
> never looked at how big the timezone databases are...
>
Some answers on database sizes, if this is any help...
I did "du -sh /usr/share/zoneinfo/" on them all.
OpenBSD
Hello, i noticed that win32 native stopped working/compiling after the SSL merge.
So i took the opportunity to fix some stuff:
1. Made the thing compile (typos & needed definitions) with the new pqsecure_* stuff,
and added fe-secure.c to the win32.mak makefile.
2. Fixed some MULTIBYTE compil
I heard people asking for listen/notify support in the jdbc driver from different
pgsql lists. I don't know what the status is about that, but here's one solution.
I did this quick hack for our own purposes, maybe someone would like to pick this code
up and use it as we do...
This code is not
... And maybe i should attach the code aswell :)
I'm not subscribed to pgsql-jdbc or pgsql-announce, so please CC me if your
responding...
Magnus
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Programmer/Networker [|] Magnus Naeslund
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Hello,
I did a vacuum from within a function, and it went sig11 on me.
Is it illegal to do that?
The function:
drop function xorder1_cleanup();
create function xorder1_cleanup() RETURNS integer AS '
declare
x record;
c integer;
begin
c:=0;
FOR x IN SELECT order_id,count(*) as cnt FROM
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Magnus Naeslund(f) dijo:
>
>> Hello,
>>
>> I did a vacuum from within a function, and it went sig11 on me.
>> Is it illegal to do that?
>
> Huh... what version is this? In current sources, VACUUM cannot be
Was there a workaround for the errors in time handling for rh7.3 dist?
I get there regression failures:
abstime ... FAILED
tinterval... FAILED
test horology ... FAILED
I remember the discussion about old dates, but not if there was any fix for it...
Joe Conway <[EMAIL PROTECTED]> wrote:
> Magnus Naeslund(f) wrote:
>> Was there a workaround for the errors in time handling for rh7.3
>> dist?
>>
>> I get there regression failures:
>> abstime ... FAILED
>> tin
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> The change was to use localtime() rather than mktime() in the code.
> There is no workaround available for 7.2.X, and I don't see that
> anyone backpatched it to 7.2 CVS. However, we are considering a
> 7.2.3 and a backpatch of that fix may be worthwh
Hello, i've got this query that's really slow...
Figure this:
testdb=> select now() ; select gid from bs where gid not in ( select x
from z2test ); select now();
now
---
2002-10-09 22:37:21.234627+02
(1 row)
gid
--
(524 rows)
Joe Conway <[EMAIL PROTECTED]> wrote:
> "IN (subselect)" is notoriously slow (in fact it is an FAQ). Can you
> rewrite this as:
>
...
Stephan Szabo <[EMAIL PROTECTED]> wrote:
> Per FAQ suggestion, try something like
...
Thanks alot, below are the results on your suggestions, quite an
dramatic
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> We already have a TODO item:
>
> * Allow Subplans to use efficient joins(hash, merge) with upper
> variable
Cool.
One thing to note here is that the JOIN query that Joe suggested is both
faster than the subselect thing (no suprise) but also don't care
Is there i faq item or maybe some other way that we can tell users
that --disable-rpath should be used when checking regressiontests if you
have an install already on the box?
The rpath defaults to the installdir even in the temporary install that
is made when doing "gmake check", and that confuses
Robert Treat <[EMAIL PROTECTED]> wrote:
> I noticed that the supported platforms listed 7.2 for linux alpha but
> with yesterdays date. I figured it was just a typo, but thought I
> would try to compile myself just to be sure, but I received 4
> failures: horology,geometry,opr_sanity, and misc
>
>
On an rh6.2, "Linux gsX 2.4.19-pre6 #4 Thu Apr 11 07:17:39 CEST 2002
alpha unknown" (ev56 ruffian) i get this failure.
Should ./configure && gmake && gmake check be the only things
i need to do?
== creating database "regression" ==
/home/mag/d/postgresql/postgresq
Linux alpha.
An Redhat 6.2, "Linux gsX 2.4.19-pre6 #4 Thu Apr 11 07:17:39 CEST 2002
alpha unknown" (ev56 ruffian).
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
./configure \
--prefix=/usr/local/pgsql-7.3b3 \
--with-maxbackends=512 \
--with-tcl \
--without-tk
If it matters, i re-ran the regression tests on psql 7.3b5, and it
worked flawlessly, all 89 tests passed.
I didn't install, but it passed the last time (b3).
System:
Redhat Linux 6.2, Alpha EV56, handupgraded to kernel 2.4.19-pre6aa1.
Options used:
./configure \
--disable-rpath \
--prefix=/
Tom Lane <[EMAIL PROTECTED]> wrote:
[snip]
>
>> Note that we have *zero* reports for any flavor of NetBSD and
>> OpenBSD.
>
> Maybe they're both dead platforms? ;-)
>
Well, OpenBSD isn't dead :)
But i have problems compiling 7.3b5 on it (OpenBSD 3.1 i386).
I figured i should give it a go, since n
Magnus Naeslund(f) <[EMAIL PROTECTED]> wrote:
>
> Well, OpenBSD isn't dead :)
> But i have problems compiling 7.3b5 on it (OpenBSD 3.1 i386).
> I figured i should give it a go, since nobody else did, but i get many
> regression failures.
>
OK OK, before anyone rubs
Tom Lane <[EMAIL PROTECTED]> wrote:
> Too low processes-per-user limit, likely.
Yes, ofcourse...
This is what happens when you're in a hurry and tries to make everything
happen at the same time :)
Now it all passes:
OpenBSD 3.1 i386
./configure \
--with-perl\
--enable-odbc
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Ports list updated:
>
> http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-
> platforms.html
>
> Also, I assume the "(f)" is part of your name, right?
>
Cool.
No the (f) part is really a mail account thing that (I/we)'ve
traditionally had.
If i
Mysql is planning on making this work:
SELECT id, @a:=COUNT(*), SUM(sum_col)/@a FROM table_name GROUP BY id.
Do we have anything like it (After a discussion with Tom i figure no).
User variables is nice, especially in these kind of queries.
Nice would be to be able to use them as in C (almost e
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
>> Mysql is planning on making this work:
>>
>> SELECT id, @a:=COUNT(*), SUM(sum_col)/@a FROM table_name GROUP BY
>> id.
>>
>> Do we have anything like it (After a discussion with Tom i figure
>> no). User variables is nice, especially in these ki
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> Are you sure that postgres evaluates that subselect more than once?
> It looks to me like it returns a constant result for every row and
> hence it will be evaluated once per statement, not once per row. I'm
> no expert tho. Can someone answer t
Stephan Szabo <[EMAIL PROTECTED]> wrote:
>
> If you use a scalar subquery, yes, but I think a subselect in from
> would help, maybe something like (if you want the total count)
>
> select table_name.id, sum(sum_col)||'/'||t2.count from table_name,
> (select count(*) as count from table_name) as t2
Stephan Szabo <[EMAIL PROTECTED]> wrote:
> On Tue, 3 Dec 2002, Magnus Naeslund(f) wrote:
>
>> Now convert this query so that it only evaluates the date_part thing
>> ONCE:
>
> That's not a good idea as long as t.stamp varies from row to row. ;)
> Perhaps o
Hannu Krosing <[EMAIL PROTECTED]> wrote:
> Magnus Naeslund(f) kirjutas T, 03.12.2002 kell 03:18:
>> It looks like it (7.2.x):
>>
>> # time psql genline -c "select id from " > /dev/null
>> real0m0.694s
>> user0m0.147s
>>
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Magnus Naeslund(f) wrote:
>>> select id, sum(sum_col)||'/'||count(*) from table_name
>>> group by id;
>>>
>>> or
>>>
>>> select table_name.id, sum(sum_col)||'/'||t2.count
I'm evaluating tsearch contrib module, and i get a backend crash when
i'm about to use a tsearch function.
When i issue
update things set nidx=txt2txtidx(productname),
didx=txt2txtidx(longdescription);
The backend dies in a segfault.
The system is redhat 7.3 dual athlon w/ 1GB memory.
Postgresql
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Magnus Naeslund(f)" <[EMAIL PROTECTED]> writes:
>> The backend dies in a segfault.
>
>> Backtrace:
>
>> #0 0x02d1 in ?? ()
>> #1 0x401faf48 in ?? ()
>> #2 0x401fb5e6 in ?? ()
>> #3 0
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Be sure to eliminate the possibility that you're loading the wrong
> version of the .so (ie, loading a 7.2 tsearch.so into 7.3). People
> get bit by that quite frequently right after an upgrade ...
>
Well, this is a clean install, so that isn't a problem.
More info, the gdb> sharedlibrary loaded some more symbols:
(gdb) bt
#0 0x02d1 in ?? ()
#1 0x401faf48 in parsetext (prs=0xbfffea60, buf=0x4277eb3c "Can - Live
1971-77", buflen=18) at txtidx.c:366
#2 0x401fb5e6 in txt2txtidx (fcinfo=0xbfffeaf0) at txtidx.c:487
#3 0x080ec45c in ExecMakeFunct
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> Does it crashed?
> # select txt2txtidx('Can - Live 1971-77');
>
>
> Line txtidx.c:366 :
> lemm = lemmatize(token, &lenlemm, type);
>
> lemmatize() is defined in morph.c. Did you use another modules for
> postgresql?
>
> It seems to me that we see a name c
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> Pls, send backtrace... :)
>
I already have, twice.
Magnus
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Some more (useless) info.
objdump -x /lib/*.so /usr/lib/*.so /lib/i686/*.so /usr/kerberos/lib/*.so
/usr/local/pgsql/bin/* /usr/local/pgsql/lib/*.so | grep lemmatize
reviels only one lemmatize symbol.
The offending address 0x02d1 is not mapped anywhere in the address
space according to /proc/
Oleg Bartunov <[EMAIL PROTECTED]> wrote:
>
> Please, tell us postgresql version. Did you reinstall tsearch after
> upgrading ? Test-suite (data, sql) demonstrated the problem would be
> nice.
>
pgsql 7.3, about 700mb text database with product descriptions.
I'm working on isolation the behavior, t
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
>> I'll reinstall tsearch and try again soon.
>> Is it necesary to install OpenFTS contrib aswell, or do i get away
>> with only installing tsearch?
>> Now i do both...
>
> Can you give us the compressed text? I can try it on my installation
> and
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
>
> Works on FreeBSD/Alpha for me. Maybe you've got some weirdness with
> bad RAM chips or something?
>
> Chris
Could be, but it only shows when i do this, and the server has been up
for several months.
If everything else failes, i'll run memtest
Ok, I nailed the bug, but i'm not sure what the correct fix is.
Attached tsearch_morph.diff that remedies this problem by avoiding it.
Also there's a debug aid patch if someone would like to know how i
finally found it out :)
There problem in the lemmatize() function is that GETDICT(...) returned
Oleg Bartunov <[EMAIL PROTECTED]> wrote:
> Magnus,
>
> what is an output of 'make installcheck' ?
As i said, it segfaults:
[root@fet1b tsearch]# gmake installcheck
gmake -C ../../src/test/regress pg_regress
gmake[1]: Entering directory `/usr/src/postgresql-7.3/src/test/regress'
gmake[1]: `pg_re
Oleg Bartunov <[EMAIL PROTECTED]> wrote:
> Magnus, we need backtrace from 'make installcheck'
>
As you wish...
This is a bt taken from a core file this time (the other ones were from
attached processes).
The whole thing has been recompiled with no additional compiler flags
(i.e. removed -march=ath
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
>
> Sorry, I have no any idea. Just only full reinstall (with initdb
> and rm -rf /usr/local/pgsql) postgresql...
> Can you give me login on you computer for a several hours?
>
The thing is that when i ran the thing breakpointing on parsetext() at
the
Oleg Bartunov <[EMAIL PROTECTED]> wrote:
>
> So, the problem may be in rh 7.3 ?
>
Might be, i'm debugging it now, and i can see that the dicts[] array in
morph.c is beeing overwritten with junk.
I can trigger it with this query:
select txt2txtidx('Can - Live 1971-77');
Is there any good way of
Yes i found this bug earlier.
There is a patch for it in the mail archives.
Magnus
Argo Priivits <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a problem with contrib/tsearch module.
>
> Simple select txt2txtidx('2-3') causes psql to crash with error:
>
> server closed the connection unexpectedly
No :)
Magnus
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
I have a problem...
We're using cursors to be able to fetch X tuples from the server.
If we would take 'em all our app would blow up because of memory
constraints.
What i would like to is something like this:
mag=# create table test (id serial unique primary key, txt text);
mag=# insert into test(
I forgot to reply to the list aswell...
Magnus
- Original Message -
From: "Magnus Naeslund(f)" <[EMAIL PROTECTED]>
To: "Jeroen T. Vermeulen" <[EMAIL PROTECTED]>
Sent: Tuesday, January 07, 2003 3:32 PM
Subject: Re: [HACKERS] Error using cursors/fetch and
Redhat 6.2
Linux gserver1 2.4.19-pre6 #4 Thu Apr 11 07:17:39 CEST 2002 alpha
unknown
All 79 tests passed.
Magnus
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
How does 7.1 work now with the vacuum and all?
Does it go for indexes by default, even when i haven't run a vacuum at all?
Does vacuum lock up postgres? It says the analyze part shouldn't, but how's
that for all of the vacuum?
An 7.0.3 db we have here we are forced to run vacuum every hour to ge
Where do get a listing of what PQftype() can return to me?
(that is what type the field/col has, need a list of Oid's i believe)
Magnus
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Programmer/Networker [|] Magnus Naeslund
PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=
From: "Tom Lane" <[EMAIL PROTECTED]>
> "Magnus Naeslund\(f\)" <[EMAIL PROTECTED]> writes:
> > Where do get a listing of what PQftype() can return to me?
>
> select oid, typname from pg_type
>
> regards, tom lane
Does these change often?
Or c
From: "Tom Lane" <[EMAIL PROTECTED]>
[snip]
>
> The system type OIDs are stable. User-defined types would probably have
> a new OID after a dump and reload.
>
> > Or could i do like the ODBC driver, autogenerate a .h out of that table.
>
> I would not recommend relying on compiled-in OID knowledg
I have a table:
create table forsamling (
id SERIAL,
for_id int4 unique not null,
kund_flag int8 not null default 1,
online smallint default 0,
klarsmallint default 0,
);
create index forsamling_idx on forsa
I have a cronjob that does a vacuumdb -a -z every night.
When i came to work this morning i saw a lot of postgres processes hanging
on wait.
The last thing i see before it hangs is this:
-
NOTICE: --Relation pg_toast_1216--
NOTICE: Pa
One day i found these in my logs, and the vacuum process hung, effectively
locking everybody out of some tables...
Version 7.1.2
VACUUM ANALYZE
NOTICE: RegisterSharedInvalid: SI buffer overflow
NOTICE: InvalidateSharedInvalid: cache state reset
It was sleeping in semop().
Any ideas, or fixes
As usual i didn't cc the list :)
Magnus
- Original Message -
From: "Magnus Naeslund(f)" <[EMAIL PROTECTED]>
To: "Tom Lane" <[EMAIL PROTECTED]>
Sent: Friday, August 17, 2001 6:55 PM
Subject: Re: [PATCHES] Re: [HACKERS] Re: WIN32 errno patch
Hello, i just reviewed the win32 errno patch and i saw that maybe i didn't
really played it totally safe in my last suggestion, the system table might
pick up the msg but not the netmsg.dll, so better try both.
I also added a hex printout of the "errno" appended to all messages, that's
nicer.
If
From: "Ross J. Reedstrom" <[EMAIL PROTECTED]>
> On Tue, Nov 28, 2000 at 05:19:45PM +0100, Zeugswetter Andreas SB wrote:
> > > I guess it depends on what you're using it for -- disk space
> > > is cheap and
> > > abundant anymore, I can see some advantages of having it
> > > computed only once
>
I don't have the same luck, sorry to say!
I am running Mandrake linux with OpenWall patched 2.2.17 kernel, dual p3
550Mhz, 1gb memory.
It's a really busy webserver that constantly is running with 10 in load.
Sometime it spikes to ~40-50 in load (the most we had was 114(!)).
I am running postgresq
From: "Nathan Myers" <[EMAIL PROTECTED]>
> On Thu, Nov 30, 2000 at 07:02:01PM -0400, The Hermit Hacker wrote:
> >
[snip]
> The logging in 7.1 protects transactions against many sources of
> database crash, but not necessarily against OS crash, and certainly
> not against power failure. (You might
From: "Ryan Kirkpatrick" <[EMAIL PROTECTED]>
> On Sat, 16 Dec 2000, Bruce Momjian wrote:
>
> > Here is the list of features in 7.1.
>
> One thing that I think ought to be added is that with 7.1,
> PostgreSQL will compile out of the box (i.e. without any extra patches)
> for Linux/Alpha.
What pa
I just wanted to check if this has been fixed in any recent v8.1.x
release, since I'm using v8.1.0 now.
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x08152448 in qual_is_pushdown_safe ()
(gdb) bt
#0 0x08152448 in qual_is_pushdown_safe ()
#1 0x08151e47 in set_subquery_pathlis
Tom Lane wrote:
> "Magnus Naeslund(f)" <[EMAIL PROTECTED]> writes:
>> SELECT DISTINCT
>> *
>> FROM
>> (
>> SELECT
>> vtgm.snicker_id
>> FROM snicker_group_mapping vtgm
>> WHERE exists
>>
66 matches
Mail list logo
