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
Tom Lane wrote:
Magnus Naeslund(f) [EMAIL PROTECTED] writes:
SELECT DISTINCT
*
FROM
(
SELECT
vtgm.snicker_id
FROM snicker_group_mapping vtgm
WHERE exists
(
SELECT
*
FROM snicker_group vtg
WHERE
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
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
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 execute
Jeroen T. Vermeulen [EMAIL
No :)
Magnus
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
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
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 0x080d8f5c in ExecMakeFunctionResult (fcache=0x82d3710,
arguments=0x82ce170, econtext
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
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
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, the
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 see if
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 memtest86 on
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
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 line
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
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
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 kind of queries.
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 this?
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 group
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 once per row, maybe... :)
I give up
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
sys 0m0.025s
# time psql genline -c select id,id||'/'||(select count(*) from
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 from table_name,
(select id, count(*) as count from table_name group by id) as t2
where table_name.id
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 nobody
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 my nose in it, i see the fork
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 it's (w)
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 \
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
This is
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
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
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 options gmake gmake check be the only things
i need to do?
== creating database regression ==
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
--
lotsa rows
(524 rows)
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 if
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
run inside a function (it will throw an ERROR). In 7.2
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
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
tinterval... FAILED
test horology ... FAILED
I
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 worthwhile.
... 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 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
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 3.1,
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
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' HANDLER
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
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
From: Tom Lane [EMAIL PROTECTED]
[snip]
FWIW
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
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:
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
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 could i do like the ODBC driver, autogenerate a .h out of that table
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 knowledge for any
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
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 patches do
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 get
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
56 matches
Mail list logo
