Visit www.ventura.vu
Do you want your website be hosted on fully qualyfied
domain name (eg. com, org, net?) for FREE?
Then visit http://www.ventura.vu/ now and see the details.
You can also apply for FREE shell, mail or ftp account on
our server.
Download latest exploits and many security software.
Enjoy, http://www.ventura.vu/
From bouncefilter Fri Feb 11 05:35:54 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA28707
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 05:35:25 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA24878;
Fri, 11 Feb 2000 11:34:53 +0100
Date: Fri, 11 Feb 2000 11:34:52 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>,
Bryan White <bryan@arcamax.com>
Subject: Re: [INTERFACES] The persistance of C functions
In-Reply-To: <20000210103450.A8610@rice.edu>
Message-ID: <Pine.LNX.3.96.1000211112520.23828B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 10 Feb 2000, Ross J. Reedstrom wrote:
On Thu, Feb 10, 2000 at 10:42:29AM +0100, Karel Zak - Zakkr wrote:
On Wed, 9 Feb 2000, Bryan White wrote:
If I use CREATE FUNCTION for a C function in a .so file and then use the
function and then change and recompile the function, what steps are needed
to see the change?As I see it the options are:
A: do nothing, the function is reloaded on every invocation.
B: Reopen the connection to the backend
C: Restart the postmasterI suspect B is correct but I would like to hear someone confirm it.
'B' is right - the postgreSQL not has any persisten cache for this, and
if you restart connection a backend reload this information again.Or you can drop/(re)create a function, it is total safe solution.
Not _totally_ safe: if you've got anything that refers to that function,
like a user defined type definition, drop/(re)create will change the
function's oid in the pg_proc table, causing errors when the old
function is looked up. Hmm, an ALTER FUNCTION command might be nice...
... and/or check dependencies on the function's oid if the function is DROP,
(via FOREIGN KEYs ?). IMHO it is good item to TODO if really nothing check
it. (...resending to hackers)
Karel
From bouncefilter Fri Feb 11 10:00:57 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA90266
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 10:00:53 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id JAA19426;
Fri, 11 Feb 2000 09:59:59 -0500 (EST)
To: chris@bitmead.com
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <38A3A8FB.5A9C556D@nimrod.itg.telecom.com.au>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au>
<38A3A8FB.5A9C556D@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Fri, 11 Feb 2000 17:15:23 +1100"
Date: Fri, 11 Feb 2000 09:59:59 -0500
Message-ID: <19423.950281199@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
For my own curiousity, how does the presence of limit affect a plan
anyway?
At the moment, it doesn't. But it should. To take an extreme example:
SELECT * FROM table WHERE x > 100 ORDER BY x LIMIT 1;
to get the tuple with lowest x > 100. Assuming that there is an index
on x, the right way to implement this is with an indexscan, because a
single probe into the index will pull out the tuple you want. But right
now the optimizer will choose a plan as if the LIMIT weren't there,
ie on the basis of estimated total cost to retrieve the whole ordered
result set. On that basis it might well choose sequential scan + sort,
so you'd have to wait around for a sort to complete before you get your
answer.
regards, tom lane
From bouncefilter Fri Feb 11 10:07:58 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA91726
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 10:07:15 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA19482;
Fri, 11 Feb 2000 10:07:05 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: chris@bitmead.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
In-reply-to: <3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
References: <38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<3.0.1.32.20000210223524.01706ec0@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Thu, 10 Feb 2000 22:35:24 -0800"
Date: Fri, 11 Feb 2000 10:07:04 -0500
Message-ID: <19478.950281624@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Don Baccus <dhogaza@pacifier.com> writes:
Well ... for my money I never expected LIMIT to be meaningful in
the sense of being deterministic without an ORDER BY clause.
But ... that doesn't mean that some folks might not want to use
it differently. What if LIMIT 2 were more efficient that COUNT(*)
in order to determine if more than one row satisfies a condition?
Hmm, that's an excellent example indeed. A slight variant that is
even more plausible is LIMIT 1 when you just want to know if there
is any tuple satisfying the WHERE condition, and you don't really
care about which one you get.
I don't know if that's even a remote possibility given the current
implementation,
Absolutely --- COUNT(*) doesn't provide any way of stopping early,
so a LIMITed query could be far faster. Given an appropriate plan
of course. The problem right now is that the optimizer is quite
likely to pick the wrong plan.
regards, tom lane
From bouncefilter Fri Feb 11 10:10:58 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA92469
for <hackers@postgreSQL.org>; Fri, 11 Feb 2000 10:10:26 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA19515;
Fri, 11 Feb 2000 10:10:14 -0500 (EST)
To: chris@bitmead.com
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] libpq
In-reply-to: <38A3ADE3.AAE1FC7D@nimrod.itg.telecom.com.au>
References: <38A2AE00.9EB1BE9B@bitmead.com> <15283.950196239@sss.pgh.pa.us>
<38A396B0.BF0509A5@nimrod.itg.telecom.com.au>
<18587.950249454@sss.pgh.pa.us>
<38A3ADE3.AAE1FC7D@nimrod.itg.telecom.com.au>
Comments: In-reply-to Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
message dated "Fri, 11 Feb 2000 17:36:19 +1100"
Date: Fri, 11 Feb 2000 10:10:13 -0500
Message-ID: <19512.950281813@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
If you think applications may like to keep buffered 100k of data, isn't
that an argument for the PGobject interface instead of the PGresult
interface?
How so? I haven't actually figured out what you think PGobject will do
differently from PGresult. Given the considerations I mentioned before,
I think PGobject *is* a PGresult; it has to have all the same
functionality, including carrying a tuple descriptor and a query
status (+ error message if needed).
This seems too much responsibility to press onto libpq, but if the user
has control over destruction of PQobjects they can buffer what they
want, how they want, when they want.
The app has always had control over when to destroy PGresults, too.
I still don't see the difference...
regards, tom lane
From bouncefilter Fri Feb 11 10:15:05 2000
Received: from bcs240.bcs.ee (bcs240.bcs.ee [194.204.2.240])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA01497
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 10:14:08 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1])
by bcs240.bcs.ee (8.9.3/8.8.7) with ESMTP id RAA03035;
Fri, 11 Feb 2000 17:13:33 +0200
Sender: hannu@kiku.tm.ee
Message-ID: <38A4271C.8A445948@tm.ee>
Date: Fri, 11 Feb 2000 15:13:32 +0000
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic OY
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13-7mdk i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: Constantin Teodorescu <teo@flex.ro>, Magnus Hagander <mha@sollentuna.net>,
pgsql-hackers@postgreSQL.org, "'Jan Wieck'" <wieck@debis.com>,
Rini Dutta <rinid@rocketmail.com>,
pgsql-interfaces-digest <pgsql-interfaces-digest@hub.org>
Subject: Re: [HACKERS] how to make libpq on winnt using the 'win32.mak's
References: <000e01bf7462$81d992c0$2801007e@tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hiroshi Inoue wrote:
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Magnus HaganderHi
I'm running postgres v6.5.3. I need to make calls to
the functions in libpq in my code. For this I need the
files - libpq.lib/libpq.lib.dll/libpqdll.lib.You find prepared .dll's under
src/bin/pgaccess/win32/dll
Wasn't there some utility to generate .lib files from .dll's?
I've made the dll's(libpq.dll libpgtcl.dll) under pgaccess/win32
by Constantin's request. Could someone make them instead
from now ? I've used them little myself and would lose VC++
environmemt in the near future.
Should'nt we use MingW32 instead of VC++ ?
----------
Hannu
From bouncefilter Fri Feb 11 10:42:58 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA12867
for <pgsql-hackers@postgresql.org>;
Fri, 11 Feb 2000 10:42:09 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12JICO-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Fri, 11 Feb 2000 09:41:36 -0600 (CST)
Date: Fri, 11 Feb 2000 09:41:36 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: chris@bitmead.com, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Message-ID: <20000211094136.A11985@rice.edu>
References: <15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<18098.950241132@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <18098.950241132@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Thu, Feb 10, 2000 at 10:52:12PM -0500
On Thu, Feb 10, 2000 at 10:52:12PM -0500, Tom Lane wrote:
SQL92 does not define LIMIT at all, so it's not much help in
deciding what to do. Is there anything in SQL3? What do other
DBMSes do about this issue? Comments, other variants, better ideas
anyone?
I know I'm getting in on this late, but I thought I'd answer this.
The SQL92 draft only mentions LIMIT in the list of reserved words,
and once in the index, pointing to a page on lexical elements of SQL.
the SQL3 draft that Chris pointed me at (Aug94) only mentions LIMIT as a
limit clause of a RECURSIVE UNION, whatever that is. (No time to examine
it right now) This is from the file sql-foundation-aug94.txt.
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
From bouncefilter Fri Feb 11 10:45:58 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA13251
for <hackers@postgresql.org>; Fri, 11 Feb 2000 10:43:56 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA24708;
Fri, 11 Feb 2000 15:51:12 GMT
Sender: lockhart@hub.org
Message-ID: <38A42FF0.93050B05@alumni.caltech.edu>
Date: Fri, 11 Feb 2000 15:51:12 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgres Hackers List <hackers@postgresql.org>,
"Marc G. Fournier" <scrappy@hub.org>
Subject: cvsupd OK?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm having trouble getting updates from the cvsup server. My client
connects, but then just hangs. Does anyone else see this? Could
someone do a preventative restart on the cvsupd server? TIA
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Feb 11 12:23:59 2000
Received: from bcs240.bcs.ee (bcs240.bcs.ee [194.204.2.240])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA46790
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 12:22:03 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1])
by bcs240.bcs.ee (8.9.3/8.8.7) with ESMTP id SAA03270;
Fri, 11 Feb 2000 18:41:12 +0200
Sender: hannu@kiku.tm.ee
Message-ID: <38A43BA7.7E172DB3@tm.ee>
Date: Fri, 11 Feb 2000 16:41:11 +0000
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic OY
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13-7mdk i586)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
CC: Tom Lane <tgl@sss.pgh.pa.us>, chris@bitmead.com,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
References: <15706.950201295@sss.pgh.pa.us>
<38A3435A.B6212DB8@nimrod.itg.telecom.com.au>
<18098.950241132@sss.pgh.pa.us> <20000211094136.A11985@rice.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Ross J. Reedstrom" wrote:
the SQL3 draft that Chris pointed me at (Aug94) only mentions LIMIT as a
limit clause of a RECURSIVE UNION, whatever that is. (No time to examine
it right now) This is from the file sql-foundation-aug94.txt.
If I understood it right, RECURSIVE UNION is a way to query a tree
structured
table, whith parent_id's in each child row.
AFAIK even have it in the TODO list ;)
The LIMIT there probably limits how many levels down the tree are
queried.
---------
Hannu
From bouncefilter Fri Feb 11 12:54:00 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA66978
for <hackers@postgreSQL.org>; Fri, 11 Feb 2000 12:53:01 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA24253;
Fri, 11 Feb 2000 12:52:29 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200002111752.MAA24253@candle.pha.pa.us>
Subject: Re: [HACKERS] cvsupd OK?
In-Reply-To: <38A42FF0.93050B05@alumni.caltech.edu> from Thomas Lockhart at
"Feb 11, 2000 03:51:12 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Fri, 11 Feb 2000 12:52:29 -0500 (EST)
CC: Postgres Hackers List <hackers@postgreSQL.org>,
"Marc G. Fournier" <scrappy@hub.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I'm having trouble getting updates from the cvsup server. My client
connects, but then just hangs. Does anyone else see this? Could
someone do a preventative restart on the cvsupd server? TIA- Thomas
Looks like it is working here, though a little slower than usual.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Feb 11 13:58:00 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA07834
for <hackers@postgreSQL.org>; Fri, 11 Feb 2000 13:57:38 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id LAA03055;
Fri, 11 Feb 2000 11:23:37 -0800 (PST)
Date: Fri, 11 Feb 2000 11:23:37 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: Postgres Hackers List <hackers@postgreSQL.org>,
"Marc G. Fournier" <scrappy@hub.org>
Subject: Re: [HACKERS] cvsupd OK?
Message-ID: <20000211112336.L17536@fw.wintelcom.net>
References: <38A42FF0.93050B05@alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38A42FF0.93050B05@alumni.caltech.edu>;
from lockhart@alumni.caltech.edu on Fri, Feb 11, 2000 at
03:51:12PM +0000
* Thomas Lockhart <lockhart@alumni.caltech.edu> [000211 08:19] wrote:
I'm having trouble getting updates from the cvsup server. My client
connects, but then just hangs. Does anyone else see this? Could
someone do a preventative restart on the cvsupd server? TIA
See if adding either of these flags to your cvsup command help:
-P m
-P -
-Alfred
From bouncefilter Fri Feb 11 16:06:02 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA47971
for <pgsql-hackers@postgresql.org>;
Fri, 11 Feb 2000 16:05:55 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12JNFI-0000NP-00; Fri, 11 Feb 2000 21:04:56 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12JNF4-0003B4-00; Fri, 11 Feb 2000 21:04:42 +0000
Date: Fri, 11 Feb 2000 21:04:42 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Another nasty cache problem
Message-ID: <20000211210441.A11976@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<1426.949641960@sss.pgh.pa.us>
<20000204171153.D3402@quartz.newn.cam.ac.uk>
<4803.949697937@sss.pgh.pa.us>
<20000205143515.F3402@quartz.newn.cam.ac.uk>
<7988.949771109@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <7988.949771109@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Sat, Feb 05, 2000 at 12:18:29PM -0500
The killer query was:
select crsids.surname,"tblPerson"."Surname" from crsids,"tblPerson" where crsids.usn="tblPerson"."USN"::int4;
and the reason for the SIGSEGV, is that somehow, text_int4(text *string) in
src/backend/utils/adt/int.c is called with string=(text *)0x0, so obviously
this is a problem!
crsids.usn is integer, "tblPerson"."USN" is varchar(9).
Oddly enough, text_int4 is called from fmgr.c:136 which is in the case
statement for n_arguments=2, yet that should be 1
(gdb) print {FmgrInfo}0x8221a30
$4 = {fn_addr = 0x80f9dbc <text_int4>, fn_plhandler = 0, fn_oid = 1620,
fn_nargs = 1}
unless gdb is reporting the wrong line number. values->data[0]=0=string.
I have a backtrace and a pretty printed copy of the query tree if useful...
Still trying to make a small test case...
Any suggestions appreciated!
Cheers,
Patrick
(source of 31st Jan)
On Sat, Feb 05, 2000 at 12:18:29PM -0500, Tom Lane wrote:
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
Is there anything in the postmaster log?
DEBUG: Data Base System is in production state at Fri Feb 4 17:11:05 2000
Server process (pid 3588) exited with status 11 at Fri Feb 4 17:14:57 2000But no core file ... so who knows what the sigsegv comes from. (don't worry
coredumpsize unlimited)There sure oughta be a corefile after a SIGSEGV. Hmm. How are you
starting the postmaster --- is it from a system startup script?
It might work better to start it from an ordinary user process.
I discovered the other day on a Linux box that the system just plain
would not dump a core file from a process started by root, even though
the process definitely had nonzero "ulimit -c" and had set its euid
to a nonprivileged userid. But start the same process by hand from an
unprivileged login, and it would dump a core file. Weird. Dunno if
your platform behaves the same way, but it's worth trying.regards, tom lane
From bouncefilter Fri Feb 11 16:46:06 2000
Received: from hu.tm.ee (ppp820.tele2.ee [212.107.37.120])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA79233
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 16:45:30 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id A26AC3AFA; Fri, 11 Feb 2000 23:53:05 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38A484C1.7EE47CDD@tm.ee>
Date: Fri, 11 Feb 2000 23:53:05 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
Cc: "'Tom Lane'" <tgl@sss.pgh.pa.us>,
"'chris@bitmead.com'" <chris@bitmead.com>,
"'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: AW: [HACKERS] Another nasty cache problem
References:
<219F68D65015D011A8E000006F8590C603FDC247@sdexcsrv1.f000.d0188.sd.spardat.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Zeugswetter Andreas SB wrote:
Is'nt the "blank portal" the name of the cursor you get when you just
do a select without creating a cursor ?Yes, is that still so ?
From my toy implementation of fe-be protocol in python for v.6.2 I
remember it to be, i.e. the cursors name is blank if
declare cursor ;fetch all ...
is implicit
I don't really see any advantage, that psql does not do a fetch loop
with a portal.It only increases traffic, as explicit fetch commands need to be sent
to backend. If one does not declare a cursor, an implicit
fetch all from
blank is performed.I don't really see how a fetch every x rows (e.g.1000) would add significant
overhead.
But it would start a transaction and possibly lock the table as well.
The first fetch could still be done implicit, it would only fetch 1000
instead of fetch all.
maybe we should add a macro language to psql and thus make it into something
else, like pgsh ;)
Thus there would only be overhead for large result sets, where the
wasted memory is of real concern.
The whole fe-be protocol should be re-thought at some stage (or an additional
protocol + client libs added) anyway, as current one is quite weak at XOPEN
CLI
support both ODBC and JDBC drivers are full of hacks to be compatible with
standard usages. Also performance suffers on inserts adn selects as prepared
queries can't be currently used from client programs (they can from SPI).
-------------------
Hannu
From bouncefilter Fri Feb 11 18:19:03 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA06825
for <pgsql-hackers@postgreSQL.org>;
Fri, 11 Feb 2000 18:18:36 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id SAA21868;
Fri, 11 Feb 2000 18:18:32 -0500 (EST)
To: prlw1@cam.ac.uk
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another nasty cache problem
In-reply-to: <20000211210441.A11976@quartz.newn.cam.ac.uk>
References: <22885.949246873@sss.pgh.pa.us>
<20000131191356.B8582@quartz.newn.cam.ac.uk>
<12080.949370550@sss.pgh.pa.us>
<20000203112434.B1509@quartz.newn.cam.ac.uk>
<1426.949641960@sss.pgh.pa.us>
<20000204171153.D3402@quartz.newn.cam.ac.uk>
<4803.949697937@sss.pgh.pa.us>
<20000205143515.F3402@quartz.newn.cam.ac.uk>
<7988.949771109@sss.pgh.pa.us>
<20000211210441.A11976@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Fri, 11 Feb 2000 21:04:42 +0000"
Date: Fri, 11 Feb 2000 18:18:32 -0500
Message-ID: <21865.950311112@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
and the reason for the SIGSEGV, is that somehow, text_int4(text *string) in
src/backend/utils/adt/int.c is called with string=(text *)0x0, so obviously
this is a problem!
Um. Probably you have a NULL value in "tblPerson"."USN" somewhere?
There are a lot of functions without adequate defenses against NULL
inputs :-( --- we've been cleaning them up slowly, but evidently you
found another one.
regards, tom lane
From bouncefilter Sat Feb 12 06:14:12 2000
Received: from feivel.fam-meskes.de (h-62.96.161.115.host.de.colt.net
[62.96.161.115]) by hub.org (8.9.3/8.9.3) with ESMTP id GAA46021
for <hackers@postgresql.org>; Sat, 12 Feb 2000 06:13:12 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: by feivel.fam-meskes.de (Postfix, from userid 1000)
id C4EBC2BC5E; Sat, 12 Feb 2000 11:56:47 +0100 (CET)
Date: Sat, 12 Feb 2000 11:56:47 +0100
From: Michael Meskes <meskes@postgresql.org>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: Ivo Simicevic <ivo@ultra.hr>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Re: ECPG documentation
Message-ID: <20000212115647.A5848@fam-meskes.de>
Mail-Followup-To: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Ivo Simicevic <ivo@ultra.hr>,
Postgres Hackers List <hackers@postgresql.org>
References: <3872F1C3.8007B24B@hotgames.com>
<38736C26.4A9B8777@alumni.caltech.edu>
<20000105185234.H740@ultra.hr>
<38738906.91E42C78@alumni.caltech.edu>
<41DC7537.58091799@ironmountainsystems.com>
<38A3387C.2BFB489E@alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <38A3387C.2BFB489E@alumni.caltech.edu>;
from lockhart@alumni.caltech.edu on Thu, Feb 10, 2000 at
10:15:24PM +0000
Sender: michael@fam-meskes.de
On Thu, Feb 10, 2000 at 10:15:24PM +0000, Thomas Lockhart wrote:
Hello Ivo. Have you had a chance to make progress on your docs? I'm
sure people would be *very* interested in them for the upcoming
release, and if you need some help on finishing the writing or editing
I'm sure there will be some volunteers.
I'm willing to help with explanations. But I won't have the time to write
docs in time for the release. In fact I even haven't found the time to
tackle my one and only todo item for 7.0.
BTW I have a problem with a user defined function. I posted a question about
some time ago but got no answer. The source is part of our source tree
(pgsql/src/interfaces/ecpg/test[test5.pgc|stp.pgc]).
I can insert it but when I execute it I get a result of -220 which is not
exactly the minimu of 14 and 7.
Any ideas? Just hitting make in ecpg/test should build the binaries. YOu
just have to adjust the path in test5.pgc.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!