Re: [SQL] Permission problem with COPY FROM
On Wed, Sep 15, 1999 at 03:50:09AM +1100, Stïż½phane FILLON wrote:
...
"ERROR: COPY command, running in backend with effective uid 501
(that's Postgres), could not open file '/usr/local/.../cltclr001' for
reading. Error: Permission not allowed (13)."
The problem does not seem to be with the permissions --- it has been
on the list a number of times already. Try using psql's \copy instead.
Albert.
--
---------------------------------------------------------------------------
Post an / Mail to / Skribu al: Albert Reiner <areiner@tph.tuwien.ac.at>
---------------------------------------------------------------------------
From bouncefilter Wed Sep 15 12:51:16 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id MAA03893
for <pgsql-hackers@postgreSQL.org>;
Wed, 15 Sep 1999 12:50:15 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 12943 invoked by uid 1001); 15 Sep 1999 16:50:03 -0000
Delivered-To: vev@paprika.michvhf.com
X-Received: (qmail 12868 invoked by alias); 15 Sep 1999 16:21:30 -0000
X-Received: from cinnamon.michvhf.com (209.57.60.10)
by paprika.michvhf.com with SMTP; 15 Sep 1999 16:21:30 -0000
X-Received: (qmail 6081 invoked by uid 201); 15 Sep 1999 16:21:25 -0000
Delivered-To: vev@cinnamon.michvhf.com
X-Received: (qmail 6070 invoked from network); 15 Sep 1999 16:21:23 -0000
X-Received: from basil.michvhf.com (209.57.60.17)
by cinnamon.michvhf.com with SMTP; 15 Sep 1999 16:21:23 -0000
X-Received: (qmail 15701 invoked by uid 1000); 15 Sep 1999 16:21:34 -0000
Delivered-To: vev@michvhf.com
X-Received: (qmail 15697 invoked by alias); 15 Sep 1999 16:21:33 -0000
X-Received: from hub.org (@216.126.84.1)
by basil.michvhf.com with SMTP; 15 Sep 1999 16:21:33 -0000
X-Received: from sparky.ambidexter.com (ambidexter.com [208.129.194.89])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA99579
for <webmaster@postgresql.org>; Wed, 15 Sep 1999 12:20:25 -0400 (EDT)
(envelope-from dexter@ambidexter.com)
X-Received: from [24.236.28.164] (net28-cust164 [24.236.28.164])
by sparky.ambidexter.com (8.9.3/8.9.3) with ESMTP id JAA13386
for <webmaster@postgresql.org>; Wed, 15 Sep 1999 09:22:07 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: dexter@208.129.194.89
Message-Id: <v04020a00b405779b1fc3@[24.236.28.164]>
Date: Wed, 15 Sep 1999 09:20:58 -0700
To: webmaster@postgreSQL.org
From: Michael Dexter <dexter@ambidexter.com>
Subject: Comparison Suggestion
ReSent-Date: Wed, 15 Sep 1999 12:49:52 -0400 (EDT)
ReSent-From: Vince Vielhaber <vev@michvhf.com>
ReSent-To: pgsql-hackers@postgreSQL.org
ReSent-Subject: Comparison Suggestion
ReSent-Message-ID: <Pine.BSF.4.05.9909151249521.12578@paprika.michvhf.com>
Regarding your on-line comparison of Prostgresql, Oracle, MySQL and the
like, it would help to know which systems support Stored Procedures.
Thanks,
Michael Dexter
dexter@ambidexter.com
From bouncefilter Wed Sep 15 14:12:17 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA13642
for <pgsql-hackers@postgreSQL.org>;
Wed, 15 Sep 1999 14:12:06 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id OAA28107;
Wed, 15 Sep 1999 14:11:15 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909151811.OAA28107@candle.pha.pa.us>
Subject: Re: [HACKERS] 6.6
In-Reply-To: <37DF32A7.62499F71@krs.ru> from Vadim Mikheev at "Sep 15,
1999 01:46:15 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Wed, 15 Sep 1999 14:11:15 -0400 (EDT)
CC: Mike Mascari <mascarim@yahoo.com>, pgsql-hackers@postgreSQL.org,
Jan Wieck <jwieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I would like to see something from Jan too...
My opinion is that RI _MUST_ be implemented in 6.6.
There are 3 ways:1. Using deferrable rules/statement level triggers.
2. Using transaction log (to read changes made in
parent/child tables and check RI constraints).
3. Using DIRTY READ in refint.cI hope to be able to do 2. or 3., though it would be much
better to have 1. (with statement level triggers) implemented by Jan.
Uh, oh. Vadim has thrown down the hachet on a 6.6 _must_ _have_ item.
(I agree with him, but am glad I didn't have to do it.)
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Wed Sep 15 19:51:21 1999
Received: from excelsior.rkirkpat.net (dhcp-210-85.letu.edu [204.158.210.85])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA57071
for <pgsql-hackers@postgreSQL.org>;
Wed, 15 Sep 1999 19:50:48 -0400 (EDT)
(envelope-from rkirkpat@rkirkpat.net)
Received: from localhost (rkirkpat@localhost)
by excelsior.rkirkpat.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id
SAA30949; Wed, 15 Sep 1999 18:49:16 -0500
Date: Wed, 15 Sep 1999 18:49:16 -0500 (CDT)
From: Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
X-Sender: rkirkpat@excelsior.rkirkpat.net
To: Bruce Momjian <maillist@candle.pha.pa.us>,
Lamar Owen <lamar.owen@wgcr.org>
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <99091418173200.00623@lowen.wgcr.org>
Message-ID: <Pine.LNX.4.10.9909151845000.30766-100000@excelsior.rkirkpat.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 14 Sep 1999, Lamar Owen wrote:
On Tue, 14 Sep 1999, Ryan Kirkpatrick wrote:
Yea, I am still around, though a bit busy with school at the
moment. I should be able to get 6.5.2beta downloaded and the alpha patches
updated for it by Monday if you want me to try. Or, if you get an updated
alpha patch before then, email it to me, and I will try it out. TTYL.You know that code far better than I; if you have time, applying those patches
to the final 6.5.2 would be a nice thing. I'm applying my time to getting RPM
upgrading working -- many thanks to Oliver Elphick for the Debian upgrade
scripts, some of which are very useful even in an RPM context.
Ok, I will do so this weekend, providing there are not too many
things broken. I will let you know on Monday what the status is. :)
Though, is the 6.5.2beta tar ball on the ftp site the one I want to work
with, or do I want to go from something from CVS? And if so, what is the
relevant tag?
Those 6.5.1 patches made alot of people very happy -- the guys at RedHat in
particular. Bravo to Uncle George for them originally, and bravo to you for
the backpatch and packaging to 6.5.1! Those patches, incidentally, will ship
with RedHat 6.1, if nothing happens between now and release time.
Good to hear, and you are welcome! Hopefully by 6.6 the patches
will not be needed and Linux/Alpha will finally be a fully supported pgsql
platform!
PS. Now that I made people at RedHat happy, can I get some of
thier stock? :) **Just kidding**
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
From bouncefilter Wed Sep 15 20:07:21 1999
Received: from idiom.com (root@[209.157.64.1])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA59009
for <pgsql-hackers@hub.org>; Wed, 15 Sep 1999 20:06:28 -0400 (EDT)
(envelope-from jason@idiom.com)
Received: from idiom.com (jason@localhost [127.0.0.1])
by idiom.com (8.9.3/8.9.3) with ESMTP id RAA15000
for <pgsql-hackers@hub.org>; Wed, 15 Sep 1999 17:06:21 -0700 (PDT)
Message-Id: <199909160006.RAA15000@idiom.com>
To: pgsql-hackers@hub.org
Subject: NOTICE: SIReadEntryData: cache state reset TRAP: Failed
Assertion("!(RelationNameCache->hctl->nkeys == 10):",
File: "relcache.c", Line: 1458)
Date: Wed, 15 Sep 1999 17:06:21 -0700
From: Jason Venner <jason@idiom.com>
freebsd 2.2.7 (PII system)
gcc 2.95.1
postgres 6.5.1 no patches
I get these sporadically and I can't trace them to any particular thing other than heavy access.
query: select serverSequence from estoret order by serverSequence
ProcessQuery
NOTICE: SIReadEntryData: cache state reset
TRAP: Failed Assertion("!(RelationNameCache->hctl->nkeys == 10):", File: "relcache.c", Line: 1458)
!(RelationNameCache->hctl->nkeys == 10) (0)
#0 0x20214151 in ?? ()
#1 0x202139c3 in ?? ()
#2 0x109648 in ExcAbort ()
#3 0x1095a7 in ExcUnCaught ()
#4 0x1095fa in ExcRaise ()
#5 0x108e3a in ExceptionalCondition ()
#6 0x105f33 in RelationCacheInvalidate ()
#7 0x1040ef in ResetSystemCaches ()
#8 0xc96c1 in SIReadEntryData ()
#9 0xc8d4b in InvalidateSharedInvalid ()
#10 0x104372 in DiscardInvalid ()
#11 0x2f7b8 in AtStart_Cache ()
#12 0x2f78a in CommandCounterIncrement ()
#13 0xd3754 in pg_exec_query_dest ()
#14 0xd35a4 in pg_exec_query ()
#15 0xd5118 in PostgresMain ()
#16 0xb44a8 in DoBackend ()
#17 0xb3f63 in BackendStartup ()
#18 0xb3246 in ServerLoop ()
#19 0xb2a3f in PostmasterMain ()
#20 0x69aa7 in main ()
From bouncefilter Wed Sep 15 20:30:21 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA65666
for <pgsql-hackers@postgresql.org>;
Wed, 15 Sep 1999 20:30:12 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA30632
for <pgsql-hackers@postgresql.org>;
Wed, 15 Sep 1999 21:30:28 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 15 Sep 1999 21:30:28 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: postgresql-6.5.2RC.tar.gz
Message-ID: <Pine.BSF.4.10.9909152129390.412-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
RC == Release Candidate...
Unless anyone has particular problems with this tar ball before tomorrow
morning (7:30EST), I'm going to get rid of the RC and make it the
release...
speak now or forever hold your piece :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Sep 15 20:40:21 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA67065
for <pgsql-hackers@postgresql.org>;
Wed, 15 Sep 1999 20:39:51 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA30809
for <pgsql-hackers@postgresql.org>;
Wed, 15 Sep 1999 21:40:09 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 15 Sep 1999 21:40:09 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: patches -- sucker for punishment?
Message-ID: <Pine.BSF.4.10.9909152138350.412-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Okay, using 'diff -cr --new-file' to create the patches, I've created one
from 6.5->6.5.1 and one from 6.5.1->6.5.2 ... I'm downloading everything
to my computer right now to see how the patches work (if they work), but
if anyone else wants to try, they are up on the site and ready to go...
If there is somethign else I should be using for that diff, please feel
free to mention it and I'll do it all over again...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Sep 15 23:04:23 1999
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 XAA84039
for <hackers@postgresql.org>; Wed, 15 Sep 1999 23:04:19 -0400 (EDT)
(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 DAA30326
for <hackers@postgresql.org>; Thu, 16 Sep 1999 03:03:53 GMT
Sender: lockhart@hub.org
Message-ID: <37E05E18.F827BA41@alumni.caltech.edu>
Date: Thu, 16 Sep 1999 03:03:53 +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>
Subject: Join syntax
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've been playing with selects using explicit join syntax, and have
some initial results for inner joins (haven't done anything more about
outer joins yet; inner joins are tough enough for now).
It's a real pita to flatten the join expressions into the traditional
Postgres query tree. It would be nice to start thinking about how to
represent general subqueries or intermediate queries in the parse
tree.
Anyway, some examples below...
- Thomas
postgres=> select * from t1;
i| j
-+--
1|10
2|20
3|30
(3 rows)
postgres=> select * from t2;
i| x
-+---
1|100
3|300
(2 rows)
postgres=> select * from t1 natural join t2;
i| j| x
-+--+---
1|10|100
3|30|300
(2 rows)
postgres=> select * from t1 join t2 using (i);
i| j| x
-+--+---
1|10|100
3|30|300
(2 rows)
postgres=> select * from t1 join t2 on (t1.i = t2.i);
i| j|i| x
-+--+-+---
1|10|1|100
3|30|3|300
(2 rows)
postgres=> select * from t1 natural join t2 natural join t1;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is
impossible. Terminating.
Oh well. Was on a roll 'til then ;)
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Sep 16 03:37:26 1999
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA22507
for <pgsql-hackers@postgreSQL.org>;
Thu, 16 Sep 1999 03:37:09 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U120.dialup.udm.net [192.168.53.120])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id MAA40289;
Thu, 16 Sep 1999 12:36:57 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37E09D04.8B342772@udmnet.ru>
Date: Thu, 16 Sep 1999 12:32:20 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] patches
References: <Pine.BSF.4.10.9909152138350.412-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
Okay, using 'diff -cr --new-file' to create the patches, I've created one
from 6.5->6.5.1 and one from 6.5.1->6.5.2 ... I'm downloading everything
to my computer right now to see how the patches work (if they work), but
if anyone else wants to try, they are up on the site and ready to go...If there is somethign else I should be using for that diff, please feel
free to mention it and I'll do it all over again...
I'm experiencing some strange problems with that patches. First,
my Netscape shows their sizes as approx. 200-300 k. But being downloaded,
they are 2-3 megs of size. Second, occasionally I had to download a
patch (6.5.1->6.5.2) twice, one immediately after another. They were
different! There was some strings of difference in the middle of
the patch. Maybe it was Netscape's quirks. Hope so. As to patches
themselves, they seem to be Ok, though I couldn't test them by
compiling source (my source tree is somehow slightly damaged), there
were no unreasonable hunk fails. I had to use -p1 option with the
patch to strip top-level dir which is called different on my system.
--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.
From bouncefilter Thu Sep 16 08:23:29 1999
Received: from mail.kdt.de (mail.kdt.de [195.8.224.4])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA84020
for <pgsql-hackers@postgresql.org>;
Thu, 16 Sep 1999 08:23:13 -0400 (EDT)
(envelope-from christof.petig@wtal.de)
Received: from gateway.petig.de (line0190lf.kdt.de [195.8.241.190])
by mail.kdt.de (8.8.8/8.8.8) with ESMTP id OAA15183
for <pgsql-hackers@postgresql.org>; Thu, 16 Sep 1999 14:23:11 +0200
Received: from wtal.de (christof@[192.168.230.9])
by gateway (8.8.8/8.8.8) with ESMTP id OAA04526
for <pgsql-hackers@postgresql.org>; Thu, 16 Sep 1999 14:09:15 +0200
Sender: christof@to.wtal.de
Message-ID: <37E0E0A0.2C650305@wtal.de>
Date: Thu, 16 Sep 1999 14:20:48 +0200
From: Christof Petig <christof.petig@wtal.de>
Organization: Adolf Petig GmbH. & Co. KG
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.7 i586)
X-Accept-Language: de
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Is there a maintainer for ecpg? patch included
Content-Type: multipart/mixed; boundary="------------5DCF69B75816DF1B32E2B673"
This is a multi-part message in MIME format.
--------------5DCF69B75816DF1B32E2B673
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear Pgsql Wizards,
I posted this message three weeks ago on pgsql-bugs and got no reply.
Is there a maintainer for ecpg? I have also trapped some other bugs /
oddities (e.g. upper case for table names etc. gets lost even if
quoted).
The patch does
- enables the use of bool variables in fields which might become NULL.
Up to now the lib told you that NULL is not a bool variable, even if
you provided an indicator.
- the second patch checks whether a value is null and issues an error if
no indicator is provided.
Sidenote: IIRC, the variable should be left alone if the value is NULL.
ECPGlib sets it's value to 0 on NULL. Is this a violation of the
standard?
Regards
Christof
PS: I offer some time for ecpg if there is no current maintainer. Or
should I address another list? (pgsql-interfaces?)
--------------5DCF69B75816DF1B32E2B673
Content-Type: text/plain; charset=us-ascii;
name="ecpg.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ecpg.patch"
--- src/interfaces/ecpg/ChangeLog.orig Mon Aug 2 11:14:41 1999
+++ src/interfaces/ecpg/ChangeLog Fri Sep 10 13:34:19 1999
@@ -1,3 +1,8 @@
+Tue Aug 24 15:53:28 MEST 1999
+
+ - made NULL a valid bool value
+ - check for indicator variables on NULL
+
Wed Feb 11 10:58:13 CET 1998 - Added '-d' option to turn on debugging.
--- src/interfaces/ecpg/include/ecpgerrno.h.orig Sat Mar 20 20:46:33 1999
+++ src/interfaces/ecpg/include/ecpgerrno.h Fri Sep 10 13:33:43 1999
@@ -22,6 +22,7 @@
#define ECPG_FLOAT_FORMAT -206
#define ECPG_CONVERT_BOOL -207
#define ECPG_EMPTY -208
+#define ECPG_MISSING_INDICATOR -209 #define ECPG_NO_CONN -220
#define ECPG_NOT_CONN -221
--- src/interfaces/ecpg/lib/ecpglib.c.orig Mon Aug 2 11:14:41 1999
+++ src/interfaces/ecpg/lib/ecpglib.c Fri Sep 10 13:34:12 1999
@@ -755,7 +755,16 @@
case ECPGt_unsigned_long:
((long *) var->ind_value)[act_tuple] = -PQgetisnull(results, act_tuple, act_field);
break;
+ case ECPGt_NO_INDICATOR:
+ if (PQgetisnull(results, act_tuple, act_field))
+ {
+ register_error(ECPG_MISSING_INDICATOR, "NULL value without indicator variable on line %d.", stmt->lineno);
+ status = false;
+ }
+ break;
default:
+ register_error(ECPG_UNSUPPORTED, "Unsupported indicator type %s on line %d.", ECPGtype_name(var->ind_type), stmt->lineno);
+ status = false;
break;
}@@ -878,6 +887,11 @@
else if (pval[0] == 't' && pval[1] == '\0')
{
((char *) var->value)[act_tuple] = true;
+ break;
+ }
+ else if (pval[0] == '\0' && PQgetisnull(results, act_tuple, act_field))
+ {
+ // NULL is valid
break;
}
}--------------5DCF69B75816DF1B32E2B673--
From bouncefilter Thu Sep 16 09:50:37 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA95473
for <pgsql-hackers@hub.org>; Thu, 16 Sep 1999 09:49:52 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA22039;
Thu, 16 Sep 1999 09:48:47 -0400 (EDT)
To: Jason Venner <jason@idiom.com>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] NOTICE: SIReadEntryData: cache state reset TRAP: Failed
Assertion("!(RelationNameCache->hctl->nkeys == 10):",
File: "relcache.c", Line: 1458)
In-reply-to: Your message of Wed, 15 Sep 1999 17:06:21 -0700
<199909160006.RAA15000@idiom.com>
Date: Thu, 16 Sep 1999 09:48:47 -0400
Message-ID: <22037.937489727@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Jason Venner <jason@idiom.com> writes:
I get these sporadically and I can't trace them to any particular
thing other than heavy access.
NOTICE: SIReadEntryData: cache state reset
TRAP: Failed Assertion("!(RelationNameCache->hctl->nkeys == 10):", File: "relcache.c", Line: 1458)
!(RelationNameCache->hctl->nkeys == 10) (0)
Yeah. What's happening is that the SI message buffer is overflowing and
you are hitting a bug in the code that is supposed to recover from that
condition. (I posted a long discussion of what SI is all about a few
days ago and don't feel like repeating it --- check the list archives.)
There are several bugs in that area :-(.
I believe I have fixed all the problems with SI overflow recovery for
6.6, but that's part of a rather extensive set of changes to relcache.c
and sinvaladt.c. We are talking about back-patching these changes along
with the not-yet-done relation locking change to make a 6.5.3.
In the meantime, your best bet might be to reduce the probability of SI
overflow by raising MAXNUMMESSAGES in src/include/storage/sinvaladt.h.
It's standardly 4000, but the space per message is only a couple dozen
bytes, so you could probably make it 10 times that without hurting
much...
regards, tom lane
From bouncefilter Thu Sep 16 10:11:30 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA98967
for <hackers@postgreSQL.org>; Thu, 16 Sep 1999 10:10:48 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA22129;
Thu, 16 Sep 1999 10:09:38 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Join syntax
In-reply-to: Your message of Thu, 16 Sep 1999 03:03:53 +0000
<37E05E18.F827BA41@alumni.caltech.edu>
Date: Thu, 16 Sep 1999 10:09:37 -0400
Message-ID: <22127.937490977@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
It's a real pita to flatten the join expressions into the traditional
Postgres query tree. It would be nice to start thinking about how to
represent general subqueries or intermediate queries in the parse
tree.
Yes. Jan has been saying for some time that he needs that for rules.
Also, I have found some squirrely cases in INSERT ... SELECT ... that
can't really be done right unless the INSERT and SELECT targetlists
are kept separate, which seems to mean a two-level parsetree structure.
The UNION/INTERSECT/EXCEPT code has a really klugy approach to
multi-query parse trees, which maybe could be cleaned up if we
supported them in a more general fashion.
Maybe it's time to bite the bullet and do it. You have any thoughts
on what the representation should look like?
regards, tom lane
From bouncefilter Thu Sep 16 10:17:30 1999
Received: from bsdi.infima.cz (xbouska@bsdi.infima.cz [193.179.168.65])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA99976
for <pgsql-hackers@postgreSQL.org>;
Thu, 16 Sep 1999 10:17:03 -0400 (EDT)
(envelope-from xbouska@bsdi.infima.cz)
Received: from localhost (xbouska@localhost)
by bsdi.infima.cz (8.9.0/8.9.0) with ESMTP id QAA28651
for <pgsql-hackers@postgreSQL.org>;
Thu, 16 Sep 1999 16:16:59 +0200 (CEST)
Date: Thu, 16 Sep 1999 16:16:58 +0200 (CEST)
From: Richard Bouska <xbouska@bsdi.infima.cz>
To: pgsql-hackers@postgreSQL.org
Subject: 1d,1e,1f poison for data?
Message-ID: <Pine.BSI.4.05L.9909161609130.4509-100000@bsdi.infima.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hello
I have inserted texts with hex codes 1d, 1e and 1f into 6.5.1 and it seems
to that this characters totaly confuses the server, the vacuum writes that
the parent for record does not exist or that the record is to long.
Is that possible?
I am not sure that this is the reason but when I copy the table to file,
destroy it, created again a copy back through filter which removes those
characters, then the server workes well.
Should'n the data be parsed for such a character before they are inserted?
Thanks in advance
Richard Bouska
From bouncefilter Thu Sep 16 11:15:34 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA10047
for <pgsql-hackers@postgreSQL.org>;
Thu, 16 Sep 1999 11:14:44 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA25362;
Thu, 16 Sep 1999 11:13:29 -0400 (EDT)
To: Richard Bouska <xbouska@bsdi.infima.cz>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] 1d,1e,1f poison for data?
In-reply-to: Your message of Thu, 16 Sep 1999 16:16:58 +0200 (CEST)
<Pine.BSI.4.05L.9909161609130.4509-100000@bsdi.infima.cz>
Date: Thu, 16 Sep 1999 11:13:29 -0400
Message-ID: <25360.937494809@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Richard Bouska <xbouska@bsdi.infima.cz> writes:
I have inserted texts with hex codes 1d, 1e and 1f into 6.5.1 and it seems
to that this characters totaly confuses the server, the vacuum writes that
the parent for record does not exist or that the record is to long.
Is that possible?
Doesn't seem like that should be a problem (and a quick trial here
doesn't show any obvious trouble). I'm guessing the explanation is
something else ... but I'm not sure what.
There are a couple of known gotchas that might cause trouble at vacuum
time:
1. If you run the server with different LOCALE settings at different
times, then the sort order of an existing index might be wrong for
the current LOCALE, in which case the system gets very confused.
Don't do that ;-)
2. If you have an index on a text field, the effective limit on text
length is ~4K instead of ~8K, because the btree index code expects to be
able to fit at least 2 keys on a disk page. This one is nasty because
if only a few of your entries are >4K you might sail along happily
until one day two long entries chance to wind up on the same page of the
index. In particular, VACUUM rearranges the index so the problem could
show up at that time.
If neither of those explain your trouble, please see if you can
develop a reproducible test case, and submit a full bug report.
regards, tom lane
From bouncefilter Thu Sep 16 12:29:39 1999
Received: from postal.dn.net (postal.dn.net [207.226.170.20])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA29192
for <pgsql-hackers@postgreSQL.org>;
Thu, 16 Sep 1999 12:28:48 -0400 (EDT)
(envelope-from frankpit@pop.dn.net)
Received: from pop.dn.net (pm-92.ppp.wdc.dn.net [207.226.188.92])
by postal.dn.net (8.9.3/postal) with ESMTP id MAA16363
for <pgsql-hackers@postgreSQL.org>;
Thu, 16 Sep 1999 12:28:10 -0400 (EDT)
Sender: matuser@postal.dn.net
Message-ID: <37E12015.AFA0D0BA@pop.dn.net>
Date: Thu, 16 Sep 1999 16:51:33 +0000
From: Bernard Frankpitt <frankpit@pop.dn.net>
Organization: AIMS
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.32 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Doccumentation Patch for Create Function
Content-Type: multipart/mixed; boundary="------------272B4C7116F8BBC6673AA8FF"
This is a multi-part message in MIME format.
--------------272B4C7116F8BBC6673AA8FF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi all,
Please find attached diffs to the documentation that are intended to
accompany the CREATE FUNCTION patch that I submitted earlier. I stuck
with the syntax in the original patch rather than the alternative
syntax suggested by Andreas.
When I was altering the xfunc.sgml page I came across this:
<title>Name Space Conflicts</title>
<para>
As of <productname>Postgres</productname> v6.5,
<command>CREATE FUNCTION</command> can decouple a C language
function name from the name of the entry point. This is now the
preferred technique to accomplish function overloading.
</para>
which seems to suggest that someone had a similar idea in the past. I
could find no evidence of this functionality in the 6.5 code though
Bernard Frankpitt
--------------272B4C7116F8BBC6673AA8FF
Content-Type: application/octet-stream;
name="CreateProcedureDocs.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="CreateProcedureDocs.patch"
KioqIC4vZG9jL3NyYy9zZ21sL3JlZi9jcmVhdGVfZnVuY3Rpb24uc2dtbC5vcmlnCVRodSBT
ZXAgMTYgMTE6NTM6MTEgMTk5OQotLS0gLi9kb2Mvc3JjL3NnbWwvcmVmL2NyZWF0ZV9mdW5j
dGlvbi5zZ21sCVRodSBTZXAgMTYgMTI6MTA6NDEgMTk5OQoqKioqKioqKioqKioqKioKKioq
IDI1LDMyICoqKioKICAgIDxzeW5vcHNpcz4KICBDUkVBVEUgRlVOQ1RJT04gPHJlcGxhY2Vh
YmxlIGNsYXNzPSJwYXJhbWV0ZXIiPm5hbWU8L3JlcGxhY2VhYmxlPiAoIFsgPHJlcGxhY2Vh
YmxlIGNsYXNzPSJwYXJhbWV0ZXIiPmZ0eXBlPC9yZXBsYWNlYWJsZT4gWywgLi4uXSBdICkK
ICAgICAgUkVUVVJOUyA8cmVwbGFjZWFibGUgY2xhc3M9InBhcmFtZXRlciI+cnR5cGU8L3Jl
cGxhY2VhYmxlPgohICAgICBBUyA8cmVwbGFjZWFibGUgY2xhc3M9InBhcmFtZXRlciI+ZGVm
aW5pdGlvbjwvcmVwbGFjZWFibGU+CiAgICAgIExBTkdVQUdFICc8cmVwbGFjZWFibGUgY2xh
c3M9InBhcmFtZXRlciI+bGFuZ25hbWU8L3JlcGxhY2VhYmxlPicKICAgIDwvc3lub3BzaXM+
CiAgICAKICAgIDxyZWZzZWN0MiBpZD0iUjItU1FMLUNSRUFURUZVTkNUSU9OLTEiPgotLS0g
MjUsMzggLS0tLQogICAgPHN5bm9wc2lzPgogIENSRUFURSBGVU5DVElPTiA8cmVwbGFjZWFi
bGUgY2xhc3M9InBhcmFtZXRlciI+bmFtZTwvcmVwbGFjZWFibGU+ICggWyA8cmVwbGFjZWFi
bGUgY2xhc3M9InBhcmFtZXRlciI+ZnR5cGU8L3JlcGxhY2VhYmxlPiBbLCAuLi5dIF0gKQog
ICAgICBSRVRVUk5TIDxyZXBsYWNlYWJsZSBjbGFzcz0icGFyYW1ldGVyIj5ydHlwZTwvcmVw
bGFjZWFibGU+CiEgICAgIEFTIDxyZXBsYWNlYWJsZSBjbGFzcz0icGFyYW1ldGVyIj5kZWZp
bml0aW9uPC9yZXBsYWNlYWJsZT4gICAKICAgICAgTEFOR1VBR0UgJzxyZXBsYWNlYWJsZSBj
bGFzcz0icGFyYW1ldGVyIj5sYW5nbmFtZTwvcmVwbGFjZWFibGU+JworIAorIAorIENSRUFU
RSBGVU5DVElPTiA8cmVwbGFjZWFibGUgY2xhc3M9InBhcmFtZXRlciI+bmFtZTwvcmVwbGFj
ZWFibGU+ICggWyA8cmVwbGFjZWFibGUgY2xhc3M9InBhcmFtZXRlciI+ZnR5cGU8L3JlcGxh
Y2VhYmxlPiBbLCAuLi5dIF0gKQorICAgICBSRVRVUk5TIDxyZXBsYWNlYWJsZSBjbGFzcz0i
cGFyYW1ldGVyIj5ydHlwZTwvcmVwbGFjZWFibGU+CisgICAgIEFTIDxyZXBsYWNlYWJsZSBj
bGFzcz0icGFyYW1ldGVyIj5vYmpfZmlsZTwvcmVwbGFjZWFibGU+ICwgPHJlcGxhY2VhYmxl
IGNsYXNzPSJwYXJhbWV0ZXIiPmxpbmtfc3ltYm9sPC9yZXBsYWNlYWJsZT4gIAorICAgICBM
QU5HVUFHRSAnYycKICAgIDwvc3lub3BzaXM+CiAgICAKICAgIDxyZWZzZWN0MiBpZD0iUjIt
U1FMLUNSRUFURUZVTkNUSU9OLTEiPgoqKioqKioqKioqKioqKioKKioqIDg0LDg5ICoqKioK
LS0tIDkwLDExMSAtLS0tCiAgICAgICAgPC9saXN0aXRlbT4KICAgICAgIDwvdmFybGlzdGVu
dHJ5PgogICAgICAgPHZhcmxpc3RlbnRyeT4KKyAgICAgICA8dGVybT48cmVwbGFjZWFibGUg
Y2xhc3M9InBhcmFtZXRlciI+b2JqX2ZpbGU8L3JlcGxhY2VhYmxlPiAsIDxyZXBsYWNlYWJs
ZSBjbGFzcz0icGFyYW1ldGVyIj5saW5rX3N5bWJvbDwvcmVwbGFjZWFibGU+PC90ZXJtPgor
ICAgICAgIDxsaXN0aXRlbT4KKyAgICAgICAgPHBhcmE+CisgCVRoaXMgZm9ybSBvZiB0aGUg
PGNvbW1hbmQ+QVM8L2NvbW1hbmQ+IGNsYXVzZSBpcyB1c2VkIGZvcgorIAlkeW5hbWljYWxs
eS1saW5rZWQsIEMgbGFuZ3VhZ2UgZnVuY3Rpb25zIHdoZW4gdGhlIGZ1bmN0aW9uIG5hbWUg
aW4KKyAJdGhlIEMgbGFuZ3VhZ2Ugc291cmNlIGNvZGUgaXMgbm90IHRoZSBzYW1lIGFzIHRo
ZSBuYW1lIG9mIHRoZSBTUUwKKyAJZnVuY3Rpb24uIFRoZSBzdHJpbmcgPHJlcGxhY2VhYmxl
CisgCWNsYXNzPSJwYXJhbWV0ZXIiPm9ial9maWxlPC9yZXBsYWNlYWJsZT4gaXMgdGhlIG5h
bWUgb2YgdGhlIGZpbGUKKyAJY29udGFpbmluZyB0aGUgZHluYW1pY2FsbHkgbG9hZGFibGUg
b2JqZWN0LCBhbmQgPHJlcGxhY2VhYmxlCisgCWNsYXNzPSJwYXJhbWV0ZXIiPmxpbmtfc3lt
Ym9sPC9yZXBsYWNlYWJsZT4sIGlzIHRoZSBvYmplY3QncyBsaW5rCisgCXN5bWJvbCB3aGlj
aCBpcyB0aGUgc2FtZSBhcyB0aGUgbmFtZSBvZiB0aGUgZnVuY3Rpb24gaW4gdGhlIEMKKyAJ
bGFuZ3VhZ2Ugc291cmNlIGNvZGUuCisgICAgICAgIDwvcGFyYT4KKyAgICAgICA8L2xpc3Rp
dGVtPgorICAgICAgPC92YXJsaXN0ZW50cnk+CisgICAgICA8dmFybGlzdGVudHJ5PgogICAg
ICAgIDx0ZXJtPjxyZXBsYWNlYWJsZSBjbGFzcz0icGFyYW1ldGVyIj5sYW5nbmFtZTwvcmVw
bGFjZWFibGU+PC90ZXJtPgogICAgICAgIDxsaXN0aXRlbT4KICAgICAgICAgPHBhcmE+Cioq
KioqKioqKioqKioqKgoqKiogMTY1LDE3NCAqKioqCiAgICAgPHBhcmE+CiAgICAgIDxwcm9k
dWN0bmFtZT5Qb3N0Z3JlczwvcHJvZHVjdG5hbWU+IGFsbG93cyBmdW5jdGlvbiAib3Zlcmxv
YWRpbmciOwogICAgICB0aGF0IGlzLCB0aGUgc2FtZSBuYW1lIGNhbiBiZSB1c2VkIGZvciBz
ZXZlcmFsIGRpZmZlcmVudCBmdW5jdGlvbnMKISAgICAgc28gbG9uZyBhcyB0aGV5IGhhdmUg
ZGlzdGluY3QgYXJndW1lbnQgdHlwZXMuICBUaGlzIGZhY2lsaXR5IG11c3QgYmUKISAgICAg
dXNlZCB3aXRoIGNhdXRpb24gZm9yIDxsaXRlcmFsPmludGVybmFsPC9saXRlcmFsPgohICAg
ICBhbmQgQy1sYW5ndWFnZSBmdW5jdGlvbnMsIGhvd2V2ZXIuCiEgICAgPC9wYXJhPgogIAog
ICAgIDxwYXJhPgogICAgICBUd28gPGxpdGVyYWw+aW50ZXJuYWw8L2xpdGVyYWw+Ci0tLSAx
ODcsMTk2IC0tLS0KICAgICA8cGFyYT4KICAgICAgPHByb2R1Y3RuYW1lPlBvc3RncmVzPC9w
cm9kdWN0bmFtZT4gYWxsb3dzIGZ1bmN0aW9uICJvdmVybG9hZGluZyI7CiAgICAgIHRoYXQg
aXMsIHRoZSBzYW1lIG5hbWUgY2FuIGJlIHVzZWQgZm9yIHNldmVyYWwgZGlmZmVyZW50IGZ1
bmN0aW9ucwohICAgICBzbyBsb25nIGFzIHRoZXkgaGF2ZSBkaXN0aW5jdCBhcmd1bWVudCB0
eXBlcy4gIFRoaXMgZmFjaWxpdHkgbXVzdAohICAgICBiZSB1c2VkIHdpdGggY2F1dGlvbiBm
b3IgPGxpdGVyYWw+aW50ZXJuYWw8L2xpdGVyYWw+IGFuZAohICAgICBDLWxhbmd1YWdlIGZ1
bmN0aW9ucywgaG93ZXZlci4gICAgCiEgCTwvcGFyYT4KICAKICAgICA8cGFyYT4KICAgICAg
VHdvIDxsaXRlcmFsPmludGVybmFsPC9saXRlcmFsPgoqKioqKioqKioqKioqKioKKioqIDE4
MSwxOTggKioqKgogICAgIDwvcGFyYT4KICAKICAgICA8cGFyYT4KISAgICAgRm9yIGR5bmFt
aWNhbGx5LWxvYWRlZCBDIGZ1bmN0aW9ucywgdGhlIFNRTCBuYW1lIG9mIHRoZSBmdW5jdGlv
biBtdXN0CiEgICAgIGJlIHRoZSBzYW1lIGFzIHRoZSBDIGZ1bmN0aW9uIG5hbWUsIGJlY2F1
c2UgdGhlIEFTIGNsYXVzZSBpcyB1c2VkIHRvCiEgICAgIGdpdmUgdGhlIHBhdGggbmFtZSBv
ZiB0aGUgb2JqZWN0IGZpbGUgY29udGFpbmluZyB0aGUgQyBjb2RlLiAgSW4gdGhpcwohICAg
ICBzaXR1YXRpb24gaXQgaXMgYmVzdCBub3QgdG8gdHJ5IHRvIG92ZXJsb2FkIFNRTCBmdW5j
dGlvbiBuYW1lcy4gIEl0CiEgICAgIG1pZ2h0IHdvcmsgdG8gbG9hZCBhIEMgZnVuY3Rpb24g
dGhhdCBoYXMgdGhlIHNhbWUgQyBuYW1lIGFzIGFuIGludGVybmFsCiEgICAgIGZ1bmN0aW9u
IG9yIGFub3RoZXIgZHluYW1pY2FsbHktbG9hZGVkIGZ1bmN0aW9uIC0tLSBvciBpdCBtaWdo
dCBub3QuCiEgICAgIE9uIHNvbWUgcGxhdGZvcm1zIHRoZSBkeW5hbWljIGxvYWRlciBtYXkg
Ym90Y2ggdGhlIGxvYWQgaW4gaW50ZXJlc3RpbmcKISAgICAgd2F5cyBpZiB0aGVyZSBpcyBh
IGNvbmZsaWN0IG9mIEMgZnVuY3Rpb24gbmFtZXMuICBTbywgZXZlbiBpZiBpdCB3b3Jrcwoh
ICAgICBmb3IgeW91IHRvZGF5LCB5b3UgbWlnaHQgcmVncmV0IG92ZXJsb2FkaW5nIG5hbWVz
IGxhdGVyIHdoZW4geW91IHRyeQohICAgICB0byBydW4gdGhlIGNvZGUgc29tZXdoZXJlIGVs
c2UuCiAgICAgPC9wYXJhPgogIAogICAgIDxwYXJhPgogICAgICBBIEMgZnVuY3Rpb24gY2Fu
bm90IHJldHVybiBhIHNldCBvZiB2YWx1ZXMuCiAgICAgPC9wYXJhPgotLS0gMjAzLDIxNyAt
LS0tCiAgICAgPC9wYXJhPgogIAogICAgIDxwYXJhPgohICAgICBXaGVuIG92ZXJsb2FkaW5n
IFNRTCBmdW5jdGlvbnMgd2l0aCBDLWxhbmd1YWdlIGZ1bmN0aW9ucywgZ2l2ZQohICAgICBl
YWNoIEMtbGFuZ3VhZ2UgaW5zdGFuY2Ugb2YgdGhlIGZ1bmN0aW9uIGEgZGlzdGluY3QgbmFt
ZSwgYW5kIHVzZQohICAgICB0aGUgYWx0ZXJuYXRpdmUgZm9ybSBvZiB0aGUgPGNvbW1hbmQ+
QVM8L2NvbW1hbmQ+IGNsYXVzZSBpbiB0aGUKISAgICAgPGNvbW1hbmQ+Q1JFQVRFIEZVTkNU
SU9OPC9jb21tYW5kPiBzeW50YXggdG8gZW5zdXJlIHRoYXQKISAgICAgb3ZlcmxvYWRlZCBT
UUwgZnVuY3Rpb25zIG5hbWVzIGFyZSByZXNvbHZlZCB0byB0aGUgY29ycmVjdAohICAgICBk
eW5hbWljYWxseSBsaW5rZWQgb2JqZWN0cy4KICAgICA8L3BhcmE+CiAgCisgCiAgICAgPHBh
cmE+CiAgICAgIEEgQyBmdW5jdGlvbiBjYW5ub3QgcmV0dXJuIGEgc2V0IG9mIHZhbHVlcy4K
ICAgICA8L3BhcmE+CioqKioqKioqKioqKioqKgoqKiogMjI3LDIzMyAqKioqCiAgICAgaXMg
Y29ycmVjdC4gSXQgaXMgaW50ZW5kZWQgZm9yIHVzZSBpbiBhIENIRUNLIGNvbnRyYWludC4K
ICAgIDwvcGFyYT4KICAgIDxwcm9ncmFtbGlzdGluZz4KLSAgICA8dXNlcmlucHV0PgogIENS
RUFURSBGVU5DVElPTiBlYW5fY2hlY2tkaWdpdChicGNoYXIsIGJwY2hhcikgUkVUVVJOUyBi
b29sCiAgICAgIEFTICcvdXNyMS9wcm9qL2JyYXkvc3FsL2Z1bmNzLnNvJyBMQU5HVUFHRSAn
Yyc7CiAgICAgIAotLS0gMjQ2LDI1MSAtLS0tCioqKioqKioqKioqKioqKgoqKiogMjM4LDI0
NSAqKioqCiAgICAgIGVhbmNvZGUgICBjaGFyKDYpIENIRUNLIChlYW5jb2RlIH4gJ1swLTld
ezZ9JyksCiAgICAgIENPTlNUUkFJTlQgZWFuICAgIENIRUNLIChlYW5fY2hlY2tkaWdpdChl
YW5wcmVmaXgsIGVhbmNvZGUpKQogICk7Ci0gICAgPC91c2VyaW5wdXQ+CiAgICA8L3Byb2dy
YW1saXN0aW5nPgogICA8L3JlZnNlY3QxPgogICAKICAgPHJlZnNlY3QxIGlkPSJSMS1TUUwt
Q1JFQVRFRlVOQ1RJT04tNCI+Ci0tLSAyNTYsMjk2IC0tLS0KICAgICAgZWFuY29kZSAgIGNo
YXIoNikgQ0hFQ0sgKGVhbmNvZGUgfiAnWzAtOV17Nn0nKSwKICAgICAgQ09OU1RSQUlOVCBl
YW4gICAgQ0hFQ0sgKGVhbl9jaGVja2RpZ2l0KGVhbnByZWZpeCwgZWFuY29kZSkpCiAgKTsK
ICAgIDwvcHJvZ3JhbWxpc3Rpbmc+CisgCisgCisgICA8cGFyYT4KKyAgICBUaGlzIGV4YW1w
bGUgY3JlYXRlcyBhIGZ1bmN0aW9uIHRoYXQgZG9lcyB0eXBlIGNvbnZlcnNpb24gYmV0d2Vl
biB0aGUKKyAgICB1c2VyIGRlZmluZWQgdHlwZSBjb21wbGV4LCBhbmQgdGhlIGludGVybmFs
IHR5cGUgcG9pbnQuICBUaGUKKyAgICBmdW5jdGlvbiBpcyBpbXBsZW1lbnRlZCBieSBhIGR5
bmFtaWNhbGx5IGxvYWRlZCBvYmplY3QgdGhhdCB3YXMKKyAgICBjb21waWxlZCBmcm9tIEMg
c291cmNlLiBGb3IgPHByb2R1Y3RuYW1lPlBvc3RncmVzPC9wcm9kdWN0bmFtZT4gdG8KKyAg
ICBmaW5kIGEgdHlwZSBjb252ZXJzaW9uIGZ1bmN0aW9uIGF1dG9tYXRpY2FsbHksIHRoZSBz
cWwgZnVuY3Rpb24gaGFzCisgICAgdG8gaGF2ZSB0aGUgc2FtZSBuYW1lIGFzIHRoZSByZXR1
cm4gdHlwZSwgYW5kIG92ZXJsb2FkaW5nIGlzCisgICAgdW5hdm9pZGFibGUuICBUaGUgZnVu
Y3Rpb24gbmFtZSBpcyBvdmVybG9hZGVkIGJ5IHVzaW5nIHRoZSBzZWNvbmQKKyAgICBmb3Jt
IG9mIHRoZSA8Y29tbWFuZD5BUzwvY29tbWFuZD4gY2xhdXNlIGluIHRoZSBTUUwgZGVmaW5p
dGlvbgorICAgPC9wYXJhPgorICAgPHByb2dyYW1saXN0aW5nPgorIENSRUFURSBGVU5DVElP
TiBwb2ludChjb21wbGV4KSBSRVRVUk5TIHBvaW50CisgICAgIEFTICcvaG9tZS9iZXJuaWUv
cGdzcWwvbGliL2NvbXBsZXguc28nLCAnY29tcGxleF90b19wb2ludCcKKyAgICAgTEFOR1VB
R0UgJ2MnOworICAgPC9wcm9ncmFtbGlzdGluZz4KKyAgIDxwYXJhPgorICAgVGhlIEMgZGVj
YWxhcmF0aW9uIG9mIHRoZSBmdW5jdGlvbiBpczoKKyAgIDwvcGFyYT4KKyAgIDxwcm9ncmFt
bGlzdGluZz4KKyBQb2ludCAqIGNvbXBsZXhfdG9fcG9pbnQgKENvbXBsZXggKnopCisgewor
IAlQb2ludCAqcDsKKyAKKyAJcCA9IChQb2ludCAqKSBwYWxsb2Moc2l6ZW9mKFBvaW50KSk7
CisgCXAtPnggPSB6LT54OworIAlwLT55ID0gei0+eTsKKyAJCQorIAlyZXR1cm4gcDsKKyB9
CisgICA8L3Byb2dyYW1saXN0aW5nPgorIAorICAgICAKICAgPC9yZWZzZWN0MT4KICAgCiAg
IDxyZWZzZWN0MSBpZD0iUjEtU1FMLUNSRUFURUZVTkNUSU9OLTQiPgoqKioqKioqKioqKioq
KioKKioqIDI4MywyOTAgKioqKgogICAgICBTUUwvUFNNIDxjb21tYW5kPkNSRUFURSBGVU5D
VElPTjwvY29tbWFuZD4gaGFzIHRoZSBmb2xsb3dpbmcgc3ludGF4OgogICAgICA8c3lub3Bz
aXM+CiAgQ1JFQVRFIEZVTkNUSU9OIDxyZXBsYWNlYWJsZSBjbGFzcz0icGFyYW1ldGVyIj5u
YW1lPC9yZXBsYWNlYWJsZT4KISAgICAgKCBbIFsgSU4gfCBPVVQgfCBJTk9VVCBdIDxyZXBs
YWNlYWJsZSBjbGFzcz0icGFyYW1ldGVyIj5ldGVyPC9yZXBsYWNlYWJsZT5lYWJsZT5lYWJs
ZT4gPHJlcGxhY2VhYmxlCiEgICAgICAgY2xhc3M9InBhcmFtZXRlciI+dHlwZTwvcmVwbGFj
ZWFibGU+IFssIC4uLl0gXSApCiAgICAgICBSRVRVUk5TIDxyZXBsYWNlYWJsZSBjbGFzcz0i
cGFyYW1ldGVyIj5ydHlwZTwvcmVwbGFjZWFibGU+CiAgICAgICBMQU5HVUFHRSAnPHJlcGxh
Y2VhYmxlIGNsYXNzPSJwYXJhbWV0ZXIiPmxhbmduYW1lPC9yZXBsYWNlYWJsZT4nCiAgICAg
ICBFU1BFQ0lGSUMgPHJlcGxhY2VhYmxlIGNsYXNzPSJwYXJhbWV0ZXIiPnJvdXRpbmU8L3Jl
cGxhY2VhYmxlPgotLS0gMzM0LDM0MCAtLS0tCiAgICAgIFNRTC9QU00gPGNvbW1hbmQ+Q1JF
QVRFIEZVTkNUSU9OPC9jb21tYW5kPiBoYXMgdGhlIGZvbGxvd2luZyBzeW50YXg6CiAgICAg
IDxzeW5vcHNpcz4KICBDUkVBVEUgRlVOQ1RJT04gPHJlcGxhY2VhYmxlIGNsYXNzPSJwYXJh
bWV0ZXIiPm5hbWU8L3JlcGxhY2VhYmxlPgohICAgICAoIFsgWyBJTiB8IE9VVCB8IElOT1VU
IF0gPHJlcGxhY2VhYmxlIGNsYXNzPSJwYXJhbWV0ZXIiPnR5cGU8L3JlcGxhY2VhYmxlPiBb
LCAuLi5dIF0gKQogICAgICAgUkVUVVJOUyA8cmVwbGFjZWFibGUgY2xhc3M9InBhcmFtZXRl
ciI+cnR5cGU8L3JlcGxhY2VhYmxlPgogICAgICAgTEFOR1VBR0UgJzxyZXBsYWNlYWJsZSBj
bGFzcz0icGFyYW1ldGVyIj5sYW5nbmFtZTwvcmVwbGFjZWFibGU+JwogICAgICAgRVNQRUNJ
RklDIDxyZXBsYWNlYWJsZSBjbGFzcz0icGFyYW1ldGVyIj5yb3V0aW5lPC9yZXBsYWNlYWJs
ZT4KKioqIC4vZG9jL3NyYy9zZ21sL3hmdW5jLnNnbWwub3JpZwlUaHUgU2VwIDE2IDExOjUy
OjMxIDE5OTkKLS0tIC4vZG9jL3NyYy9zZ21sL3hmdW5jLnNnbWwJVGh1IFNlcCAxNiAxMjoy
MzoxMiAxOTk5CioqKioqKioqKioqKioqKgoqKiogMzU3LDM4MSAqKioqCiAgICAgPHRpdGxl
PkNvbXBpbGVkIChDKSBMYW5ndWFnZSBGdW5jdGlvbnM8L3RpdGxlPgogIAogICAgIDxwYXJh
PgohICAgICBGdW5jdGlvbnMgd3JpdHRlbiBpbiBDIGNhbiBiZSBkZWZpbmVkIHRvIFBvc3Rn
cmVzLCB3aGljaCB3aWxsIGR5bmFtaWNhbGx5CiEgICAgIGxvYWQgdGhlbSBpbnRvIGl0cyBh
ZGRyZXNzIHNwYWNlLiAgVGhlIEFTCiEgICAgIGNsYXVzZSBnaXZlcyB0aGUgZnVsbCBwYXRo
IG5hbWUgb2YgdGhlIG9iamVjdCBmaWxlIHRoYXQgY29udGFpbnMgdGhlCiEgICAgIGZ1bmN0
aW9uLiAgVGhpcyBmaWxlIGlzIGxvYWRlZCBlaXRoZXIgdXNpbmcKISAgICAgbG9hZChsKQoh
ICAgICBvciBhdXRvbWF0aWNhbGx5IHRoZSBmaXJzdCB0aW1lIHRoZSBmdW5jdGlvbiBpcyBu
ZWNlc3NhcnkgZm9yCiEgICAgIGV4ZWN1dGlvbi4gUmVwZWF0ZWQgZXhlY3V0aW9uIG9mIGEg
ZnVuY3Rpb24gd2lsbCBjYXVzZSBuZWdsaWdpYmxlCiEgICAgIGFkZGl0aW9uYWwgb3Zlcmhl
YWQsIGFzIHRoZSBmdW5jdGlvbiB3aWxsIHJlbWFpbiBpbiBhIG1haW4gbWVtb3J5CiEgICAg
IGNhY2hlLgogICAgIDwvcGFyYT4KICAKICAgICA8cGFyYT4KISAgICAgVGhlIHN0cmluZyB3
aGljaCBzcGVjaWZpZXMgdGhlIG9iamVjdCBmaWxlICh0aGUgc3RyaW5nIGluIHRoZSBBUyBj
bGF1c2UpCiEgICAgIHNob3VsZCBiZSB0aGUgPGVtcGhhc2lzPmZ1bGwgcGF0aDwvZW1waGFz
aXM+CiEgICAgIG9mIHRoZSBvYmplY3QgY29kZSBmaWxlIGZvciB0aGUgZnVuY3Rpb24sIGJy
YWNrZXRlZCBieSBxdW90YXRpb24KISAgICAgbWFya3MuICAoPHByb2R1Y3RuYW1lPlBvc3Rn
cmVzPC9wcm9kdWN0bmFtZT4gd2lsbCBub3QgY29tcGlsZSBhCiEgICAgIGZ1bmN0aW9uIGF1
dG9tYXRpY2FsbHk7IGl0IG11c3QKISAgICAgYmUgY29tcGlsZWQgYmVmb3JlIGl0IGlzIHVz
ZWQgaW4gYSBDUkVBVEUgRlVOQ1RJT04KISAgICAgY29tbWFuZC4gIFNlZSBiZWxvdyBmb3Ig
YWRkaXRpb25hbCBpbmZvcm1hdGlvbi4pCiAgICAgPC9wYXJhPgogIAogICAgIDxzZWN0Mj4K
LS0tIDM1NywzOTkgLS0tLQogICAgIDx0aXRsZT5Db21waWxlZCAoQykgTGFuZ3VhZ2UgRnVu
Y3Rpb25zPC90aXRsZT4KICAKICAgICA8cGFyYT4KISAgICAgRnVuY3Rpb25zIHdyaXR0ZW4g
aW4gQyBjYW4gYmUgY29tcGlsZWQgaW50byBkeW5hbWljYWxseSBsb2FkYWJsZQohICAgICBv
YmplY3RzLCBhbmQgdXNlZCB0byBpbXBsZW1lbnQgdXNlci1kZWZpbmVkIFNRTCBmdW5jdGlv
bnMuICBUaGUKISAgICAgZmlyc3QgdGltZSB0aGUgdXNlciBkZWZpbmVkIGZ1bmN0aW9uIGlz
IGNhbGxlZCBpbnNpZGUgdGhlIGJhY2tlbmQsCiEgICAgIHRoZSBkeW5hbWljIGxvYWRlciBs
b2FkcyB0aGUgZnVuY3Rpb24ncyBvYmplY3QgY29kZSBpbnRvIG1lbW9yeSwKISAgICAgYW5k
IGxpbmtzIHRoZSBmdW5jdGlvbiB3aXRoIHRoZSBydW5uaW5nCiEgICAgIDxwcm9kdWN0bmFt
ZT5Qb3N0Z3JlczwvcHJvZHVjdG5hbWU+IGV4ZWN1dGFibGUuICBUaGUgU1FMIHN5bnRheAoh
ICAgICBmb3IgdGhlIDx4cmVmIGxpbmtlbmQ9InNxbC1jcmVhdGVmdW5jdGlvbi10aXRsZSIK
ISAgICAgZW5kdGVybT0ic3FsLWNyZWF0ZWZ1bmN0aW9uLXRpdGxlIj4gY29tbWFuZCBsaW5r
cyB0aGUgU1FMIGZ1bmN0aW9uCiEgICAgIHRvIHRoZSBDIHNvdXJjZSBmdW5jdGlvbiBpbiBv
bmUgb2YgdHdvIHdheXMuIElmIHRoZSBTUUwgZnVuY3Rpb24KISAgICAgaGFzIHRoZSBzYW1l
IG5hbWUgYXMgdGhlIEMgc291cmNlIGZ1bmN0aW9uIHRoZSBmaXJzdCBmb3JtIG9mIHRoZQoh
ICAgICBzdGF0ZW1lbnQgaXMgdXNlZC4gVGhlIHN0cmluZyBhcmd1bWVudCBpbiB0aGUgQVMg
Y2xhdXNlIGlzIHRoZQohICAgICBmdWxsIHBhdGhuYW1lIG9mIHRoZSBmaWxlIHRoYXQgY29u
dGFpbnMgdGhlIGR5bmFtaWNhbGx5IGxvYWRhYmxlCiEgICAgIGNvbXBpbGVkIG9iamVjdC4g
IElmIHRoZSBuYW1lIG9mIEMgZnVuY3Rpb24gaXMgZGlmZmVyZW50IGZyb20gdGhlCiEgICAg
IG5hbWUgb2YgdGhlIFNRTCBmdW5jdGlvbiwgdGhlbiB0aGUgc2Vjb25kIGZvcm0gaXMgdXNl
ZC4gSW4gdGhpcwohICAgICBmb3JtIHRoZSBBUyBjbGF1c2UgdGFrZXMgdHdvIHN0cmluZyBh
cmd1bWVudHMsIHRoZSBmaXJzdCBpcyB0aGUKISAgICAgZnVsbCBwYXRobmFtZSBvZiB0aGUg
ZHluYW1pY2FsbHkgbG9hZGFibGUgb2JqZWN0IGZpbGUsIGFuZCB0aGUKISAgICAgc2Vjb25k
IGlzIHRoZSBsaW5rIHN5bWJvbCB0aGF0IHRoZSBkeW5hbWljIGxvYWRlciBzaG91bGQgc2Vh
cmNoCiEgICAgIGZvci4gVGhpcyBsaW5rIHN5bWJvbCBpcyBqdXN0IHRoZSBmdW5jdGlvbiBu
YW1lIGluIHRoZSBDIHNvdXJjZQohICAgICBjb2RlLgohIAohIAlBZnRlciBpdCBpcyB1c2Vk
IGZvciB0aGUgZmlyc3QgdGltZSwgYSBkeW5hbWljYWxseSBsb2FkZWQsIHVzZXIKISAJZnVu
Y3Rpb24gaXMgcmV0YWluZWQgaW4gbWVtb3J5LCBhbmQgZnV0dXJlIGNhbGxzIHRvIHRoZSBm
dW5jdGlvbgohIAlvbmx5IGluY3VyIHRoZSBzbWFsbCBvdmVyaGVhZCBvZiBhIHN5bWJvbCB0
YWJsZSBsb29rdXAuCiAgICAgPC9wYXJhPgogIAogICAgIDxwYXJhPgohICAgICBUaGUgc3Ry
aW5nIHdoaWNoIHNwZWNpZmllcyB0aGUgb2JqZWN0IGZpbGUgKHRoZSBzdHJpbmcgaW4gdGhl
IEFTCiEgICAgIGNsYXVzZSkgc2hvdWxkIGJlIHRoZSA8ZW1waGFzaXM+ZnVsbCBwYXRoPC9l
bXBoYXNpcz4gb2YgdGhlIG9iamVjdAohICAgICBjb2RlIGZpbGUgZm9yIHRoZSBmdW5jdGlv
biwgYnJhY2tldGVkIGJ5IHF1b3RhdGlvbiBtYXJrcy4gIElmIGEKISAgICAgbGluayBzeW1i
b2wgaXMgdXNlZCBpbiB0aGUgQVMgY2xhdXNlLCB0aGUgbGluayBzeW1ib2wgc2hvdWxkIGFs
c28gYmUKISAgICAgYnJhY2tldGVkIGJ5IHNpbmdsZSBxdW90YXRpb24gbWFya3MsIGFuZCBz
aG91bGQgYmUgZXhhY3RseSB0aGUKISAgICAgc2FtZSBhcyB0aGUgbmFtZSBvZiBmdW5jdGlv
biBpbiB0aGUgQyBzb3VyY2UgY29kZS4gT24gVU5JWCBzeXN0ZW1zCiEgICAgIHRoZSBjb21t
YW5kIDxjb21tYW5kPm5tPC9jb21tYW5kPiB3aWxsIHByaW50IGFsbCBvZiB0aGUgbGluawoh
ICAgICBzeW1ib2xzIGluIGEgZHluYW1pY2FsbHkgbG9hZGFibGUgb2JqZWN0LgohICAgICAo
PHByb2R1Y3RuYW1lPlBvc3RncmVzPC9wcm9kdWN0bmFtZT4gd2lsbCBub3QgY29tcGlsZSBh
IGZ1bmN0aW9uCiEgICAgIGF1dG9tYXRpY2FsbHk7IGl0IG11c3QgYmUgY29tcGlsZWQgYmVm
b3JlIGl0IGlzIHVzZWQgaW4gYSBDUkVBVEUKISAgICAgRlVOQ1RJT04gY29tbWFuZC4gIFNl
ZSBiZWxvdyBmb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbi4pCiAgICAgPC9wYXJhPgogIAog
ICAgIDxzZWN0Mj4KKioqKioqKioqKioqKioqCioqKiA5NjAsOTY5ICoqKioKICAgICAgPHRp
dGxlPk5hbWUgU3BhY2UgQ29uZmxpY3RzPC90aXRsZT4KICAKICAgICAgPHBhcmE+CiEgICAg
ICBBcyBvZiA8cHJvZHVjdG5hbWU+UG9zdGdyZXM8L3Byb2R1Y3RuYW1lPiB2Ni41LAohICAg
ICAgPGNvbW1hbmQ+Q1JFQVRFIEZVTkNUSU9OPC9jb21tYW5kPiBjYW4gZGVjb3VwbGUgYSBD
IGxhbmd1YWdlCiEgICAgICBmdW5jdGlvbiBuYW1lIGZyb20gdGhlIG5hbWUgb2YgdGhlIGVu
dHJ5IHBvaW50LiBUaGlzIGlzIG5vdyB0aGUKISAgICAgIHByZWZlcnJlZCB0ZWNobmlxdWUg
dG8gYWNjb21wbGlzaCBmdW5jdGlvbiBvdmVybG9hZGluZy4KICAgICAgPC9wYXJhPgogIAog
ICAgICA8c2VjdDM+Ci0tLSA5NzgsOTkwIC0tLS0KICAgICAgPHRpdGxlPk5hbWUgU3BhY2Ug
Q29uZmxpY3RzPC90aXRsZT4KICAKICAgICAgPHBhcmE+CiEgICAgICBBcyBvZiA8cHJvZHVj
dG5hbWU+UG9zdGdyZXM8L3Byb2R1Y3RuYW1lPiB2Ni42LCB0aGUgYWx0ZXJuYXRpdmUKISAJ
IGZvcm0gb2YgdGhlIEFTIGNsYXVzZSBmb3IgdGhlIFNRTCA8Y29tbWFuZD5DUkVBVEUKISAJ
IEZVTkNUSU9OPC9jb21tYW5kPiBjb21tYW5kIGRlc2NyaWJlZCBpbiA8eHJlZgohIAkgbGlu
a2VuZD0ic3FsLWNyZWF0ZWZ1bmN0aW9uLXRpdGxlIiBlbmR0ZXJtPSJzcWwtY3JlYXRlZnVu
Y3Rpb24tdGl0bGUiPgohIAkgZGVjb3VwbGVzIHRoZSBTUUwgZnVuY3Rpb24gbmFtZSBmcm9t
IHRoZSBmdW5jdGlvbiBuYW1lIGluIHRoZSBDCiEgCSBzb3VyY2UgY29kZS4gVGhpcyBpcyBu
b3cgdGhlIHByZWZlcnJlZCB0ZWNobmlxdWUgdG8gYWNjb21wbGlzaAohIAkgZnVuY3Rpb24g
b3ZlcmxvYWRpbmcuCiAgICAgIDwvcGFyYT4KICAKICAgICAgPHNlY3QzPgoqKiogLi9zcmMv
YmluL3BzcWwvcHNxbEhlbHAuaC5vcmlnCVRodSBTZXAgMTYgMTE6NTM6NTAgMTk5OQotLS0g
Li9zcmMvYmluL3BzcWwvcHNxbEhlbHAuaAlUaHUgU2VwIDE2IDEyOjIzOjEyIDE5OTkKKioq
KioqKioqKioqKioqCioqKiA4OCw5NSAqKioqCiAgCQkiY3JlYXRlIGEgdXNlci1kZWZpbmVk
IGZ1bmN0aW9uIiwKICAJIlwKICBcdENSRUFURSBGVU5DVElPTiBmdW5jdGlvbl9uYW1lIChb
dHlwZTEsIC4uLnR5cGVOXSkgUkVUVVJOUyByZXR1cm5fdHlwZVxuXAohIFx0QVMgJ29iamVj
dF9maWxlbmFtZSd8J3NxbC1xdWVyaWVzJ3wnYnVpbHRpbl9mdW5jdGlvbl9uYW1lJ1xuXAoh
IFx0TEFOR1VBR0UgJ2MnfCdzcWwnfCdpbnRlcm5hbCc7In0sCiAgCXsiY3JlYXRlIGluZGV4
IiwKICAJCSJjb25zdHJ1Y3QgYW4gaW5kZXgiLAogIAkiXAotLS0gODgsMTAxIC0tLS0KICAJ
CSJjcmVhdGUgYSB1c2VyLWRlZmluZWQgZnVuY3Rpb24iLAogIAkiXAogIFx0Q1JFQVRFIEZV
TkNUSU9OIGZ1bmN0aW9uX25hbWUgKFt0eXBlMSwgLi4udHlwZU5dKSBSRVRVUk5TIHJldHVy
bl90eXBlXG5cCiEgXHRBUyAnc3FsLXF1ZXJpZXMnfCdidWlsdGluX2Z1bmN0aW9uX25hbWUn
fCdvYmplY3RfZmlsZW5hbWUnXG5cCiEgXHRMQU5HVUFHRSAnc3FsJ3wnaW50ZXJuYWwnfCdj
JztcblwKISBcblwKISBPUlxuXAohIFxuXAohIFx0Q1JFQVRFIEZVTkNUSU9OIGZ1bmN0aW9u
X25hbWUgKFt0eXBlMSwgLi4udHlwZU5dKSBSRVRVUk5TIHJldHVybl90eXBlXG5cCiEgXHRB
UyAnb2JqZWN0X2ZpbGVuYW1lJywgJ2xpbmtfc3ltYm9sJ1xuXAohIFx0TEFOR1VBR0UgJ2Mn
OyJ9LAogIAl7ImNyZWF0ZSBpbmRleCIsCiAgCQkiY29uc3RydWN0IGFuIGluZGV4IiwKICAJ
IlwK
--------------272B4C7116F8BBC6673AA8FF--
From bouncefilter Thu Sep 16 15:38:45 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA63005
for <pgsql-hackers@postgreSQL.org>;
Thu, 16 Sep 1999 15:37:45 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id PAA07323;
Thu, 16 Sep 1999 15:37:46 -0400
Message-ID: <37E14701.EE79FA45@wgcr.org>
Date: Thu, 16 Sep 1999 15:37:37 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <Pine.LNX.4.10.9909151845000.30766-100000@excelsior.rkirkpat.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ryan Kirkpatrick wrote:
Ok, I will do so this weekend, providing there are not too many
things broken. I will let you know on Monday what the status is. :)
The current tarball is 6.5.2RC (for Release Candidate). AFAIK, this
will become the release of 6.5.2, unless there are problems.
Thanks much!
Good to hear, and you are welcome! Hopefully by 6.6 the patches
will not be needed and Linux/Alpha will finally be a fully supported pgsql
platform!
Yes! Now if I just HAD one.... ;-)
PS. Now that I made people at RedHat happy, can I get some of
thier stock? :) **Just kidding**
ROTFL.... I _wish_...
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Thu Sep 16 21:06:01 1999
Received: from web129.yahoomail.com (web129.yahoomail.com [205.180.60.198])
by hub.org (8.9.3/8.9.3) with SMTP id VAA37893
for <pgsql-hackers@postgresql.org>;
Thu, 16 Sep 1999 21:05:14 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19990917010618.13322.rocketmail@web129.yahoomail.com>
Received: from [206.246.185.100] by web129.yahoomail.com;
Thu, 16 Sep 1999 18:06:18 PDT
Date: Thu, 16 Sep 1999 18:06:18 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: TRUNCATE TABLE patch
To: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
I submitted a patch to the patches list several
months ago which implemented Oracle's TRUNCATE TABLE
statement in PostgreSQL and was wondering whether or
not the patch was going to make it into current. I had
the patch ready before the 6.5 release but 6.5 was
already in beta at the time, so I waited until the
6.5 tree was split.
Recent discussions with regard to the functioning of
DROP TAPLE in transactions and changing heap_openr()
to require a locking type affect the nature of the
patch. TRUNCATE TABLE behaves like Oracle's DDL
statements by committing the running transaction and
starting a new one for the TRUNCATE operation
(which generates no rollback information), or, as
Bruce Momjian puts it "cheating".
Any news?
Just curious,
Mike Mascari
(mascarim@yahoo.com)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
From bouncefilter Thu Sep 16 21:37:55 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA44420
for <pgsql-hackers@postgreSQL.org>;
Thu, 16 Sep 1999 21:37:25 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id KAA10471 for <pgsql-hackers@postgreSQL.org>;
Fri, 17 Sep 1999 10:37:22 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: couldn't rollback cache ?
Date: Fri, 17 Sep 1999 10:40:48 +0900
Message-ID: <000501bf00ad$aacd80c0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Hello all,
Cache invalidation mechanism was much improved.
Thanks to Tom.
But as far as I see,neither relation cache nor system catalog cache
aren't be rollbacked correctly.
This should be solved if we would execute DDL statement inside
transactions.
For example,
create table t1 (id int4);
CREATE
begin;
BEGIN
alter table t1 add column dt1 text;
ADD
select * from t1;
id|dt1
--+---
(0 rows)
abort;
ABORT
visco=> select * from t1;
id|dt1
--+---
(0 rows)
I added time_qualification_check to SearchSysCache() on trial
(see the patch at the end of this posting).
After this change,
.
.
abort;
ABORT
select * from t1;
ERROR: Relation t1 does not have attribute dt1
Seems relation cache is not invalidated yet.
I also tried to add time_qualification_check to RelationId(Name)-
CacheGetRelation(). But unfortunately,Relation doesn't have
such a information.
Any ideas ?
Comments ?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
*** utils/cache/catcache.c.orig Mon Jul 26 12:45:14 1999
--- utils/cache/catcache.c Fri Sep 17 08:57:50 1999
***************
*** 872,878 ****
cache->cc_skey,
res);
if (res)
! break;
} /* ----------------
--- 872,881 ----
cache->cc_skey,
res);
if (res)
! {
! if (HeapTupleSatisfiesNow(ct->ct_tup->t_data))
! break;
! }
}/* ----------------
From bouncefilter Thu Sep 16 21:58:56 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA49371
for <pgsql-hackers@postgreSQL.org>;
Thu, 16 Sep 1999 21:57:58 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id VAA21525;
Thu, 16 Sep 1999 21:49:31 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909170149.VAA21525@candle.pha.pa.us>
Subject: Re: attdisbursion
In-Reply-To: <33FD3D88.61133CF4@sable.krasnoyarsk.su> from "Vadim B. Mikheev"
at "Aug 22, 1997 03:19:36 pm"
To: "Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>
Date: Thu, 16 Sep 1999 21:49:31 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Added to TODO. This will improve VACUUM ANALYZE performance, thought I
don't think we have btree comparison functions for all data types,
though we should:
* change VACUUM ANALYZE to use btree comparison functions, not <,=,> calls
Also, I have idea about using '<' '>' in vacuum:
what if try to use btree BT_ORDER functions which allow
to compare vals for many data types (btXXXcmp functions in
nbtcompare.c).I see, use a btree index to tell use how selective the > or < is? An
interesting idea. Isn't there a significant performance problem with
this?Don't use btree index, but use btree functions to compare
two values of a datatype. You call
func_operator = oper("<",...
"="
">"
but this's not right way in common case: operators may be
overloaded.These functions are stored in catalog.
To get function for a datatype btree callproc = index_getprocid(rel, 1, BTORDER_PROC);
Look @ nbtcompare.c:
* These functions are stored in pg_amproc. For each operator class
* defined on btrees, they compute
*
* compare(a, b):
* < 0 if a < b,
* = 0 if a == b,
* > 0 if a > b.There are functions for INTs, FLOATs, ...
...But this is not so important thing...
Vadim
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Thu Sep 16 21:54:56 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA48510
for <pgsql-hackers@postgreSQL.org>;
Thu, 16 Sep 1999 21:54:23 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA28371
for <pgsql-hackers@postgreSQL.org>;
Thu, 16 Sep 1999 21:53:52 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: pgaccess seems a tad confused
Date: Thu, 16 Sep 1999 21:53:52 -0400
Message-ID: <28368.937533232@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
1. Why did the new pgaccess get installed into REL6_5 branch but not
main development branch?
2. New pgaccess no longer has a Makefile in src/bin/pgaccess, which
is a problem because src/bin/Makefile tries to run a sub-make in that
directory when configured --with-tcl. Lack of the sub-Makefile looks
bogus to me; it may not need to do anything for "make all" but it sure
ought to do something for "make install", no?
regards, tom lane
From bouncefilter Fri Sep 17 00:12:58 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA87304
for <pgsql-hackers@postgresql.org>;
Fri, 17 Sep 1999 00:12:13 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id AAA06957;
Fri, 17 Sep 1999 00:11:46 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909170411.AAA06957@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess seems a tad confused
In-Reply-To: <28368.937533232@sss.pgh.pa.us> from Tom Lane at "Sep 16,
1999 09:53:52 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 17 Sep 1999 00:11:46 -0400 (EDT)
CC: pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
1. Why did the new pgaccess get installed into REL6_5 branch but not
main development branch?
No sense putting in development because there will probably be a newer
version by the time 6.6 is released, no?
2. New pgaccess no longer has a Makefile in src/bin/pgaccess, which
is a problem because src/bin/Makefile tries to run a sub-make in that
directory when configured --with-tcl. Lack of the sub-Makefile looks
bogus to me; it may not need to do anything for "make all" but it sure
ought to do something for "make install", no?
Yes. I was not in favor of adding new pgaccess in 6.5.2, but was
out-voted.
I have re-added the Makefile that appeared in the development tree.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sep 17 00:47:59 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA93662;
Fri, 17 Sep 1999 00:47:41 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id AAA07310;
Fri, 17 Sep 1999 00:45:49 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909170445.AAA07310@candle.pha.pa.us>
Subject: Re: [QUESTIONS] errors on transactions and locks ?
In-Reply-To: <Pine.LNX.3.96.980422113809.1139A-100000@proxy.bazzanese.com>
from
"Jose' Soares Da Silva" at "Apr 22, 1998 11:39:51 am"
To: "Jose' Soares Da Silva" <sferac@proxy.bazzanese.com>
Date: Fri, 17 Sep 1999 00:45:49 -0400 (EDT)
CC: Herouth Maoz <herouth@oumail.openu.ac.il>,
questions postgres <pgsql-questions@postgreSQL.org>,
hackers postgres <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I think 6.6 will improve this.
On Tue, 21 Apr 1998, Herouth Maoz wrote:
Your example is very exhaustive Herouth. I tried it with SOLID and in fact
it leaves SOLID database inconsistent.I see that PostgreSQL BEGIN/END statements are slight different from SQL
transactions that begins with a implicit begin transaction (no BEGIN command)
and ends with a ROLLBACK or COMMIT statement.Until now I thought that END was equal to COMMIT but in the case of:
NOTICE: (transaction aborted): queries ignored until END
*ABORT STATE*
in this case END stands for ROLLBACK/ABORT I think it isn't enough clear.
(I thought all reference to END were changed to COMMIT).
PostgreSQL don't say to the user that all his work will be lost even if he do
COMMIT.Maybe the following warn is more clear:
NOTICE: (transaction aborted): queries ignored until COMMIT/ROLLBAK
WARN: all changes will be lost even if you use COMMIT.Of course SQL transaction allows all kind of SQL command because it doesn't
works outside transactions.PostgreSQL is more restrictive than SQL, then I think we need to know
what kind of statements we can use successful inside transactions and
PostgreSQL should reject all invalid commands.(I have to change information on BEGIN reference manual page, we have to
document this feature of PostgreSQL).I've tried the following commands:
o CREATE TABLE works.
o DROP TABLE doesn't work properly after ROLLBACK, the table lives
but it's empty.
o CREATE/DROP INDEX works.
o CREATE/DROP SEQUENCE works.
o CREATE/DROP USER works.
o GRANT/REVOKE works.
o DROP VIEW works.
o CREATE VIEWS aborts transactions see below:
o DROP AGGREGATE works.
o CREATE AGGREGATE doesn't work.
o DROP FUNCTION works.
o CREATE FUNCTION doesn't work.
o ALTER TABLE seems that doesn't work properly see below:
o CREATE/DROP DATABASE removes references from "pg_database" but
don't remove directory /usr/local/pgsql/data/base/name_database.
...Maybe somebody knows what more is valid/invalid inside transactions...o EXAMPLE ALTER TABLE:
postgres=> begin;
BEGIN
postgres=> \d aTable = a +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ | a | int2 | 2 | +----------------------------------+----------------------------------+-------+ postgres=> select * from a; a ----- 32767 (1 rows) postgres=> alter table a add b int; ADD postgres=> \d aTable = a +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ | a | int2 | 2 | | b | int4 | 4 | +----------------------------------+----------------------------------+-------+ postgres=> select * from a; a|b -----+- 32767| (1 rows)postgres=> rollback;
ABORT
postgres=> \d aTable = a +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ | a | int2 | 2 | +----------------------------------+----------------------------------+-------+ postgres=> select * from a; a|b <------------------ column b is already here. Why ? -----+- 32767| (1 rows) postgres=> rollback; ABORT postgres=> \d aTable = a +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ | a | int2 | 2 | +----------------------------------+----------------------------------+-------+ postgres=> select * from a; a|b -----+- 32767| (1 rows)o EXAMPLE CREATE VIEW:
postgres=> begin;
BEGIN
postgres=> create view error as select * from films;
CREATE
postgres=> \d errorTable = error +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ | code | char() | 5 | | title | varchar() | 40 | | did | int4 | 4 | | date_prod | date | 4 | | kind | char() | 10 | | len | int2 | 2 | +----------------------------------+----------------------------------+-------+ postgres=> select * from error; PQexec() -- Request was sent to backend, but backend closed the channel before responding. This probably means the backend terminated abnormally before or while processing the request.At 16:15 +0100 on 21/4/98, Jose' Soares Da Silva wrote:
* Bad, this isn't very friendly.
* No. What I would is that PostgreSQL don't abort at every smallest
syntax error.It depends on what you expect from a transaction. The way I see it, a
transaction is a sequence of operations which either *all* succeed, or
*all* fail. That is, if one of the operations failed, even for a syntax
error, Postgres should not allow any of the other operations in the same
transaction to work.For example, suppose you want to move money from one bank account to
another, you'll do something like:BEGIN;
UPDATE accounts
SET credit = credit - 20,000
WHERE account_num = '00-xx-00';UPDATE accounts
SET credit = credit + 20000
WHERE account_num = '11-xx-11';END;
Now, look at this example. There is a syntax error in the first update
statement - 20,000 should be without a comma. If Postgres were tolerant,
your client would have an extra 20,000 dollars in one of his account, and
the money came from nowhere, which means your bank loses it, and you lose
your job...But a real RDBMS, as soon as one of the statement fails - no matter why -
the transaction would not happen. It notifies you that it didn't happen.
You can then decide what to do - issue a different transaction, fix the
program, whatever.The idea is that the two actions (taking money from one account and putting
it in another) are considered atomic, inseparable, and dependent. If your
"real world" thinking says that the next operation should happen, no matter
if the first one succeeded or failed, then they shouldn't be inside the
same transaction.Herouth
--
Official WWW Site: http://www.postgresql.org
Online Docs & FAQ: http://www.postgresql.org/docs
Searchable Lists: http://www.postgresql.org/mhonarc
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sep 17 01:58:59 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA03923
for <hackers@postgreSQL.org>; Fri, 17 Sep 1999 01:58:54 -0400 (EDT)
(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 FAA00248;
Fri, 17 Sep 1999 05:58:20 GMT
Sender: lockhart@hub.org
Message-ID: <37E1D87B.DA85C685@alumni.caltech.edu>
Date: Fri, 17 Sep 1999 05:58:19 +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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Join syntax
References: <22127.937490977@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
... represent general subqueries or intermediate queries in the
parse tree.Maybe it's time to bite the bullet and do it. You have any thoughts
on what the representation should look like?
I was hoping you would tell me ;)
I don't have a good feel for the current parse tree (which of course
hasn't kept me from fooling around with it). But I'll definitely need
something extra or different to implement outer joins. If I were
keeping everything else the same, I was thinking of propagating a
"join expression" into the planner/optimizer in the same area as the
existing qualification nodes. One of the differences would be that the
JE marks a node around which the optimizer is not allowed to reorder
the plan (since outer joins must be evaluated in a specific order to
get the right result). But I could just as easily represent this as a
subquery node somewhere else in the parse tree.
afaik the planner/optimizer already has the notion of
merging/joining/scanning intermediate results, so teaching it to
invoke these explicitly from the query tree rather than just
implicitly may not be a huge stretch.
btw I'm currently rewriting the join syntax in gram.y to conform
better to a closer reading of the SQL92 standard. One annoyance is
that the standard allows table *and* column aliasing *everywhere*.
e.g.
select * from (t1 as x1 (i,j,k) join t2 using (i)) as r1 (a,b,c,d)
is (apparently) legal syntax, resulting in rows labeled a-d. Ugh.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Sep 17 02:18:59 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA06997
for <hackers@postgreSQL.org>; Fri, 17 Sep 1999 02:18:39 -0400 (EDT)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id OAA04163;
Fri, 17 Sep 1999 14:15:13 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E1DC71.94327D69@krs.ru>
Date: Fri, 17 Sep 1999 14:15:13 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Tom Lane <tgl@sss.pgh.pa.us>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Join syntax
References: <22127.937490977@sss.pgh.pa.us>
<37E1D87B.DA85C685@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
... represent general subqueries or intermediate queries in the
parse tree.Maybe it's time to bite the bullet and do it. You have any thoughts
on what the representation should look like?I was hoping you would tell me ;)
I don't have a good feel for the current parse tree (which of course
hasn't kept me from fooling around with it). But I'll definitely need
something extra or different to implement outer joins. If I were
keeping everything else the same, I was thinking of propagating a
"join expression" into the planner/optimizer in the same area as the
existing qualification nodes. One of the differences would be that the
JE marks a node around which the optimizer is not allowed to reorder
^^^^^^^^^^^^^^^^^^^^^^^^^
the plan (since outer joins must be evaluated in a specific order to
^^^^^^^^
get the right result). But I could just as easily represent this as a
And this is what we need to have subqueries in FROM!..
(One a great thing which I want to have so much -:))
subquery node somewhere else in the parse tree.
Vadim
From bouncefilter Fri Sep 17 02:49:59 1999
Received: from flame.flame.co.za (flame.flame.co.za [160.124.170.1])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA11198
for <pgsql-hackers@postgreSQL.org>;
Fri, 17 Sep 1999 02:49:47 -0400 (EDT)
(envelope-from theo@flame.co.za)
Received: from flame.co.za (flame [160.124.170.1])
by flame.flame.co.za (8.8.7/8.8.7) with ESMTP id IAA02048
for <pgsql-hackers@postgreSQL.org>; Fri, 17 Sep 1999 08:53:53 +0200
Sender: theo@flame.flame.co.za
Message-ID: <37E1E580.A7C66E57@flame.co.za>
Date: Fri, 17 Sep 1999 08:53:52 +0200
From: Theo Kramer <theo@flame.co.za>
Organization: Flame Computing Enterprises
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.35 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <Pine.LNX.4.10.9909151845000.30766-100000@excelsior.rkirkpat.net>
<37E14701.EE79FA45@wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lamar Owen wrote:
Ryan Kirkpatrick wrote:
Ok, I will do so this weekend, providing there are not too many
things broken. I will let you know on Monday what the status is. :)The current tarball is 6.5.2RC (for Release Candidate). AFAIK, this
will become the release of 6.5.2, unless there are problems.Thanks much!
Good to hear, and you are welcome! Hopefully by 6.6 the patches
will not be needed and Linux/Alpha will finally be a fully supported pgsql
platform!Yes! Now if I just HAD one.... ;-)
Dont know if it's been raised before, but the postgres utilities are installed
into /usr/bin from the rpm. Problem with this is the naming of some of the
utilities eg.createuser, destroyuser. These could be confused with the
'standard' user utilities such as useradd, userdel etc. How about pre-pending
a 'pg' to all postgres utilities so that these become pgcreateuser,
pgdestroyuser etc.?
--------
Regards
Theo
From bouncefilter Fri Sep 17 02:55:59 1999
Received: from volcano.DEFUDATA.DK ([195.97.164.2])
by hub.org (8.9.3/8.9.3) with SMTP id CAA12369
for <hackers@postgreSQL.org>; Fri, 17 Sep 1999 02:55:20 -0400 (EDT)
(envelope-from kar@webline.dk)
Received: from VOLCANO [195.97.164.2] (HELO localhost)
by volcano.DEFUDATA.DK (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_00fe_37e1_e5be_3dc8; Fri, 17 Sep 1999 08:54:54 +0200
Message-ID: <37E1E5B3.C1D36155@webline.dk>
Date: Fri, 17 Sep 1999 08:54:43 +0200
From: Kaare Rasmussen <kar@webline.dk>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgreSQL.org
Subject: Hierarchical query?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I may have missed some discussions, but I want to know if there are any
plans on implementing something like the hierarchical query that Oracle
has?
You know, this would greatly simplify the task of writing the accounting
system I'm planning :-)
From bouncefilter Fri Sep 17 06:41:02 1999
Received: from sun.med.ru (sun.med.ru [194.67.88.10])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA48020
for <pgsql-hackers@postgresql.org>;
Fri, 17 Sep 1999 06:39:35 -0400 (EDT) (envelope-from phd@sun.med.ru)
Received: (from phd@localhost) by sun.med.ru (8.8.5/8.8.7) id OAA19733;
Fri, 17 Sep 1999 14:38:45 +0400 (MSD)
Date: Fri, 17 Sep 1999 14:38:45 +0400 (MSD)
From: Oleg Broytmann <phd@sun.med.ru>
Reply-To: phd2@earthling.net
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
cc: Artem Chuprina <ran@pirit.com>
Subject: Bug
Message-ID: <Pine.SOL2.3.96.SK.990917143736.19731A-100000@sun.med.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
---------- Forwarded message ----------
Date: Fri, 17 Sep 1999 17:52:44 +0400 (MSD)
From: Artem Chuprina <ran@pirit.com>
ran=> create table test_source (src text);
CREATE
ran=> insert into test_source values('First distinct');
INSERT 235913 1
ran=> insert into test_source values('First distinct');
INSERT 235914 1
ran=> insert into test_source values('Second distinct');
INSERT 235915 1
ran=> insert into test_source values('Second distinct');
INSERT 235916 1
ran=> select src from test_source;
src
---------------
First distinct
First distinct
Second distinct
Second distinct
(4 rows)
ran=> select distinct src from test_source;
src
---------------
First distinct
Second distinct
(2 rows)
ran=> create sequence seq_test;
CREATE
ran=> create table test1 (n int default nextval('seq_test'), t text);
CREATE
ran=> create table test2 (n int, t text);
CREATE
ran=> insert into test2 ("t") select distinct src from test_source;
INSERT 0 2
ran=> insert into test1 ("t") select distinct src from test_source;
INSERT 0 4
Look here^
ran=> select * from test2;
n|t
-+---------------
|First distinct
|Second distinct
(2 rows)
ran=> select * from test1;
n|t
-+---------------
1|First distinct
2|First distinct
3|Second distinct
4|Second distinct
(4 rows)
PostgreSQL 6.4.2, PostgreSQL 6.5.1.
--
Artem Chuprina E-mail: ran@pirit.com
Network Administrator FIDO: 2:5020/371.32
PIRIT Corp. Phone: +7(095) 115-7101
From bouncefilter Fri Sep 17 06:51:02 1999
Received: from sid.trust.ee (ns.tm.ee [195.50.195.154])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA49680
for <hackers@postgreSQL.org>; Fri, 17 Sep 1999 06:50:53 -0400 (EDT)
(envelope-from hannu@trust.ee)
Received: from trust.ee (wink.trust.ee [194.106.111.151])
by sid.trust.ee (8.8.7/8.8.7) with ESMTP id NAA02136;
Fri, 17 Sep 1999 13:55:33 +0300
Message-ID: <37E21D71.A6BC36F9@trust.ee>
Date: Fri, 17 Sep 1999 13:52:33 +0300
From: Hannu Krosing <hannu@trust.ee>
X-Mailer: Mozilla 4.06 [en] (Win95; I)
MIME-Version: 1.0
To: Kaare Rasmussen <kar@webline.dk>,
"hackers@postgreSQL.org" <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Hierarchical query?
References: <37E1E5B3.C1D36155@webline.dk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Kaare Rasmussen wrote:
I may have missed some discussions, but I want to know if there are any
plans on implementing something like the hierarchical query that Oracle
has?
It should be in the TODO under some weird name derived from SQL3 docs ;)
You know, this would greatly simplify the task of writing the accounting
system I'm planning :-)
One more general approach would be to enable functions to return rowsets
like ordinary selects do, then it would be easy to write a function for
the above.
Currently it can be implemented using a function and temp tables, but it
gets a bit convoluted .
-------
Hannu
From bouncefilter Fri Sep 17 09:59:04 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA88902
for <pgsql-hackers@postgreSQL.org>;
Fri, 17 Sep 1999 09:58:08 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA29178;
Fri, 17 Sep 1999 09:57:33 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] couldn't rollback cache ?
In-reply-to: Your message of Fri, 17 Sep 1999 10:40:48 +0900
<000501bf00ad$aacd80c0$2801007e@cadzone.tpf.co.jp>
Date: Fri, 17 Sep 1999 09:57:33 -0400
Message-ID: <29176.937576653@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
But as far as I see,neither relation cache nor system catalog cache
aren't be rollbacked correctly.
I added time_qualification_check to SearchSysCache() on trial
(see the patch at the end of this posting).
Hmm. This must be a bug of very long standing; surprising it hasn't
been noticed before. I think you are probably right, because a little
glimpsing shows that SearchSysCache() is the *only* place in the whole
system where HeapKeyTest() is called directly --- everyone else goes
through HeapTupleSatisfies() which adds a timequal check of one sort or
another. I don't know the timequal stuff at all, but it seems likely
that we want one here. (Vadim, is this fix right?)
After this change,
abort;
ABORT
select * from t1;
ERROR: Relation t1 does not have attribute dt1
Seems relation cache is not invalidated yet.
I also tried to add time_qualification_check to RelationId(Name)-
CacheGetRelation(). But unfortunately,Relation doesn't have
such a information.
I think the real bug here is in inval.c: see
InvalidationMessageCacheInvalidate, which scans pending SI messages
at abort time. If we had committed, we'd have sent an SI message
telling other backends to refresh their relcache entries for t1;
so there is an entry for t1 in the pending-SI-message list. We can
use that entry to tell us to invalidate our own relcache entry instead.
It looks like this is done correctly for tuple SI messages but not for
relation SI messages --- and in fact the code sez
/* XXX ignore this--is this correct ??? */
Evidently not. (BTW, please add some comments to this code! It's
not obvious that what it's doing is throwing away cache entries that
have been changed by a transaction now being aborted.)
It would probably be a good idea to switch the order of the operations
in AtAbort_Cache() in xact.c, so that relcache reference counts get
reset to 0 before we do the pending-SI-message scan. That way, we could
just discard the bogus relcache entry and not waste time rebuilding an
entry we might not need again. (This might even be essential to avoid
an error in the aborted-table-create case; not sure. The routine
RelationCacheAbort() didn't exist till last week, so the present call
order is certainly not gospel.)
We could probably do this in other ways too, like marking all relcache
entries with the transaction ID of their last change and using that to
detect what to throw away. But the SI message queue is already there
so might as well use it...
regards, tom lane
From bouncefilter Fri Sep 17 10:21:04 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA93129
for <pgsql-hackers@postgreSQL.org>;
Fri, 17 Sep 1999 10:20:47 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA29259;
Fri, 17 Sep 1999 10:18:20 -0400 (EDT)
To: phd2@earthling.net
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Bug
In-reply-to: Your message of Fri, 17 Sep 1999 14:38:45 +0400 (MSD)
<Pine.SOL2.3.96.SK.990917143736.19731A-100000@sun.med.ru>
Date: Fri, 17 Sep 1999 10:18:20 -0400
Message-ID: <29257.937577900@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Oleg Broytmann <phd@sun.med.ru> writes:
ran=> create table test1 (n int default nextval('seq_test'), t text);
ran=> insert into test1 ("t") select distinct src from test_source;
[ doesn't work right ]
My, that's an interesting case. I think that fits right in with my
remark yesterday that the SELECT inside an INSERT ... SELECT needs
to have a targetlist that's separate from the INSERT's list. As it
stands, we form a targetlist representing the set of values that need
to be inserted into the target table --- and then the DISTINCT pass
runs on those tuples :-(, because there is nothing else for it to
run on.
In short, this is not a trivial thing to fix. We need multilevel
query trees...
regards, tom lane
From bouncefilter Fri Sep 17 10:51:04 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA05507
for <hackers@postgreSQL.org>; Fri, 17 Sep 1999 10:50:55 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA29290;
Fri, 17 Sep 1999 10:49:34 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Join syntax
In-reply-to: Your message of Fri, 17 Sep 1999 05:58:19 +0000
<37E1D87B.DA85C685@alumni.caltech.edu>
Date: Fri, 17 Sep 1999 10:49:34 -0400
Message-ID: <29288.937579774@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Maybe it's time to bite the bullet and do it. You have any thoughts
on what the representation should look like?
I was thinking of propagating a "join expression" into the
planner/optimizer in the same area as the existing qualification
nodes.
I think it would be best to keep it out of the regular expression-tree
stuff, for a number of reasons including the issue of not allowing
reordering.
The thing I was visualizing was a tree of Query nodes, not queries as
items in ordinary expressions within queries. Essentially, we'd allow a
sub-Query as an entry in the rangetable (the FROM list) of another Query.
I *think* this is what Jan has been saying he wants in order to do view
rule rewrites more cleanly. It could also solve my problems with INSERT
... SELECT.
Aside from plain Query nodes (representing a sub-Select) we'd need node
types that represent UNION/INTERSECT/EXCEPT combinations of Queries.
I don't like the way the current UNION/INTERSECT code overloads
AND/OR/NOT nodes to do this duty, not least because there's noplace to
represent the "ALL" modifier cleanly. I'd rather see a separate set of
node types.
I still don't understand the semantics of all those join types you are
working on, but I suppose they would be additional node types in this
Query tree structure. Should the rangetable itself (which represents
a regular Cartesian-product join of the source tables) become some
kind of explicit join node? If so, I guess the WHERE clause would be
attached to this join node, and not to the Query node referencing the
join. (Actually, the rangetable should probably continue to exist
as a list of all the tables referenced anywhere in the Query tree,
but we should separate out its implicit use as a representation of
a Cartesian product join and make an explicit node that says what to
join, how, and with what restriction clauses. The "in From clause"
flag in RTEs would go away...)
Another thing it'd be nice to think about while we are at it is how
to implement SQL92's DISTINCT-inside-an-aggregate-function feature,
eg, "SELECT COUNT(DISTINCT x), COUNT(DISTINCT y) FROM table".
My thought here is that the cleanest implementation is to have
sub-Queries like "SELECT DISTINCT x FROM table" and then apply the
aggregates over the outputs of those subqueries. Not sure about
details here.
afaik the planner/optimizer already has the notion of
merging/joining/scanning intermediate results, so teaching it to
invoke these explicitly from the query tree rather than just
implicitly may not be a huge stretch.
Yes, the output of the planner is a tree of plan node types, so there
would probably be very little change needed there or in the executor.
We might need to generalize the notion that a plan node only has
one or two descendants ("lefttree/righttree") into N descendants.
regards, tom lane
PS: Has anyone heard from Jan lately? Seems like he's been awfully
quiet...
From bouncefilter Fri Sep 17 11:02:05 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA07566
for <pgsql-hackers@postgresql.org>;
Fri, 17 Sep 1999 11:01:04 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA29308;
Fri, 17 Sep 1999 10:58:50 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: "Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: attdisbursion
In-reply-to: Your message of Thu, 16 Sep 1999 21:49:31 -0400 (EDT)
<199909170149.VAA21525@candle.pha.pa.us>
Date: Fri, 17 Sep 1999 10:58:49 -0400
Message-ID: <29306.937580329@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
Added to TODO. This will improve VACUUM ANALYZE performance, thought I
don't think we have btree comparison functions for all data types,
though we should:
* change VACUUM ANALYZE to use btree comparison functions, not <,=,> calls
There are several places that know more than they should about the
meaning of "<" etc operators. For example, the parser assumes it
should use "<" and ">" to implement ORDER BY [DESC]. Making VACUUM
not depend on specific names for the ordering operators will not
improve life unless we fix *all* of these places.
Rather than depending on btree to tell us which way is up, maybe the
pg_type row for a type ought to specify the standard ordering operators
for the type directly.
While we are at it we could think about saying that there is just one
"standard ordering operator" for a type and it yields a strcmp-like
result (minus, zero, plus) rather than several ops yielding booleans.
But that'd take a lot of changes in btree and everywhere else...
regards, tom lane
From bouncefilter Fri Sep 17 11:52:06 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA17381
for <pgsql-hackers@postgresql.org>;
Fri, 17 Sep 1999 11:51:51 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id LAA19225;
Fri, 17 Sep 1999 11:43:17 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909171543.LAA19225@candle.pha.pa.us>
Subject: Re: [HACKERS] Bug
In-Reply-To: <29257.937577900@sss.pgh.pa.us> from Tom Lane at "Sep 17,
1999 10:18:20 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 17 Sep 1999 11:43:17 -0400 (EDT)
CC: phd2@earthling.net, PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Oleg Broytmann <phd@sun.med.ru> writes:
ran=> create table test1 (n int default nextval('seq_test'), t text);
ran=> insert into test1 ("t") select distinct src from test_source;
[ doesn't work right ]My, that's an interesting case. I think that fits right in with my
remark yesterday that the SELECT inside an INSERT ... SELECT needs
to have a targetlist that's separate from the INSERT's list. As it
stands, we form a targetlist representing the set of values that need
to be inserted into the target table --- and then the DISTINCT pass
runs on those tuples :-(, because there is nothing else for it to
run on.In short, this is not a trivial thing to fix. We need multilevel
query trees...
Added to TODO:
* Allow multi-level query trees for INSERT INTO ... SELECT
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sep 17 11:53:06 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA17421
for <pgsql-hackers@postgresql.org>;
Fri, 17 Sep 1999 11:52:07 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id LAA19253;
Fri, 17 Sep 1999 11:47:59 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909171547.LAA19253@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: attdisbursiont
In-Reply-To: <29306.937580329@sss.pgh.pa.us> from Tom Lane at "Sep 17,
1999 10:58:49 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 17 Sep 1999 11:47:59 -0400 (EDT)
CC: "Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <maillist@candle.pha.pa.us> writes:
Added to TODO. This will improve VACUUM ANALYZE performance, thought I
don't think we have btree comparison functions for all data types,
though we should:* change VACUUM ANALYZE to use btree comparison functions, not <,=,> calls
There are several places that know more than they should about the
meaning of "<" etc operators. For example, the parser assumes it
should use "<" and ">" to implement ORDER BY [DESC]. Making VACUUM
not depend on specific names for the ordering operators will not
improve life unless we fix *all* of these places.
Actually, I thought it would be good for performance reasons, not for
portability. We would call one function per attribute instead of three.
Rather than depending on btree to tell us which way is up, maybe the
pg_type row for a type ought to specify the standard ordering operators
for the type directly.While we are at it we could think about saying that there is just one
"standard ordering operator" for a type and it yields a strcmp-like
result (minus, zero, plus) rather than several ops yielding booleans.
But that'd take a lot of changes in btree and everywhere else...
The btree comparison functions do just that, returning -1,0,1 like
strcmp, for each type btree supports.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sep 17 11:50:06 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA16863
for <pgsql-hackers@postgreSQL.org>;
Fri, 17 Sep 1999 11:49:40 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
JAA22349;
Fri, 17 Sep 1999 09:48:03 -0600 (MDT)
Date: Fri, 17 Sep 1999 09:48:03 -0600 (MDT)
Message-Id: <199909171548.JAA22349@biology.nmsu.edu>
X-Authentication-Warning: biology.nmsu.edu: brook set sender to
brook@biology.nmsu.edu using -f
From: Brook Milligan <brook@biology.nmsu.edu>
To: maillist@candle.pha.pa.us
CC: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
In-reply-to: <199909170411.AAA06957@candle.pha.pa.us> (message from Bruce
Momjian on Fri, 17 Sep 1999 00:11:46 -0400 (EDT))
Subject: Re: [HACKERS] pgaccess seems a tad confused
References: <199909170411.AAA06957@candle.pha.pa.us>
1. Why did the new pgaccess get installed into REL6_5 branch but not
main development branch?
No sense putting in development because there will probably be a newer
version by the time 6.6 is released, no?
Yes there will be, but it seems to serve two purposes. One is that
anyone working with the development tree at least has some version of
pgaccess handy. More importantly, though, any bugs in the Makefile or
whatever will be noticed early by developers and won't wait until the
last moment. Since the basic installation scheme likely doesn't
depend much on the exact pgaccess release, there really isn't much to
be lost by keeping it in the development tree.
Cheers,
Brook
From bouncefilter Fri Sep 17 12:50:06 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA27108
for <pgsql-hackers@postgreSQL.org>;
Fri, 17 Sep 1999 12:49:18 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA20026;
Fri, 17 Sep 1999 12:44:17 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909171644.MAA20026@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess seems a tad confused
In-Reply-To: <199909171548.JAA22349@biology.nmsu.edu> from Brook Milligan at
"Sep 17, 1999 09:48:03 am"
To: Brook Milligan <brook@biology.nmsu.edu>
Date: Fri, 17 Sep 1999 12:44:17 -0400 (EDT)
CC: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
1. Why did the new pgaccess get installed into REL6_5 branch but not
main development branch?No sense putting in development because there will probably be a newer
version by the time 6.6 is released, no?Yes there will be, but it seems to serve two purposes. One is that
anyone working with the development tree at least has some version of
pgaccess handy. More importantly, though, any bugs in the Makefile or
whatever will be noticed early by developers and won't wait until the
last moment. Since the basic installation scheme likely doesn't
depend much on the exact pgaccess release, there really isn't much to
be lost by keeping it in the development tree.
It is in the development tree, just not the most recent version.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sep 17 17:46:17 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA88687
for <pgsql-hackers@postgreSQL.org>;
Fri, 17 Sep 1999 17:45:54 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA00336;
Fri, 17 Sep 1999 17:44:30 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: "Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: attdisbursiont
In-reply-to: Your message of Fri, 17 Sep 1999 11:47:59 -0400 (EDT)
<199909171547.LAA19253@candle.pha.pa.us>
Date: Fri, 17 Sep 1999 17:44:30 -0400
Message-ID: <334.937604670@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
* change VACUUM ANALYZE to use btree comparison functions, not <,=,> calls
There are several places that know more than they should about the
meaning of "<" etc operators. For example, the parser assumes it
should use "<" and ">" to implement ORDER BY [DESC]. Making VACUUM
not depend on specific names for the ordering operators will not
improve life unless we fix *all* of these places.
Actually, I thought it would be good for performance reasons, not for
portability. We would call one function per attribute instead of three.
No such luck: what VACUUM wants to do is figure out whether the current
value is less than the min-so-far (one "<" call), greater than the
max-so-far (one ">") call, and/or equal to the candidate most-frequent
values it has (one "=" call apiece). Same number of function calls if
it's using a "compare" function.
I suppose you'd save a little time by only looking up one operator
function per column instead of three, but it's hard to think that'd
be measurable let alone significant. There's not going to be any
per-tuple savings.
While we are at it we could think about saying that there is just one
"standard ordering operator" for a type and it yields a strcmp-like
result (minus, zero, plus) rather than several ops yielding booleans.
But that'd take a lot of changes in btree and everywhere else...
The btree comparison functions do just that, returning -1,0,1 like
strcmp, for each type btree supports.
Right, and that's useful for btree because it saves compares, but it
doesn't really help VACUUM noticeably.
After writing the above quote, I realized that you can't really define
a type's ordering just in terms of a strcmp-like operator with no other
baggage. That might be enough for building a btree index, but in order
to *do* anything with the index, the optimizer and executor have to
understand the relationship of the index ordering to the things that
a user would write in a query, such as "WHERE A >= 12 AND A < 100"
or "ORDER BY column USING >". So there has to be information relating
these user-available operators to the type's ordering, as well.
(We do have that, in the form of the pg_amop table entries. The point
is that you can't get away with much less information than is contained
in pg_amop.)
As far as I can see, the only thing that's really at stake here is not
hardwiring the semantics of the operator names "<", "=", ">" into the
system. While that'd be nice from a cleanliness/data-type-independence
point of view, it's not clear that it has any real practical
significance. Any data type designer who didn't make "=" mean equals
ought to be shot anyway ;-). So upon second thought I think I'd put
this *way* down the to-do list...
regards, tom lane
From bouncefilter Fri Sep 17 17:49:10 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA89334
for <pgsql-hackers@postgreSQL.org>;
Fri, 17 Sep 1999 17:48:57 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA00374;
Fri, 17 Sep 1999 17:47:41 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Brook Milligan <brook@biology.nmsu.edu>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pgaccess seems a tad confused
In-reply-to: Your message of Fri, 17 Sep 1999 12:44:17 -0400 (EDT)
<199909171644.MAA20026@candle.pha.pa.us>
Date: Fri, 17 Sep 1999 17:47:41 -0400
Message-ID: <372.937604861@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
More importantly, though, any bugs in the Makefile or
whatever will be noticed early by developers and won't wait until the
last moment. Since the basic installation scheme likely doesn't
depend much on the exact pgaccess release, there really isn't much to
be lost by keeping it in the development tree.
It is in the development tree, just not the most recent version.
But the point is, if the most recent version had been in the development
tree, we'd have had a better shot at noticing that its makefile was
missing...
regards, tom lane
From bouncefilter Fri Sep 17 21:35:12 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA19593
for <pgsql-hackers@postgreSQL.org>;
Fri, 17 Sep 1999 21:34:26 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id VAA02888;
Fri, 17 Sep 1999 21:34:11 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909180134.VAA02888@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: attdisbursiont
In-Reply-To: <334.937604670@sss.pgh.pa.us> from Tom Lane at "Sep 17,
1999 05:44:30 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 17 Sep 1999 21:34:11 -0400 (EDT)
CC: "Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
As far as I can see, the only thing that's really at stake here is not
hardwiring the semantics of the operator names "<", "=", ">" into the
system. While that'd be nice from a cleanliness/data-type-independence
point of view, it's not clear that it has any real practical
significance. Any data type designer who didn't make "=" mean equals
ought to be shot anyway ;-). So upon second thought I think I'd put
this *way* down the to-do list...
Removed from TODO list.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sep 17 21:35:12 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA19842
for <pgsql-hackers@postgreSQL.org>;
Fri, 17 Sep 1999 21:35:09 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id VAA02912;
Fri, 17 Sep 1999 21:35:00 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909180135.VAA02912@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess seems a tad confused]
In-Reply-To: <372.937604861@sss.pgh.pa.us> from Tom Lane at "Sep 17,
1999 05:47:41 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 17 Sep 1999 21:35:00 -0400 (EDT)
CC: Brook Milligan <brook@biology.nmsu.edu>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <maillist@candle.pha.pa.us> writes:
More importantly, though, any bugs in the Makefile or
whatever will be noticed early by developers and won't wait until the
last moment. Since the basic installation scheme likely doesn't
depend much on the exact pgaccess release, there really isn't much to
be lost by keeping it in the development tree.It is in the development tree, just not the most recent version.
But the point is, if the most recent version had been in the development
tree, we'd have had a better shot at noticing that its makefile was
missing...
I guess. The new pgaccess release was so different than the current
one, I just cvs removed all files, and readded everything. That is how
Makefile go lost.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sat Sep 18 10:59:21 1999
Received: from excelsior.rkirkpat.net (dhcp-210-85.letu.edu [204.158.210.85])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA35130
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 10:58:57 -0400 (EDT)
(envelope-from rkirkpat@rkirkpat.net)
Received: from localhost (rkirkpat@localhost)
by excelsior.rkirkpat.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id
JAA20892; Sat, 18 Sep 1999 09:58:48 -0500
Date: Sat, 18 Sep 1999 09:58:48 -0500 (CDT)
From: Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
X-Sender: rkirkpat@excelsior.rkirkpat.net
To: Lamar Owen <lamar.owen@wgcr.org>
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <37E14701.EE79FA45@wgcr.org>
Message-ID: <Pine.LNX.4.10.9909180953280.30766-100000@excelsior.rkirkpat.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 16 Sep 1999, Lamar Owen wrote:
Ryan Kirkpatrick wrote:
Ok, I will do so this weekend, providing there are not too many
things broken. I will let you know on Monday what the status is. :)The current tarball is 6.5.2RC (for Release Candidate). AFAIK, this
will become the release of 6.5.2, unless there are problems.
Ok, I grabbed 6.5.2, and after only minor trouble, have an
alpha-patched version. The biggest changes to the patch was that a few
of the "safe" changes made by the 6.5.1 alpha patches have made thier way
into the source tree (i.e. CPU defintions in the configure and makefiles).
Only one instance where changes in actual source code broke and patch, and
that instance was trival.
I am running regression tests on the 6.5.2 alpha patched binaries
now. Once they pass, I will post the patch to the list.
Good to hear, and you are welcome! Hopefully by 6.6 the patches
will not be needed and Linux/Alpha will finally be a fully supported pgsql
platform!Yes! Now if I just HAD one.... ;-)
They are nice machines... And there is a nice range of price/perf
on them, everything from low end inexpensive machine to top of the end
bank-busting machines. :) If you are really interested in playing around
with an Alpha, I would recommend something like an AS200 at the low end,
or a PC164LX at the mid end. Don't waste your time on a UDB though, they
are more trouble then they are worth (overheat and die after a few years
:( ).
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
From bouncefilter Sat Sep 18 11:33:22 1999
Received: from excelsior.rkirkpat.net (dhcp-210-85.letu.edu [204.158.210.85])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA41279;
Sat, 18 Sep 1999 11:32:55 -0400 (EDT)
(envelope-from pgsql@rkirkpat.net)
Received: from localhost (rkirkpat@localhost)
by excelsior.rkirkpat.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id
KAA29111; Sat, 18 Sep 1999 10:32:49 -0500
Date: Sat, 18 Sep 1999 10:32:48 -0500 (CDT)
From: Ryan Kirkpatrick <pgsql@rkirkpat.net>
X-Sender: rkirkpat@excelsior.rkirkpat.net
To: pgsql-hackers@postgreSQL.org, pgsql-patches@postgreSQL.org,
pgsql-ports@postgreSQL.org, Lamar Owen <lamar.owen@wgcr.org>
Subject: Linux/Alpha patches for Postgresql 6.5.2
Message-ID: <Pine.LNX.4.10.9909181023010.30766-101000@excelsior.rkirkpat.net>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
BOUNDARY="2831159047-1185505748-937668768=:30766"
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--2831159047-1185505748-937668768=:30766
Content-Type: TEXT/PLAIN; charset=US-ASCII
Ok, the Linux/Alpha patches for Postgresql 6.5.2 are attached to
this email (quite small after gzip). The procedure for use is the same as
for the 6.5.1 patches. Grab the 6.5.2 tarball, untar/ungzip it, then from
the top level directory of the source tree, run 'gzip -dc
/path/to/patch/postgresql-6.5.2-alpah.patch | patch -p1', and it should
apply cleanly. Then just compile, install, and run as usual.
The only regression tests that are failing are the sames ones as
for 6.5.1, geometry (off by one in nth decimal place) and rules (with
no-predefined sorting method, alpha's default sort is different than the
rest).
The patches are also on my web site, though notice the new URL,
http://www.rkirkpat.net/software/ to go directly to them. Also, if someone
could update my email address in the documentation (under Linux/Alpha
person, or where ever it shows up) to 'pgsql@rkirkpat.net' (from
rkirkpat@nag.cs.colorado.edu) that would be great! Thanks.
If you have any trouble with this patch, feel free to email me,
but please try and provide as much detail as possible as what you were
doing and what happened. The more detail you give me, the quicker I can
solve the problem. TTYL.
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
--2831159047-1185505748-937668768=:30766
Content-Type: APPLICATION/octet-stream; name="postgresql-6.5.2-alpha.patch.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9909181032480.30766@excelsior.rkirkpat.net>
Content-Description:
Content-Disposition: attachment; filename="postgresql-6.5.2-alpha.patch.gz"
H4sICDKr4zcCA3Bvc3RncmVzcWwtNi41LjItYWxwaGEucGF0Y2gA1D1rd9s2
sp/lX4Gkt42elghRsmQ73rqJ2/qexMmxnWzP7vbqUBIlsaEohaTcpN3e374z
ePAJvqzEm/ichBQ4GMwMZgYDcADOrcWCdHZXLtluPH/pmt57uzM8HBzSrufO
ulNj9s505l1jNjM9r7syvBX7b7FzZoezVJ2OYW9XRomaB51O5z4t1l5uHHK+
WxJCSa93TPXjfp9o4/H4oNVq3Z+c2o3hkxtzS7QR0XrHPe14cMTRfv896VCt
rQ1Ii1++//6AfGM5M3s3N8njCLrD1eMDckB2luP36UEHi+CW1uE/bUjemR8b
B62g8Lnh79a8kPx50Km5pr9zHVLntRvk/+HRyUErXV7n+BpY9eSA/KVoUhfQ
8Tb1rDYTTUELojFFEygNbTBoH5EWvzBpzM2F5Zjk9fXlywtaq9W0nj4ajPpJ
0mYrw63jfxHCWFmcMFKDOoDFNh1ovcYx1GqrE976sM9aZxdsvbYiT0kPIaEC
3HrWH+ZmwdpB6mvdJnm2ce5M1yesbX9DAKO5NF3S7IIUsPqKNDn1Gvk/UgdC
SIc8IU8aKJb0c447CoVEfPtUCOAE+ZbSBKrnlSzMmfquaeJltllvDdesZGWK
2qUtTVE3bW167z7WpkKdb3FDbnHDtMXtfMv2utOdZfuW4wmjE1o29dG4Zuut
MDqjTfjNFNQtfMj1DR7ym2nCBoWp1Q3o32kjaoXyibBBBBC308BSoqToghSw
RU4K3ASk6MWkMArSBMh24XYabxZlp4+Z7PgFZZcii+pJEUXpoiUIq0tRGI0k
iUIg/ImaSiEcmpROtKN0Wk48ASWqngoAkKBkFzFvotH2CLwJXMZMVjEijann
W2sTCTmfeht755u38Bvpif3mREegObXzgO45J7xVi6MBz4IwZIo3KKOatSCx
pi69H8zFxjXrADZtAJKa5LCjIbxpeybJrDRtQy80OKOUu02qC7cZ7w70aEg4
85DQFrtytuQjZVeQtGmgvx41eN+IeyH5ko7QNX93Ld+U15eGY23LOUF1zWIH
qK5X+7s5Jy+Nj4QOSe/oeDA41keVnF8G2lzHd6QdtYekhRcxvOEfdrO4/VNc
a01nMzdf+y7ozmyz/fhq+ps58+sOswL2Zy3ql955XcK1yVvoU65D+Fev4+9m
g0iARufsznBt8w5a220Brb+yvEmk6ERU/YtfS3eo529cY2l2re2s+9J4B8GC
bZaRn6pecWeqatVudjCObV1CBiDqYzo41nSU+ahsV6qR5nWk1sd+hP/BqXHH
8uzHF+c/3ZDWU9K5PDzsHh5CYesb4pnm2sOoZGoS13y/s1xQO0TT7R11Kfjl
39YHLWthvif1/6k/e/2m0WbkNSKFzxptspzNoIi3gU0snE3HcmyIyw5awIG1
SMCby5lXVEFcDsirH/73BhQCuD/c4P8WXLzV2lzz6/uduTPx1nLuDBtu/nVA
xB8vMuY+Pt5azuEGuC6pN3ykh7pd9EHlXECyTrG+JGukY55BtZgnhTBXT/ro
kFt96ZZJs1bDapsdhsAdMG0WunrkyYcnqCSPPzxGoO4Bd9HNg46AFgPpbAWd
Kou4p8Yi5qqxuAZ90gT6d7YPHcr9PfiArWHbm1mdoqNmZA3HSBb7X5K1daEJ
Ywq2i7WMmW+6h6jEcWqseYQYpIUXCFLUlKBjebZZrw1nfjmvzSiP9EfD9nBM
WvzCifiUf120yelmY3MRmu+R6BEx3KXGghF2S4U04akY/9jj4J4mAhJ4Sp4+
ZU8S0cioIR8Gv6iMR0IqHDOPCnhamopHeVQ8yqfC9vOosP08KkhsyoqBADZ4
Gv2pajGXb9u8R4tPC5pc5jK5vAeTZ0Ut5jK5vAeTZ2omsYQ3ubXzmoSnpfWp
laNOLYU2hTSsrTwa4GlpGjo5NHTyadjlCgIfl6aimUNFM5eKuXWXRwU+Lk1F
N4eKbrZ1W/McR8cefkY/xyTBl5BGba2Pa0jsGsxHfPODL8e0Cf4ISRUy4qUh
jcI4sDQ+oDCLEcOcGN3enl///Pz65h+grxpbtIGCm8t/XNQ5YAMgoyAnwG8T
Kz0/vz2XMAiE7SLXyoehDGLrQAFdf1WPfuaGb1aNfnidKtEPr6GIfrR7Rj8C
YX6UPBiz+TdcxkGg4Zo2TqRZCBSJgPyVyVbuXMewCcxv14AYIiKDCHji+RCh
LBMBSYisfm3ahm/d8ck3FoJORR5zpfLFTD0FjH0bLWwQFrcoQhmgYzcD2tY1
32+zuRI+99eA4TvfF8uYY40xPqZtrccNgPy+gllFvddAvfF8aGhG7jbWPOCB
+us0D20SNAfex1+HPKXB07AVWIVpQO325avnb168qvOG/XXnzF9PPpoGTC77
2qA/7PV6zLCUcOuN0yZ0MKb5UHPjY5uMhjoDYhHy4AhFBdgjazRI1s3WcFCy
gYAm+J8HpXG+xdNQMiEc73MsVslCKlZKHPiAcRChIux/vnzNxMJnysC5L5av
+6MRY2ZMIwq/fuczxYaZEtN41wTT8UCzWevyEfnd8lcEbGy7gSKwB41AwEx8
KjSeLf0I2INOBGd88crXEqtXPvr+KLhYswr8/5yqVq+g+acMyKd4g04+AQA6
7KL7Pf/h5vby5cXLy6u6z+AbQi4+MBN5fv6LfC5lK9kJZMCFqGtMiDrtS+NB
KaKwtjabNXGny10G1NqZZLMgdbFAh5S3sAsl81x8UdoPOhxZWnJxW0HJCchK
QjtJWV0oQ1zN89kA+uzN9fXF1e1EyIet3DAEP5n+s53rmo5/6xqOB1Mxa+Pc
oLQRWT2YxOl9Zjm6rrc1LSantVVOTp3ABvIEBTFcSUEF0d7egmp9YlENhkxU
w2FUpYQkUFqlhBX8CIQl/HiUh4NOgLaMZYbA97XLTycqjoYq0TApHg2YFEdH
USlaTtS7STFi8AmBkCFoJxguEMsDUw9HevRkXI7w86ATIkoIrk2U3gLXyJyk
W8uEVYgSBRjKT4J2zrBXdx6K4XZyeXV7cf32/MUE/l0+J999B9Vgfn15xX7H
xCzDZNGlMOPz2yTEChIw/tn7tQE4uH8UcLYKTvu1IcZHfTTGpcZBT74RjSlb
UA8MuZ7DeQUeo7yE2pmiT8WafGfBCB9o4zZEl61BX28PjpLh39JUaAso6pKN
ji4oCYy7G5eY73fADASCwUDIpzoCDcxo4g5E6ZtCYBEFBkbmy6lPaEGya68v
XmDXkn//m3CbSDwAvKxWPHhQ4wBQQJOIMzKwhtLvnYRzMo7Xj83HFA0nW4jP
D4UcHLOC0IJVqa9TaI+KhPaopNBsv4LQgkW0r1NopwUyOy0nsmUVkS2/bpGd
FYjsrKSWVTFN++s2zdMi0zwtaZrLKkJbft1COysS2lm20Ph7FwgkIIgbUT0y
ReV/wWQgNtLKYd6GoeB9IsZIypmFZHngIkpTLk3wcIwkJulitY8J2cqIW5j4
GthJdV8lTh6+jvi8cqT3UpxDfFHIPAyEVZhXgP9Xme/zboeJUOVuh9GsCucK
8P8q5zrv9iNanfNlNc6XXxjnQ97no1GK8xqLr4t7vprO21+Yzh+xnh/30q5O
TCtKCWFZTQjLL0cIld9FLOyN4Vd9GSEqVXkbIaooXkfQe76OkBgLsnZ6LE2O
XbhCkJ0DONiaxNzCVwzTHS6MeMRwTbLb4rLF/DCqOZ3O/Lc10WhXG3bHQ64z
nW+wowhPlJ7XbcvZfcB5flAymTDaJ5MGYeWP5IM3VzfnP15Mfnzx6vz2BvTo
EyHCR70wdTv2EIp55o+IBwZaG/Mw4BJd1NH9zTyeogKmgombxNmtp6bL380w
qY9EkbAfVjbUwYQQh8gVAQi0ElbCrcER7/YEeK0mV9hbNZ4SDlXECzfMPHQS
L/3qol6Q3CISw0Uxrkg0guW/0XDIeBzGF65oBo+0Ao9U8KgNJY+0LI/aMMIj
prDuxeNYw5dsrTFN9eNij37E/FGGI9WPCxWPmMl/n37EJwoe+zTBY19nPPZT
/bjYox8Zj1TwGOvHcjyW7McSPFb219BgVW/NqlTx1ayCwlP37+mpOb5cPz1k
bnrYi6SnYXemsua81cZlb4kfQwckM+dEDdGp3oqP0jR8F+ytMvPV+C6F3qCt
UdIS1wgleooSZlHZhOhh1hxftuYlnA47m4yoEiWS+TTaOKnh9hfD83ZrE4Rh
LZ02CBPGsaXle23y5F+9J3wTjO1vjLrdFmkKLIeYFQmjjD5RpTQIcVDa1nQQ
B16HQhzdSJ45Woyly40HPKlDlKUyOhJ55SKhQqaRaEPudSwqNxAIbLwswCYC
qhAm4mjgZ7i2L7LUbn6+vp28vLxi82vT3izrF9fXr67b5DHHfEyefDt/QmbG
zjM97kF2ztx0wVB/f9zmVJxEUZ4JlOe/8IiT9lliJdW1aB6+zHtBhEHeS0RG
QXGZxBfWzIgZCB1R2QwqAgJP2PazhuiYSMN60HBEnEFx2Yb7fdyyA0rQ74/Y
TcQocEU/uqTP3/+IPDbME0rG1zrPVRL0yI0qIltJPN8zXQk3iUTylfjPxCIS
tsQTM7Mp2T81U1LyqIAS28+nJD89M07JaR4hpwV0FEjEriCR01yJnBZIZFkg
kWUFiZzlEXJWQEeBRJYVJHKWK5GzfIlQbjfCgcitVSEldH+7wd1vEbvhPxWU
cLvJpmR/u5GUPCqgxPbzKdnbbiQhpwV0FEhkf7sJCCmQyLJAInvbjSTkrICO
AonsbzcBIQUSKRpw6MONOLRoyKEPN+bQokGHPtSoQ4uGHfpw4w4tGnjoQ408
tGjooQ839ui0KGijDxe10aKwjT5c3EaLAjf6UJEbLQrd6MPFbrQoeKMPFb3R
ovCNfm4bktS8Mz8uLNfzgyiuqRgYs4CyqGpmmFMzJ4zrNsWBAn2Yyo3xSIEB
TOyjiX3+P6n+69y6i87rIttTwuQ9Nv0HIe7WoZCFXKEoPl8PaO7wKXpCgrw0
toEd0fCtTtndt/dmJ9l5LVXfRQjhuXDZhOy940kS0ikiZFcgkv23PUlSmgWk
iJ1P2aTsv/dJktItIMVyZikVxLIMHYSCsMeJlm601YrrI1uagiGXazo3WDEK
V9J0sMWOGjPX9Ox4eW9Nl+FyS+UUIoRwTc8mZG9Nl4R0igjZFYhkf02XpDQL
SBGank3K/pouSekWkCI0PaaCpTQdX1Fo6UaTmi4siha5XvpgvpcWOV/6YN6X
Frpf+nD+lxY6YPqAHpgWDdX0wcZqWjRY0wcbrWnhcE0fbrymhQM2/cz6ArFn
NMZc44v4RIwJZRlR5jpIK8iKfII38CWI/zaP+G8LLG8dvP3PGpr2JkWOB99m
jAehRyoQC304uei0sI/oZyYmoWELY5bUsEdpzQKo9CsyLIwPqkSkNqRyHVTv
IEn8HaQmknvFa90e3+UzZHmZreFgHGwYTnSvIC3+2jCDNG2YTlGI0sYOcCtP
23DcpgMg7qiP1yhxMhax8YALt2Dlm8OU6fJ6ZLrfIH/jKnCcUoHMRWisE314
XBBKeWvM3CugXwKVZ+C0CgOn92FA6m0o/5w3dp9F/srlF0m+fHhc4C0i8s+m
/zPJX7mqVsxA5VQdR+ylq5qvE9arkrQT1lJk7uj3zNyJIM1Ps6RsR3JLXOWm
fn7agcCBxxfEd2OyYwJAyqTp/7FNnmUgziyER064aRZxiB0c5Sujj/zGWszN
BXlzczF5/erm8pcJ5stGj3bAAx0+nBx0QFf4iQI1loLD7xusuRPMo7Q9U6SF
dpvkUQIhG1wCnFBlSvzpCYfFfNONPSdvjzqWt+bpGjxDlaW2tbQwxS2bXLZd
5Y8trk1fvXnxogH6X/M/AKH2ZmawpOa6IBnzhr5jpySw8wMTQPCIhHs3Se3P
ANFyXYRFQAQo/jpJ5JdSrYdJ2PyC/Ig907F95iByKjq1nuw77FX/D7lDhx2+
gIdIII21mmfOxBDHi08Sm3wFBOEnBd8ZtoUZvW0yZUdokuXGcpZks/Nxs7dr
OEvoFYd4G9DHtYl5gh7vRCbp8DwMHCrHPY3tCoqUnhHa6/MjcPoaP9UCLjL1
nPxk3ZkOpibG9F5u7QGFuHCWtuWteNrOHTRuATFAGEtOBrITeWXSHDGTLGVK
YCXR5/HTT1LQqNzRwuzTT7ik/T/wfr7ZTW0Q8QJkHIYLfb7roD/UI0maqgNM
Cbgz6GuTb/2FBxpuEDcWbPsvmvdhLGNIeQZqipPUJntEBMJQ1s7YCKYQEEZO
CMfxEbEJC8/E8DzT9RMHtL5FPWNGo7HEziIoGqa49o/YkTn9EU3Z/9Wr2wn4
gOdqgZyj3O4rD175SxTHmJ8F0gvOAsGMR67Xk4XlWL5Zb8TUJPEwfiQvfxaO
IBIqvkFDVSdtIeLogCCWkIAZpwMQzMmPAl29urk9vw6PWEg/v7gKUbAzdmsK
5pF1fmqKzk9N0RRHXOy7216gMd9XONIieA+875EWCWmm92IqDmH48fzFzUXB
eStMapSfodIfxuZdMa4dswLXwRvnL5prnY3JerjnI8217VfgOni3/UVzPegn
DoFJc72swvXyq+B6yI++GeX1dRUNt78KDefDqD7O6+sqXC+/Bq4HA2bXg2F4
3l7wdYzg8KINiyXZPE74eGCH085OW5MDjIQqGkIDODEZrzSIGshVtP3o3gfk
9tHrDdtbKeOD5KmPYiuNRNFo3Gfbo7Nbm641qzw1l9UqzcxlJcXEfHDfiXmA
M39eDq6AfVxlGG5/7AR/QhmuOC6YXvCbieWIrScenjKPs7H5br3+KFdo/I/b
9WaO040ieBFUCni2VikaewvTDHbm1klYxtYh5WmKnO6xpBvPnPLx7Pr6d6wa
Cyo9kxVNFu5mPYG266z9EAAmjMZ2a3+ccApE1bYkCGeOyudi5ScAE7tyQAXX
xjtzwhUySsjCNc04cVz4Oht+2HWcFv8+f8muYxs7RH+IRTV5XlbkAe+Pu9gm
Gtyw/JTcpfsh1lfhdDCYIfrr7Ul1w9tY86pGx6pUMThWQWFsw3saG8eXNrRR
xNCOBm0NNZZfE8PPBg/iZZ9semXNVaudKoDkgdEwEwAwnDDvHNz5Zc7bZLrz
+UY0i+8GM+d8+1f4IoVibloPZxqF6Zdp0Nz8OvM9kBNbwBW0h5t5ECC6eBsC
3J8hrTxDIWgixzTKkNgxVVmRwdzv8xWDoFoVhQ4qKZR6dE+lDnHmKvaQxRfD
yAEqhExNtl+O/G7CmOx56E8hRoRO5mcpeuZs47COBv8Bg8ECppmG6xofYaA4
bCSWtKZbvAtHEMV4Y/h+MOSkwUVkFh1wjPguQVkdT3pWrHGFJ/q6J/Fvlcnl
WfTh/fBEDYLfJbM4r+wIkBXxtubMWligrRYoYINs7Z0Xnj09/eib3qGS8Rjb
uFfUdAIukzzaMbb4x9Hssgy5AN8Wy7N4LEqLavon4ugc+/YWdIAFkxNBfFja
vItzp4YQPJpO8l0wKs7a2NYB5ofXz34+v351+RwcBcMRKwIHg9UjrqBaZbk3
luGInJ9E+xrbe9nvh0FU8gt0giWtcaj4modkOPIRjUhp0Zc0+KoY5UusdPC5
DFH4g9KWmA9/H0NMWJ9gfKTx1dGItnqfxAAFA0kL9LiSpp4KP+NFWap53Arn
Xll28IhjTLymR5/H+CTZOdanBiljfkBBYC8CS7ywwALL1FcZ4X3GZkBg3GNs
5tUqjs280qcdmwXO3LEZvUHCKZAOuV1t1uAAXmxm71Z4Xjd+Fquj0Y7WEyoj
94iz3ePeboozJ17GD9yX+rKWN6g22cDCMNbBnROzejwmAx8yO2EfAI3sNE8b
SUFfi69GdmOfac0TrrJCdv8qwZM9Ozim5b6hoMaW26d0KM5c4FfsVRCXCaaE
L9MJopiDj/flAYgbdpxVm1z65losnBDfErNWiLAj3/bFQFrgEt+TVXzS9iQD
JvYNWjDwDEThl1+zYPQYDFHCjJCgoU6amUDsIBVdnqeCyLY5gCN5gE4OIM5V
cH6S2SQAjBhEM1NO8Q/iKiWQ+D6usiV2QIN4KS5cAVh2JrhjrM36FfwHaAHQ
aVSwo+THV8toc7JOsTUlaygMSq9kUCmEuTalD9vjPr4GwAt/wQqWIWZv6BGF
TOUX1yJRzWwV6WlZlPg+W9jPcYDga20nyRaseRg2pfHHv7gWPsapN8n7tJkC
NOv7YwrQrI+EqUDLY12Wx7osxMrK8j6DpQDN+lqVCnRXHm3mp5+SjGV/oCml
N/Ev64WPox2fkQunAM7eCasAzt6qqgKugnlZBfOyBOaoEpQHzk77VwHvqqDO
SZxPspj3Qa6Ylxjxs33YaMHDLXEUkVQuXqj6rlbYZhImcuaPDA/4cWIpH8h3
FgkXhaejJZ1U6qitpDKnDt6KsYfbWxFiFPrBlRcBCXGMwlYSMJxSBNL1AI3l
bHf+hIemKnx65FyupuFM2PwkhZRvIcxnP3bAV8xBIILUwVgxCChMH3aV7Fvl
2VEKMf+ntGtpbtsGwmf7V/AWT2jZ0Zp2bPmUSZs+JmkzdTLTnjSURNOaSqJG
ouq6v754gwAXIFa+WJL57WKxWBDP3XXiijnmaQVxWj7HBEERviCuATlsbCiq
iLmiUamQ4op4cfwMShVX4MWJ3hYPOIWAw8EFEHDY+x8DUzjXFM41gXMkjBAC
Dkf6QcDhYDwYmMK5pnCuKZxJxgEk6wCSeQDJPoBkIECykFiwDwxN6jFA6jJA
6jNA6jSQrJOE0A29d78fFQEDhD0mMXTYqRFFH0jMI56BGNx1t+8Na76jPAYI
+7tj6LBTOoo+kJhHvLsxuOuBjagHaC0LtKYFYtsCtXGBZpdAM0wgWiYQpY94
IGLKiXhy4ronsY86RGJ4zxMRE8HzCMQsNO6Xh1EMuMJhosadzzCKAX8vb50U
DwWKgJPXuvGAmhiYwrmmcK4JnIGiDaBoAyjaAIo2gKINIGmDZBxAsg4gmQeQ
7ANIBgIkCylIJlKQbKQgGUlBspKCZCZFup0kxNPqLZb94FUYIHHXyc7cKOgD
iXnSxpM7cwvUzc7c4oDEytuZGwV9IDFPrXxn5hZtWKC1LNCaFohtC9TGBZpd
As0wgWiZQJQ+EhkCUw4RTmRfEPm74SLGqAgxiDtzI9j0gH88JiqhEG/mFt61
FhvJ/BDS3UnunEiyb86Bl7wd/U7emJWf2n3ta7UbNdv5il9nmjfrbblb7ptN
xo+wZZYefolpUz1ns3ZXVfuLLPv2VO0rnrxHMti3zU5enNnW03K93TVzkVZd
pc3hDzaC9lJl8nFqPONZ02G+3urpsJ4Lz3rTWgEtFJRPZPWMdtbTo+WqNKdV
GIAWAWjWh94qAfhpuZSAfwtIC4VfMyUuVjPwq6a0kIf4JtYNEisnj/g5WJ/y
M7j+GiS4NQRMD5qAfcUImuWCo8WtZHk5OYC61bC3CocqWLm8cKzrCuM5GWG0
vG9wQtFHShW+ANNgp5AEfWu2CermnZRDbbdlcPsDI+Fb75ykd1WhNPEY7P9m
xsN3fHctosuoT3Mgz92K3FeImyFNZm0zLxL+wxz0uMczCsoPRtzUa+yP9tDI
QxQ2voRx8FBQJ8lbqxPAdc6e5D+YUL2jJ4PmJeBZu+/xaotqbsvNVIkoqB/Y
P5QG2LdO/e1DBZ9q0BmmTI/SCLX+uw1kZkc85iyPntf4FiH387RGyNkkJYE8
H667bFNb6Xyo0ohjvKXCqkkjMLMvjyA7HbGOgJmBzcs+3B6Zirjhjm7chQpv
0/MsZJH5oDRYNTrl53j5ChsuGC1VP98FM99bwp7KN83zGb9C5+/wE9LK45Qp
udVxypQE4zhlfTTl6mhp6yTKHNdttHt42kzG4jnXcWxNwK4IMtQBbObtXMiR
oVz7qULHfh8IEvdyK6eTbpJKlSm/xjIDmvzsXD91GPbS3qbLsjpeA3US6Qgv
NSGVdZh2OBN0mHY4l3KYtn4F7eoVMtcJtHm6nnUsojBRMHd2jCiYdjpGVB9D
tDpGvDpGhBr4/Phu1fxDIXVGRztvLXe+APq18L44H1+x14L89F8LcuXFNGsW
XmKboPOrJ7ciqdJI9L8feaZVvQZ0L2ZpiJ+DFkF4GVxtC7o8VCZQHAE+whGV
lb1obd5WDyKFW4ibWUEEE24hbma5iJFXjJ+qFUF4iU69yhgeweoaHlh1ZcmP
ti5GDrcuj7YuPYSuobjUpS7sGx8TZYFXhQhqIj98++NLdNZF5QrdeBq/xeyO
Q2sCtA1BRx405uCNXkwLek97b5QB33D06DToeG2rKBXMgPKunebdQbB/CV+d
KefmXLNTvmzv3ougj+qTN4oKnXiiI4TIFVhbyi0I+bp5qx+avUPrSt1Zsch1
M8k92F/UpzkLd8gzhJwv2ENX9XEf3r10XjOrWutnF/ON9aisK4HvPYrX0q+j
YpenCoFS9YWwl9O9zSDxeNqVpKdPvsOk+diNpS6us90k+QnXFnffuAAR4CdX
n51XQVeSZs5sjFVGEcszH8R3RokTcrbxmoPmI+vrMcljNmiNijpmjjGPVtwe
Y+6iqC0E3GIj1hZzN1VkzltX4dks0jTdWIdzxd7SCr+paPhVG8bL0GHvudO3
/OgZGX8bcusyb0X0grIxwjhs2+w7r9fzzHyH3gVqgsumf616yIHT+G9ueoOE
6LhilBjqtqIQ0WlVEWawuL7h3vO5/BBDhfYCXZfzcrHYTdfl5vB4pn6x+rO/
9nTJhGviI4SJU0MLWMQ0kk7phC66l17jQlxNyTuiYqenMz737vOeLD30tJzt
PY5CcXcgFHenMz/36FabIUGmPPF1B8OMrPMLUJJt81zt4kS2IQLhh7oaxwIR
yR07FVnfNgmb6oQqJA+FDB89n1Sc1E/LS7mJutxIrpEmAjbBNdLSpLpGWoqT
b4cq+1K+ZHCdjceTcXLYoiDDuLuxCLYq/ioH8uU+uylGs2W7vzj59lTtRNxc
ETOr4iFpW3HaOmvaJx5lYr9cb1cv2Rs513tzLk5aV1UrOPGABr8/qIPX7PmJ
ySGiUiz/4+cPbIn8wgq74DGB//jyY3Z1eX3JhJJnsqY0GYW6u1y97z3t7kww
i9NPpRm6pN5Dl5IHA1KP5XyAu7GLAys2wQUe3Vx+KkV1w7vvmrbhtHvlYo8t
szXeP8DqDePxKM/+iIzEfNZza2fRQQjoeo9SpgRFxSlTAovilPXRlKujpa2P
pkQjEHuN5rXF8D6zH2U2AZu0L+5HNE3hS5ChJmDdmMx2aYj1IrOy1MHj0XWl
bh37MC3GpZUvQqlm6obE62iviVru6ScWwlzysD/AkUQEi3h94gUrj8+QmoVB
NKhME3DCZ3S/qTCm05/5C3NgSG4rNsww9V+ulpvDv1Mx6MXGQgwfHooxNBv6
Dtmvh1UGdxnABG4m7EvKMIwyiw7Bt+dXWX57LmN9/PD54funT7/8ObnYN6fZ
X58+f/jpYTJasK8fPn6czMRdqNHLaf7x6/eJrNb/Q1E5gfC7AAA=
--2831159047-1185505748-937668768=:30766--From bouncefilter Sat Sep 18 12:12:22 1999
Received: from excelsior.rkirkpat.net (dhcp-210-85.letu.edu [204.158.210.85])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA46199;
Sat, 18 Sep 1999 12:11:51 -0400 (EDT)
(envelope-from rkirkpat@rkirkpat.net)
Received: from localhost (rkirkpat@localhost)
by excelsior.rkirkpat.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id
LAA29289; Sat, 18 Sep 1999 11:11:44 -0500
Date: Sat, 18 Sep 1999 11:11:44 -0500 (CDT)
From: Ryan Kirkpatrick <pgsql@rkirkpat.net>
X-Sender: rkirkpat@excelsior.rkirkpat.net
To: pgsql-hackers@postgreSQL.org, pgsql-patches@postgreSQL.org,
pgsql-ports@postgreSQL.org, Lamar Owen <lamar.owen@wgcr.org>
Subject: Linux/Alpha patches for Postgresql 6.5.2
Message-ID: <Pine.LNX.4.10.9909181110380.30766-101000@excelsior.rkirkpat.net>
MIME-Version: 1.0
Content-Type: MULTIPART/Mixed;
BOUNDARY="2831159047-1185505748-937668768=:30766"
Content-ID: <Pine.LNX.4.10.9909181110381.30766@excelsior.rkirkpat.net>
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--2831159047-1185505748-937668768=:30766
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.10.9909181110382.30766@excelsior.rkirkpat.net>
Ok, the Linux/Alpha patches for Postgresql 6.5.2 are attached to
this email (quite small after gzip). The procedure for use is the same as
for the 6.5.1 patches. Grab the 6.5.2 tarball, untar/ungzip it, then from
the top level directory of the source tree, run 'gzip -dc
/path/to/patch/postgresql-6.5.2-alpah.patch | patch -p1', and it should
apply cleanly. Then just compile, install, and run as usual.
The only regression tests that are failing are the sames ones as
for 6.5.1, geometry (off by one in nth decimal place) and rules (with
no-predefined sorting method, alpha's default sort is different than the
rest).
The patches are also on my web site, though notice the new URL,
http://www.rkirkpat.net/software/ to go directly to them. Also, if someone
could update my email address in the documentation (under Linux/Alpha
person, or where ever it shows up) to 'pgsql@rkirkpat.net' (from
rkirkpat@nag.cs.colorado.edu) that would be great! Thanks.
If you have any trouble with this patch, feel free to email me,
but please try and provide as much detail as possible as what you were
doing and what happened. The more detail you give me, the quicker I can
solve the problem. TTYL.
PS. Sorry for any duplicates of this message, but the lists did
not like my new email address until I had unsubscribed and resubscribed
with my new email address.
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
--2831159047-1185505748-937668768=:30766
Content-Type: APPLICATION/OCTET-STREAM; NAME="postgresql-6.5.2-alpha.patch.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9909181032480.30766@excelsior.rkirkpat.net>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="postgresql-6.5.2-alpha.patch.gz"
H4sICDKr4zcCA3Bvc3RncmVzcWwtNi41LjItYWxwaGEucGF0Y2gA1D1rd9s2
sp/lX4Gkt42elghRsmQ73rqJ2/qexMmxnWzP7vbqUBIlsaEohaTcpN3e374z
ePAJvqzEm/ichBQ4GMwMZgYDcADOrcWCdHZXLtluPH/pmt57uzM8HBzSrufO
ulNj9s505l1jNjM9r7syvBX7b7FzZoezVJ2OYW9XRomaB51O5z4t1l5uHHK+
WxJCSa93TPXjfp9o4/H4oNVq3Z+c2o3hkxtzS7QR0XrHPe14cMTRfv896VCt
rQ1Ii1++//6AfGM5M3s3N8njCLrD1eMDckB2luP36UEHi+CW1uE/bUjemR8b
B62g8Lnh79a8kPx50Km5pr9zHVLntRvk/+HRyUErXV7n+BpY9eSA/KVoUhfQ
8Tb1rDYTTUELojFFEygNbTBoH5EWvzBpzM2F5Zjk9fXlywtaq9W0nj4ajPpJ
0mYrw63jfxHCWFmcMFKDOoDFNh1ovcYx1GqrE976sM9aZxdsvbYiT0kPIaEC
3HrWH+ZmwdpB6mvdJnm2ce5M1yesbX9DAKO5NF3S7IIUsPqKNDn1Gvk/UgdC
SIc8IU8aKJb0c447CoVEfPtUCOAE+ZbSBKrnlSzMmfquaeJltllvDdesZGWK
2qUtTVE3bW167z7WpkKdb3FDbnHDtMXtfMv2utOdZfuW4wmjE1o29dG4Zuut
MDqjTfjNFNQtfMj1DR7ym2nCBoWp1Q3o32kjaoXyibBBBBC308BSoqToghSw
RU4K3ASk6MWkMArSBMh24XYabxZlp4+Z7PgFZZcii+pJEUXpoiUIq0tRGI0k
iUIg/ImaSiEcmpROtKN0Wk48ASWqngoAkKBkFzFvotH2CLwJXMZMVjEijann
W2sTCTmfeht755u38Bvpif3mREegObXzgO45J7xVi6MBz4IwZIo3KKOatSCx
pi69H8zFxjXrADZtAJKa5LCjIbxpeybJrDRtQy80OKOUu02qC7cZ7w70aEg4
85DQFrtytuQjZVeQtGmgvx41eN+IeyH5ko7QNX93Ld+U15eGY23LOUF1zWIH
qK5X+7s5Jy+Nj4QOSe/oeDA41keVnF8G2lzHd6QdtYekhRcxvOEfdrO4/VNc
a01nMzdf+y7ozmyz/fhq+ps58+sOswL2Zy3ql955XcK1yVvoU65D+Fev4+9m
g0iARufsznBt8w5a220Brb+yvEmk6ERU/YtfS3eo529cY2l2re2s+9J4B8GC
bZaRn6pecWeqatVudjCObV1CBiDqYzo41nSU+ahsV6qR5nWk1sd+hP/BqXHH
8uzHF+c/3ZDWU9K5PDzsHh5CYesb4pnm2sOoZGoS13y/s1xQO0TT7R11Kfjl
39YHLWthvif1/6k/e/2m0WbkNSKFzxptspzNoIi3gU0snE3HcmyIyw5awIG1
SMCby5lXVEFcDsirH/73BhQCuD/c4P8WXLzV2lzz6/uduTPx1nLuDBtu/nVA
xB8vMuY+Pt5azuEGuC6pN3ykh7pd9EHlXECyTrG+JGukY55BtZgnhTBXT/ro
kFt96ZZJs1bDapsdhsAdMG0WunrkyYcnqCSPPzxGoO4Bd9HNg46AFgPpbAWd
Kou4p8Yi5qqxuAZ90gT6d7YPHcr9PfiArWHbm1mdoqNmZA3HSBb7X5K1daEJ
Ywq2i7WMmW+6h6jEcWqseYQYpIUXCFLUlKBjebZZrw1nfjmvzSiP9EfD9nBM
WvzCifiUf120yelmY3MRmu+R6BEx3KXGghF2S4U04akY/9jj4J4mAhJ4Sp4+
ZU8S0cioIR8Gv6iMR0IqHDOPCnhamopHeVQ8yqfC9vOosP08KkhsyoqBADZ4
Gv2pajGXb9u8R4tPC5pc5jK5vAeTZ0Ut5jK5vAeTZ2omsYQ3ubXzmoSnpfWp
laNOLYU2hTSsrTwa4GlpGjo5NHTyadjlCgIfl6aimUNFM5eKuXWXRwU+Lk1F
N4eKbrZ1W/McR8cefkY/xyTBl5BGba2Pa0jsGsxHfPODL8e0Cf4ISRUy4qUh
jcI4sDQ+oDCLEcOcGN3enl///Pz65h+grxpbtIGCm8t/XNQ5YAMgoyAnwG8T
Kz0/vz2XMAiE7SLXyoehDGLrQAFdf1WPfuaGb1aNfnidKtEPr6GIfrR7Rj8C
YX6UPBiz+TdcxkGg4Zo2TqRZCBSJgPyVyVbuXMewCcxv14AYIiKDCHji+RCh
LBMBSYisfm3ahm/d8ck3FoJORR5zpfLFTD0FjH0bLWwQFrcoQhmgYzcD2tY1
32+zuRI+99eA4TvfF8uYY40xPqZtrccNgPy+gllFvddAvfF8aGhG7jbWPOCB
+us0D20SNAfex1+HPKXB07AVWIVpQO325avnb168qvOG/XXnzF9PPpoGTC77
2qA/7PV6zLCUcOuN0yZ0MKb5UHPjY5uMhjoDYhHy4AhFBdgjazRI1s3WcFCy
gYAm+J8HpXG+xdNQMiEc73MsVslCKlZKHPiAcRChIux/vnzNxMJnysC5L5av
+6MRY2ZMIwq/fuczxYaZEtN41wTT8UCzWevyEfnd8lcEbGy7gSKwB41AwEx8
KjSeLf0I2INOBGd88crXEqtXPvr+KLhYswr8/5yqVq+g+acMyKd4g04+AQA6
7KL7Pf/h5vby5cXLy6u6z+AbQi4+MBN5fv6LfC5lK9kJZMCFqGtMiDrtS+NB
KaKwtjabNXGny10G1NqZZLMgdbFAh5S3sAsl81x8UdoPOhxZWnJxW0HJCchK
QjtJWV0oQ1zN89kA+uzN9fXF1e1EyIet3DAEP5n+s53rmo5/6xqOB1Mxa+Pc
oLQRWT2YxOl9Zjm6rrc1LSantVVOTp3ABvIEBTFcSUEF0d7egmp9YlENhkxU
w2FUpYQkUFqlhBX8CIQl/HiUh4NOgLaMZYbA97XLTycqjoYq0TApHg2YFEdH
USlaTtS7STFi8AmBkCFoJxguEMsDUw9HevRkXI7w86ATIkoIrk2U3gLXyJyk
W8uEVYgSBRjKT4J2zrBXdx6K4XZyeXV7cf32/MUE/l0+J999B9Vgfn15xX7H
xCzDZNGlMOPz2yTEChIw/tn7tQE4uH8UcLYKTvu1IcZHfTTGpcZBT74RjSlb
UA8MuZ7DeQUeo7yE2pmiT8WafGfBCB9o4zZEl61BX28PjpLh39JUaAso6pKN
ji4oCYy7G5eY73fADASCwUDIpzoCDcxo4g5E6ZtCYBEFBkbmy6lPaEGya68v
XmDXkn//m3CbSDwAvKxWPHhQ4wBQQJOIMzKwhtLvnYRzMo7Xj83HFA0nW4jP
D4UcHLOC0IJVqa9TaI+KhPaopNBsv4LQgkW0r1NopwUyOy0nsmUVkS2/bpGd
FYjsrKSWVTFN++s2zdMi0zwtaZrLKkJbft1COysS2lm20Ph7FwgkIIgbUT0y
ReV/wWQgNtLKYd6GoeB9IsZIypmFZHngIkpTLk3wcIwkJulitY8J2cqIW5j4
GthJdV8lTh6+jvi8cqT3UpxDfFHIPAyEVZhXgP9Xme/zboeJUOVuh9GsCucK
8P8q5zrv9iNanfNlNc6XXxjnQ97no1GK8xqLr4t7vprO21+Yzh+xnh/30q5O
TCtKCWFZTQjLL0cIld9FLOyN4Vd9GSEqVXkbIaooXkfQe76OkBgLsnZ6LE2O
XbhCkJ0DONiaxNzCVwzTHS6MeMRwTbLb4rLF/DCqOZ3O/Lc10WhXG3bHQ64z
nW+wowhPlJ7XbcvZfcB5flAymTDaJ5MGYeWP5IM3VzfnP15Mfnzx6vz2BvTo
EyHCR70wdTv2EIp55o+IBwZaG/Mw4BJd1NH9zTyeogKmgombxNmtp6bL380w
qY9EkbAfVjbUwYQQh8gVAQi0ElbCrcER7/YEeK0mV9hbNZ4SDlXECzfMPHQS
L/3qol6Q3CISw0Uxrkg0guW/0XDIeBzGF65oBo+0Ao9U8KgNJY+0LI/aMMIj
prDuxeNYw5dsrTFN9eNij37E/FGGI9WPCxWPmMl/n37EJwoe+zTBY19nPPZT
/bjYox8Zj1TwGOvHcjyW7McSPFb219BgVW/NqlTx1ayCwlP37+mpOb5cPz1k
bnrYi6SnYXemsua81cZlb4kfQwckM+dEDdGp3oqP0jR8F+ytMvPV+C6F3qCt
UdIS1wgleooSZlHZhOhh1hxftuYlnA47m4yoEiWS+TTaOKnh9hfD83ZrE4Rh
LZ02CBPGsaXle23y5F+9J3wTjO1vjLrdFmkKLIeYFQmjjD5RpTQIcVDa1nQQ
B16HQhzdSJ45Woyly40HPKlDlKUyOhJ55SKhQqaRaEPudSwqNxAIbLwswCYC
qhAm4mjgZ7i2L7LUbn6+vp28vLxi82vT3izrF9fXr67b5DHHfEyefDt/QmbG
zjM97kF2ztx0wVB/f9zmVJxEUZ4JlOe/8IiT9lliJdW1aB6+zHtBhEHeS0RG
QXGZxBfWzIgZCB1R2QwqAgJP2PazhuiYSMN60HBEnEFx2Yb7fdyyA0rQ74/Y
TcQocEU/uqTP3/+IPDbME0rG1zrPVRL0yI0qIltJPN8zXQk3iUTylfjPxCIS
tsQTM7Mp2T81U1LyqIAS28+nJD89M07JaR4hpwV0FEjEriCR01yJnBZIZFkg
kWUFiZzlEXJWQEeBRJYVJHKWK5GzfIlQbjfCgcitVSEldH+7wd1vEbvhPxWU
cLvJpmR/u5GUPCqgxPbzKdnbbiQhpwV0FEhkf7sJCCmQyLJAInvbjSTkrICO
AonsbzcBIQUSKRpw6MONOLRoyKEPN+bQokGHPtSoQ4uGHfpw4w4tGnjoQ408
tGjooQ839ui0KGijDxe10aKwjT5c3EaLAjf6UJEbLQrd6MPFbrQoeKMPFb3R
ovCNfm4bktS8Mz8uLNfzgyiuqRgYs4CyqGpmmFMzJ4zrNsWBAn2Yyo3xSIEB
TOyjiX3+P6n+69y6i87rIttTwuQ9Nv0HIe7WoZCFXKEoPl8PaO7wKXpCgrw0
toEd0fCtTtndt/dmJ9l5LVXfRQjhuXDZhOy940kS0ikiZFcgkv23PUlSmgWk
iJ1P2aTsv/dJktItIMVyZikVxLIMHYSCsMeJlm601YrrI1uagiGXazo3WDEK
V9J0sMWOGjPX9Ox4eW9Nl+FyS+UUIoRwTc8mZG9Nl4R0igjZFYhkf02XpDQL
SBGank3K/pouSekWkCI0PaaCpTQdX1Fo6UaTmi4siha5XvpgvpcWOV/6YN6X
Frpf+nD+lxY6YPqAHpgWDdX0wcZqWjRY0wcbrWnhcE0fbrymhQM2/cz6ArFn
NMZc44v4RIwJZRlR5jpIK8iKfII38CWI/zaP+G8LLG8dvP3PGpr2JkWOB99m
jAehRyoQC304uei0sI/oZyYmoWELY5bUsEdpzQKo9CsyLIwPqkSkNqRyHVTv
IEn8HaQmknvFa90e3+UzZHmZreFgHGwYTnSvIC3+2jCDNG2YTlGI0sYOcCtP
23DcpgMg7qiP1yhxMhax8YALt2Dlm8OU6fJ6ZLrfIH/jKnCcUoHMRWisE314
XBBKeWvM3CugXwKVZ+C0CgOn92FA6m0o/5w3dp9F/srlF0m+fHhc4C0i8s+m
/zPJX7mqVsxA5VQdR+ylq5qvE9arkrQT1lJk7uj3zNyJIM1Ps6RsR3JLXOWm
fn7agcCBxxfEd2OyYwJAyqTp/7FNnmUgziyER064aRZxiB0c5Sujj/zGWszN
BXlzczF5/erm8pcJ5stGj3bAAx0+nBx0QFf4iQI1loLD7xusuRPMo7Q9U6SF
dpvkUQIhG1wCnFBlSvzpCYfFfNONPSdvjzqWt+bpGjxDlaW2tbQwxS2bXLZd
5Y8trk1fvXnxogH6X/M/AKH2ZmawpOa6IBnzhr5jpySw8wMTQPCIhHs3Se3P
ANFyXYRFQAQo/jpJ5JdSrYdJ2PyC/Ig907F95iByKjq1nuw77FX/D7lDhx2+
gIdIII21mmfOxBDHi08Sm3wFBOEnBd8ZtoUZvW0yZUdokuXGcpZks/Nxs7dr
OEvoFYd4G9DHtYl5gh7vRCbp8DwMHCrHPY3tCoqUnhHa6/MjcPoaP9UCLjL1
nPxk3ZkOpibG9F5u7QGFuHCWtuWteNrOHTRuATFAGEtOBrITeWXSHDGTLGVK
YCXR5/HTT1LQqNzRwuzTT7ik/T/wfr7ZTW0Q8QJkHIYLfb7roD/UI0maqgNM
Cbgz6GuTb/2FBxpuEDcWbPsvmvdhLGNIeQZqipPUJntEBMJQ1s7YCKYQEEZO
CMfxEbEJC8/E8DzT9RMHtL5FPWNGo7HEziIoGqa49o/YkTn9EU3Z/9Wr2wn4
gOdqgZyj3O4rD175SxTHmJ8F0gvOAsGMR67Xk4XlWL5Zb8TUJPEwfiQvfxaO
IBIqvkFDVSdtIeLogCCWkIAZpwMQzMmPAl29urk9vw6PWEg/v7gKUbAzdmsK
5pF1fmqKzk9N0RRHXOy7216gMd9XONIieA+875EWCWmm92IqDmH48fzFzUXB
eStMapSfodIfxuZdMa4dswLXwRvnL5prnY3JerjnI8217VfgOni3/UVzPegn
DoFJc72swvXyq+B6yI++GeX1dRUNt78KDefDqD7O6+sqXC+/Bq4HA2bXg2F4
3l7wdYzg8KINiyXZPE74eGCH085OW5MDjIQqGkIDODEZrzSIGshVtP3o3gfk
9tHrDdtbKeOD5KmPYiuNRNFo3Gfbo7Nbm641qzw1l9UqzcxlJcXEfHDfiXmA
M39eDq6AfVxlGG5/7AR/QhmuOC6YXvCbieWIrScenjKPs7H5br3+KFdo/I/b
9WaO040ieBFUCni2VikaewvTDHbm1klYxtYh5WmKnO6xpBvPnPLx7Pr6d6wa
Cyo9kxVNFu5mPYG266z9EAAmjMZ2a3+ccApE1bYkCGeOyudi5ScAE7tyQAXX
xjtzwhUySsjCNc04cVz4Oht+2HWcFv8+f8muYxs7RH+IRTV5XlbkAe+Pu9gm
Gtyw/JTcpfsh1lfhdDCYIfrr7Ul1w9tY86pGx6pUMThWQWFsw3saG8eXNrRR
xNCOBm0NNZZfE8PPBg/iZZ9semXNVaudKoDkgdEwEwAwnDDvHNz5Zc7bZLrz
+UY0i+8GM+d8+1f4IoVibloPZxqF6Zdp0Nz8OvM9kBNbwBW0h5t5ECC6eBsC
3J8hrTxDIWgixzTKkNgxVVmRwdzv8xWDoFoVhQ4qKZR6dE+lDnHmKvaQxRfD
yAEqhExNtl+O/G7CmOx56E8hRoRO5mcpeuZs47COBv8Bg8ECppmG6xofYaA4
bCSWtKZbvAtHEMV4Y/h+MOSkwUVkFh1wjPguQVkdT3pWrHGFJ/q6J/Fvlcnl
WfTh/fBEDYLfJbM4r+wIkBXxtubMWligrRYoYINs7Z0Xnj09/eib3qGS8Rjb
uFfUdAIukzzaMbb4x9Hssgy5AN8Wy7N4LEqLavon4ugc+/YWdIAFkxNBfFja
vItzp4YQPJpO8l0wKs7a2NYB5ofXz34+v351+RwcBcMRKwIHg9UjrqBaZbk3
luGInJ9E+xrbe9nvh0FU8gt0giWtcaj4modkOPIRjUhp0Zc0+KoY5UusdPC5
DFH4g9KWmA9/H0NMWJ9gfKTx1dGItnqfxAAFA0kL9LiSpp4KP+NFWap53Arn
Xll28IhjTLymR5/H+CTZOdanBiljfkBBYC8CS7ywwALL1FcZ4X3GZkBg3GNs
5tUqjs280qcdmwXO3LEZvUHCKZAOuV1t1uAAXmxm71Z4Xjd+Fquj0Y7WEyoj
94iz3ePeboozJ17GD9yX+rKWN6g22cDCMNbBnROzejwmAx8yO2EfAI3sNE8b
SUFfi69GdmOfac0TrrJCdv8qwZM9Ozim5b6hoMaW26d0KM5c4FfsVRCXCaaE
L9MJopiDj/flAYgbdpxVm1z65losnBDfErNWiLAj3/bFQFrgEt+TVXzS9iQD
JvYNWjDwDEThl1+zYPQYDFHCjJCgoU6amUDsIBVdnqeCyLY5gCN5gE4OIM5V
cH6S2SQAjBhEM1NO8Q/iKiWQ+D6usiV2QIN4KS5cAVh2JrhjrM36FfwHaAHQ
aVSwo+THV8toc7JOsTUlaygMSq9kUCmEuTalD9vjPr4GwAt/wQqWIWZv6BGF
TOUX1yJRzWwV6WlZlPg+W9jPcYDga20nyRaseRg2pfHHv7gWPsapN8n7tJkC
NOv7YwrQrI+EqUDLY12Wx7osxMrK8j6DpQDN+lqVCnRXHm3mp5+SjGV/oCml
N/Ev64WPox2fkQunAM7eCasAzt6qqgKugnlZBfOyBOaoEpQHzk77VwHvqqDO
SZxPspj3Qa6Ylxjxs33YaMHDLXEUkVQuXqj6rlbYZhImcuaPDA/4cWIpH8h3
FgkXhaejJZ1U6qitpDKnDt6KsYfbWxFiFPrBlRcBCXGMwlYSMJxSBNL1AI3l
bHf+hIemKnx65FyupuFM2PwkhZRvIcxnP3bAV8xBIILUwVgxCChMH3aV7Fvl
2VEKMf+ntGtpbtsGwmf7V/AWT2jZ0Zp2bPmUSZs+JmkzdTLTnjSURNOaSqJG
ouq6v754gwAXIFa+WJL57WKxWBDP3XXiijnmaQVxWj7HBEERviCuATlsbCiq
iLmiUamQ4op4cfwMShVX4MWJ3hYPOIWAw8EFEHDY+x8DUzjXFM41gXMkjBAC
Dkf6QcDhYDwYmMK5pnCuKZxJxgEk6wCSeQDJPoBkIECykFiwDwxN6jFA6jJA
6jNA6jSQrJOE0A29d78fFQEDhD0mMXTYqRFFH0jMI56BGNx1t+8Na76jPAYI
+7tj6LBTOoo+kJhHvLsxuOuBjagHaC0LtKYFYtsCtXGBZpdAM0wgWiYQpY94
IGLKiXhy4ronsY86RGJ4zxMRE8HzCMQsNO6Xh1EMuMJhosadzzCKAX8vb50U
DwWKgJPXuvGAmhiYwrmmcK4JnIGiDaBoAyjaAIo2gKINIGmDZBxAsg4gmQeQ
7ANIBgIkCylIJlKQbKQgGUlBspKCZCZFup0kxNPqLZb94FUYIHHXyc7cKOgD
iXnSxpM7cwvUzc7c4oDEytuZGwV9IDFPrXxn5hZtWKC1LNCaFohtC9TGBZpd
As0wgWiZQJQ+EhkCUw4RTmRfEPm74SLGqAgxiDtzI9j0gH88JiqhEG/mFt61
FhvJ/BDS3UnunEiyb86Bl7wd/U7emJWf2n3ta7UbNdv5il9nmjfrbblb7ptN
xo+wZZYefolpUz1ns3ZXVfuLLPv2VO0rnrxHMti3zU5enNnW03K93TVzkVZd
pc3hDzaC9lJl8nFqPONZ02G+3urpsJ4Lz3rTWgEtFJRPZPWMdtbTo+WqNKdV
GIAWAWjWh94qAfhpuZSAfwtIC4VfMyUuVjPwq6a0kIf4JtYNEisnj/g5WJ/y
M7j+GiS4NQRMD5qAfcUImuWCo8WtZHk5OYC61bC3CocqWLm8cKzrCuM5GWG0
vG9wQtFHShW+ANNgp5AEfWu2CermnZRDbbdlcPsDI+Fb75ykd1WhNPEY7P9m
xsN3fHctosuoT3Mgz92K3FeImyFNZm0zLxL+wxz0uMczCsoPRtzUa+yP9tDI
QxQ2voRx8FBQJ8lbqxPAdc6e5D+YUL2jJ4PmJeBZu+/xaotqbsvNVIkoqB/Y
P5QG2LdO/e1DBZ9q0BmmTI/SCLX+uw1kZkc85iyPntf4FiH387RGyNkkJYE8
H667bFNb6Xyo0ohjvKXCqkkjMLMvjyA7HbGOgJmBzcs+3B6Zirjhjm7chQpv
0/MsZJH5oDRYNTrl53j5ChsuGC1VP98FM99bwp7KN83zGb9C5+/wE9LK45Qp
udVxypQE4zhlfTTl6mhp6yTKHNdttHt42kzG4jnXcWxNwK4IMtQBbObtXMiR
oVz7qULHfh8IEvdyK6eTbpJKlSm/xjIDmvzsXD91GPbS3qbLsjpeA3US6Qgv
NSGVdZh2OBN0mHY4l3KYtn4F7eoVMtcJtHm6nnUsojBRMHd2jCiYdjpGVB9D
tDpGvDpGhBr4/Phu1fxDIXVGRztvLXe+APq18L44H1+x14L89F8LcuXFNGsW
XmKboPOrJ7ciqdJI9L8feaZVvQZ0L2ZpiJ+DFkF4GVxtC7o8VCZQHAE+whGV
lb1obd5WDyKFW4ibWUEEE24hbma5iJFXjJ+qFUF4iU69yhgeweoaHlh1ZcmP
ti5GDrcuj7YuPYSuobjUpS7sGx8TZYFXhQhqIj98++NLdNZF5QrdeBq/xeyO
Q2sCtA1BRx405uCNXkwLek97b5QB33D06DToeG2rKBXMgPKunebdQbB/CV+d
KefmXLNTvmzv3ougj+qTN4oKnXiiI4TIFVhbyi0I+bp5qx+avUPrSt1Zsch1
M8k92F/UpzkLd8gzhJwv2ENX9XEf3r10XjOrWutnF/ON9aisK4HvPYrX0q+j
YpenCoFS9YWwl9O9zSDxeNqVpKdPvsOk+diNpS6us90k+QnXFnffuAAR4CdX
n51XQVeSZs5sjFVGEcszH8R3RokTcrbxmoPmI+vrMcljNmiNijpmjjGPVtwe
Y+6iqC0E3GIj1hZzN1VkzltX4dks0jTdWIdzxd7SCr+paPhVG8bL0GHvudO3
/OgZGX8bcusyb0X0grIxwjhs2+w7r9fzzHyH3gVqgsumf616yIHT+G9ueoOE
6LhilBjqtqIQ0WlVEWawuL7h3vO5/BBDhfYCXZfzcrHYTdfl5vB4pn6x+rO/
9nTJhGviI4SJU0MLWMQ0kk7phC66l17jQlxNyTuiYqenMz737vOeLD30tJzt
PY5CcXcgFHenMz/36FabIUGmPPF1B8OMrPMLUJJt81zt4kS2IQLhh7oaxwIR
yR07FVnfNgmb6oQqJA+FDB89n1Sc1E/LS7mJutxIrpEmAjbBNdLSpLpGWoqT
b4cq+1K+ZHCdjceTcXLYoiDDuLuxCLYq/ioH8uU+uylGs2W7vzj59lTtRNxc
ETOr4iFpW3HaOmvaJx5lYr9cb1cv2Rs513tzLk5aV1UrOPGABr8/qIPX7PmJ
ySGiUiz/4+cPbIn8wgq74DGB//jyY3Z1eX3JhJJnsqY0GYW6u1y97z3t7kww
i9NPpRm6pN5Dl5IHA1KP5XyAu7GLAys2wQUe3Vx+KkV1w7vvmrbhtHvlYo8t
szXeP8DqDePxKM/+iIzEfNZza2fRQQjoeo9SpgRFxSlTAovilPXRlKujpa2P
pkQjEHuN5rXF8D6zH2U2AZu0L+5HNE3hS5ChJmDdmMx2aYj1IrOy1MHj0XWl
bh37MC3GpZUvQqlm6obE62iviVru6ScWwlzysD/AkUQEi3h94gUrj8+QmoVB
NKhME3DCZ3S/qTCm05/5C3NgSG4rNsww9V+ulpvDv1Mx6MXGQgwfHooxNBv6
Dtmvh1UGdxnABG4m7EvKMIwyiw7Bt+dXWX57LmN9/PD54funT7/8ObnYN6fZ
X58+f/jpYTJasK8fPn6czMRdqNHLaf7x6/eJrNb/Q1E5gfC7AAA=
--2831159047-1185505748-937668768=:30766--From bouncefilter Sat Sep 18 12:40:23 1999
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net
[194.217.242.38]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA50426
for <hackers@postgresql.org>; Sat, 18 Sep 1999 12:40:05 -0400 (EDT)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
id 11SNWt-000LtO-0A
for hackers@postgreSQL.org; Sat, 18 Sep 1999 16:40:03 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id RAA28704; Sat, 18 Sep 1999 17:39:46 +0100 (BST)
Message-Id: <199909181639.RAA28704@mtcc.demon.co.uk>
Date: Sat, 18 Sep 1999 17:39:46 +0100 (BST)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] case bug?
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: EB2GGMyx3X0CVJVsEGj5fw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Following case statement is legal but fails in 6.5.1.
drop table t1;
DROP
create table t1(i int);
CREATE
insert into t1 values(-1);
INSERT 4047465 1
insert into t1 values(0);
INSERT 4047466 1
insert into t1 values(1);
INSERT 4047467 1select i,
case
when i < 0 then 'minus'
when i = 0 then 'zero'
when i > 0 then 'plus'
else null
end
from t1;
ERROR: Unable to locate type oid 0 in catalog
I'd kept this as an example of case usage and tried it on
the latest source, where it worked fine.
Then I tried inserting a NULL into the table, which the
case statement then treated as 0 and not null.
insert into t1 values(null);
INSERT 150412 1
select i,
case
when i < 0 then 'minus'
when i = 0 then 'zero'
when i > 0 then 'plus'
else null
end
from t1;
i|case
--+-----
-1|minus
0|zero
1|plus
|zero
(4 rows)
Was this discussed?
Keith.
From bouncefilter Sat Sep 18 13:21:23 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA55989;
Sat, 18 Sep 1999 13:20:41 -0400 (EDT)
(envelope-from a.joubert@albourne.com)
Received: from isadora.cy.albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.6X) with ESMTP
id UAA12443; Sat, 18 Sep 1999 20:23:06 +0300 (EET DST)
Received: from albourne.com (localhost [127.0.0.1])
by isadora.cy.albourne.com (8.9.3/8.9.3/Albourne/CYC/1.4) with ESMTP id
UAA02028; Sat, 18 Sep 1999 20:20:37 +0300 (EET DST)
Sender: a.joubert@albourne.com
Message-ID: <37E3C9E5.DAE0BC75@albourne.com>
Date: Sat, 18 Sep 1999 20:20:37 +0300
From: Adriaan Joubert <a.joubert@albourne.com>
Organization: APL Financial Services (Overseas) Ltd
X-Mailer: Mozilla 4.61 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgresql <pgsql-hackers@postgresql.org>, pgsql-patches@postgresql.org
Subject: Patches for alpha w. cc
Content-Type: multipart/mixed; boundary="------------882D822CCAF68377D905E516"
This is a multi-part message in MIME format.
--------------882D822CCAF68377D905E516
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Needed the following patches to get it to compile on a DS20. It is an
ev6, so it wasn't recognised and one of the defines in s_lock.h was
wrong.
Adriaan
--------------882D822CCAF68377D905E516
Content-Type: text/plain; charset=us-ascii;
name="p1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="p1"
*** postgresql-6.5.2/src/config.sub Sat Sep 18 19:00:31 1999
--- postgresql-6.5.2/src/config.sub.orig Tue Apr 20 03:26:31 1999
***************
*** 152,158 ****
tahoe | i860 | m32r | m68k | m68000 | m88k | ns32k | arc | arm \
| arme[lb] | pyramid | mn10200 | mn10300 | tron | a29k \
| 580 | i960 | h8300 | hppa | hppa1.0 | hppa1.1 | hppa2.0 \
! | alpha | alphaev5 | alphaev56 | alphaev6 | we32k | ns16k | clipper \
| i370 | sh | powerpc | powerpcle | 1750a | dsp16xx | pdp11 \
| mips64 | mipsel | mips64el | mips64orion | mips64orionel \
| mipstx39 | mipstx39el \
--- 152,158 ----
tahoe | i860 | m32r | m68k | m68000 | m88k | ns32k | arc | arm \
| arme[lb] | pyramid | mn10200 | mn10300 | tron | a29k \
| 580 | i960 | h8300 | hppa | hppa1.0 | hppa1.1 | hppa2.0 \
! | alpha | alphaev5 | alphaev56 | we32k | ns16k | clipper \
| i370 | sh | powerpc | powerpcle | 1750a | dsp16xx | pdp11 \
| mips64 | mipsel | mips64el | mips64orion | mips64orionel \
| mipstx39 | mipstx39el \
***************
*** 176,182 ****
| mips-* | pyramid-* | tron-* | a29k-* | romp-* | rs6000-* \
| power-* | none-* | 580-* | cray2-* | h8300-* | i960-* \
| xmp-* | ymp-* | hppa-* | hppa1.0-* | hppa1.1-* | hppa2.0*-* \
! | alpha-* | alphaev5-* | alphaev56-* | alphaev6-* | we32k-* | cydra-* \
| ns16k-* | pn-* | np1-* | xps100-* | clipper-* | orion-* \
| sparclite-* | pdp11-* | sh-* | powerpc-* | powerpcle-* \
| sparc64-* | mips64-* | mipsel-* \
--- 176,182 ----
| mips-* | pyramid-* | tron-* | a29k-* | romp-* | rs6000-* \
| power-* | none-* | 580-* | cray2-* | h8300-* | i960-* \
| xmp-* | ymp-* | hppa-* | hppa1.0-* | hppa1.1-* | hppa2.0*-* \
! | alpha-* | alphaev5-* | alphaev56-* | we32k-* | cydra-* \
| ns16k-* | pn-* | np1-* | xps100-* | clipper-* | orion-* \
| sparclite-* | pdp11-* | sh-* | powerpc-* | powerpcle-* \
| sparc64-* | mips64-* | mipsel-* \--------------882D822CCAF68377D905E516
Content-Type: text/plain; charset=us-ascii;
name="p2"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="p2"
*** postgresql-6.5.2/src/template/alpha_cc Sat Sep 18 19:00:58 1999
--- postgresql-6.5.2/src/template/alpha_cc.orig Sat Sep 18 19:12:47 1999
***************
*** 5,11 ****
# This is defined here because a bunch of clients include tmp/c.h,
# which is where the work is done on HP-UX. It only affects the
# backend on Ultrix and OSF/1.
- CC:cc
CFLAGS:-DNOFIXADE -std -O4 -Olimit 2000
SHARED_LIB:
ALL:
--- 5,10 ------------------882D822CCAF68377D905E516
Content-Type: text/plain; charset=us-ascii;
name="p3"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="p3"
*** postgresql-6.5.2/src/include/storage/s_lock.h Sat Sep 18 19:06:24 1999
--- postgresql-6.5.2/src/include/storage/s_lock.h.orig Fri Jul 30 20:07:17 1999
***************
*** 226,232 ****
* All non gcc
*/! #if defined(__alpha)
/*
* OSF/1 (Alpha AXP)
*
--- 226,232 ----
* All non gcc
*/! #if defined(__alpha__)
/*
* OSF/1 (Alpha AXP)
*
--------------882D822CCAF68377D905E516--
From bouncefilter Sat Sep 18 15:32:24 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA72855
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 15:32:11 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id PAA20709
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 15:31:36 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Notice: heap_open/close changes committed
Date: Sat, 18 Sep 1999 15:31:35 -0400
Message-ID: <20706.937683095@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I have just committed a ton of changes to make heap_open/heap_openr
take an additional argument specifying the kind of lock to grab on
the relation (or you can say "NoLock" to get the old, no-lock behavior).
Similarly, heap_close takes a new argument giving the kind of lock to
release, or "NoLock" to release no lock. (If you don't release the
lock you got at open time, it's implicitly held till transaction end.)
This should go a long way towards fixing problems caused by a concurrent
VACUUM moving tuples in system relations. I also fixed several bugs
(first spotted by Hiroshi) having to do with not getting a sufficient
lock on a relation being DROPped, ALTERed, etc. There may be more of
those still lurking, though.
There are a couple of coding rules that ought to be pointed out:
1. If you specify a lock type to heap_open/openr, then heap_open will
elog(ERROR) if the relation cannot be found --- since it can't get the
lock in that case, obviously. You must use NoLock (and then lock later,
if appropriate) if you want to be able to recover from no-such-relation.
This allowed extra code to test for no-such-rel to be removed from many
call sites. There were a lot of other call sites that neglected to test
for failure return at all, so they're now a little more robust.
2. I made most opens of system relations grab AccessShareLock if
read-only, or RowExclusiveLock if read-write, on the theory that
these accesses correspond to an ordinary search or update of a user
relation. This maximizes concurrency of access to the system tables.
It should be sufficient to have AccessExclusiveLock on the user relation
being modified in order to do most things like dropping/modifying
relations. Note however that we release these locks as soon as we
close the system relations, whereas the lock on the underlying relation
needs to be held till transaction commit to ensure that other users of
the relation will see whatever you did. There may be a few cases where
we need a stronger lock on system relations...
3. If you are doing a SearchSysCache (any flavor) to find a tuple that
you intend to modify/delete, you must open and lock the containing
relation *before* the search, not after. Otherwise you may retrieve
a tuple containing a stale physical location pointer (because VACUUM
has just moved it), which will cause the heap_replace or heap_delete
to crash and burn. There were a few places that did the heap_open
after getting the tuple. Naughty naughty.
I did not change locking behavior for index_open/close --- for the
most part we just acquire AccessShareLock on an index during
index_beginscan. I am not sure if this is good or not. I did make
index_open do elog(ERROR) on failure, because most call sites weren't
checking for failure...
These changes do *not* include Hiroshi's recent proposal to add
time qual checking in SearchSysCache. I suspect he is right but
would like confirmation from someone who actually understands the
time qual code ;-)
regards, tom lane
PS: you should do "make clean all" after pulling these changes.
From bouncefilter Sat Sep 18 15:38:24 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA73534
for <hackers@postgreSQL.org>; Sat, 18 Sep 1999 15:37:59 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id PAA20729;
Sat, 18 Sep 1999 15:37:17 -0400 (EDT)
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] case bug?
In-reply-to: Your message of Sat, 18 Sep 1999 17:39:46 +0100 (BST)
<199909181639.RAA28704@mtcc.demon.co.uk>
Date: Sat, 18 Sep 1999 15:37:17 -0400
Message-ID: <20727.937683437@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
Then I tried inserting a NULL into the table, which the
case statement then treated as 0 and not null.
This is a bug: the test expressions i < 0 etc are actually returning
NULL, but ExecEvalCase is failing to check for a NULL condition result.
It should treat a NULL as false, I expect, just as WHERE does.
regards, tom lane
From bouncefilter Sat Sep 18 15:59:24 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA78186
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 15:58:42 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id PAA20778
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 15:58:06 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Why do we need pg_vlock?
Date: Sat, 18 Sep 1999 15:58:06 -0400
Message-ID: <20775.937684686@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
It seems to me there's no fundamental reason why there couldn't be
two VACUUMs running concurrently in a database. With the locking
we are doing now, it should be safe enough. So, I'd like to propose
that we get rid of the pg_vlock lock file. It doesn't have any useful
purpose but it does force manual intervention by the dbadmin to recover
if a VACUUM crashes :-(
Comments? Did I miss something about why we can't have more than one
vacuum process?
regards, tom lane
From bouncefilter Sat Sep 18 16:14:28 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA80332;
Sat, 18 Sep 1999 16:14:18 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id QAA18416;
Sat, 18 Sep 1999 16:10:11 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909182010.QAA18416@candle.pha.pa.us>
Subject: Re: [INTERFACES] Re: [HACKERS] changes in 6.4
In-Reply-To: <35E0ABF0.578694C8@bellatlantic.net> from David Hartwig at "Aug
23, 1998 07:55:29 pm"
To: David Hartwig <daybee@bellatlantic.net>
Date: Sat, 18 Sep 1999 16:10:11 -0400 (EDT)
CC: hannu@trust.ee, pgsql-interfaces@postgreSQL.org, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
This is an old message, but still relivant. I belive 6.6 will have much
better OR memory usage.
Bruce Momjian wrote:
Hannu Krosing wrote:
The days where every release fixed server crashes, or added a feature
that users were 'screaming for' may be a thing of the past.Is anyone working on fixing the exploding optimisations for many OR-s,
at least the canonic case used by access?My impression is that this has fallen somewhere between
insightdist and Vadim.This is really big for the ODBCers. (And I suspect for JDBCers too.) Many
desktop libraries and end-user tools depend on this "record set" strategy to
operate effectively.I have put together a workable hack that runs just before cnfify(). The
option is activated through the SET command. Once activated, it identifies
queries with this particular multi-OR pattern generated by these RECORD SET
strategies. Qualified query trees are rewritten as multiple UNIONs. (One
for each OR grouping).The results are profound. Queries that used to scan tables because of the
ORs, now make use of any indexes. Thus, the size of the table has virtually
no effect on performance. Furthermore, queries that used to crash the
backend, now run in under a second.Currently the down sides are:
1. If there is no usable index, performance is significantly worse. The
patch does not check to make sure that there is a usable index. I could use
some pointers on this.2. Small tables are actually a bit slower than without the patch.
3. Not very elegant. I am looking for a more generalized solution.
I have lots of ideas, but I would need to know the backend much better before
attempting any of them. My favorite idea is before cnfify(), to factor the
OR terms and pull out the constants into a virtual (temporary) table spaces.
Then rewrite the query as a join. The optimizer will (should) treat the new
query accordingly. This assumes that an efficient factoring algorithm exists
and that temporary tables can exist in the heap.Illustration:
SELECT ... FROM tab WHERE
(var1 = const1 AND var2 = const2) OR
(var1 = const3 AND var2 = const4) OR
(var1 = const5 AND var2 = const6)SELECT ... FROM tab, tmp WHERE
(var1 = var_x AND var2 = var_y)tmp
var_x | var_y
--------------
const1|const2
const3|const4
const5|const6David, where are we on this? I know we have OR's using indexes. Do we
still need to look this as a fix, or are we OK. I have not gotten far
enough in the optimizer to know how to fix theBruce,
If the question is, have I come up with a solution for the cnf'ify problem: No
If the question is, is it still important: Very much yes.
It is essential for many RAD tools using remote data objects which make use of key
sets. Your recent optimization of the OR list goes a long way, but inevitably
users are confronted with multi-part keys.When I look at the problem my head spins. I do not have the experience (yet?)
with the backend to be mucking around in the optimizer. As I see it, cnf'ify is
doing just what it is supposed to do. Boundless boolean logic.I think hope may lay though, in identifying each AND'ed group associated with a key
and tagging it as a special sub-root node which cnf'ify does not penetrate. This
node would be allowed to pass to the later stages of the optimizer where it will be
used to plan index scans. Easy for me to say.In the meantime, I still have the patch that I described in prior email. It has
worked well for us. Let me restate that. We could not survive without it!
However, I do not feel that is a sufficiently functional approach that should be
incorporated as a final solution. I will submit the patch if you, (anyone) does
not come up with a better solution. It is coded to be activated by a SET KSQO to
minimize its reach.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sat Sep 18 16:31:25 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA82900
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 16:30:49 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id QAA18799;
Sat, 18 Sep 1999 16:25:40 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909182025.QAA18799@candle.pha.pa.us>
Subject: Re: [HACKERS] Why do we need pg_vlock?
In-Reply-To: <20775.937684686@sss.pgh.pa.us> from Tom Lane at "Sep 18,
1999 03:58:06 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 18 Sep 1999 16:25:40 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
It seems to me there's no fundamental reason why there couldn't be
two VACUUMs running concurrently in a database. With the locking
we are doing now, it should be safe enough. So, I'd like to propose
that we get rid of the pg_vlock lock file. It doesn't have any useful
purpose but it does force manual intervention by the dbadmin to recover
if a VACUUM crashes :-(Comments? Did I miss something about why we can't have more than one
vacuum process?
I vote for removal. Lock files are hacks, usually.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sat Sep 18 16:36:25 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA83519
for <pgsql-hackers@postgresql.org>;
Sat, 18 Sep 1999 16:36:23 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from lowen.wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id QAA09559;
Sat, 18 Sep 1999 16:36:04 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
Date: Sat, 18 Sep 1999 16:27:08 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
References: <37E1E580.A7C66E57@flame.co.za>
MIME-Version: 1.0
Message-Id: <99091816355500.00581@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit
On Fri, 17 Sep 1999, Theo Kramer wrote:
Dont know if it's been raised before, but the postgres utilities are installed
into /usr/bin from the rpm. Problem with this is the naming of some of the
utilities eg.createuser, destroyuser. These could be confused with the
'standard' user utilities such as useradd, userdel etc. How about pre-pending
a 'pg' to all postgres utilities so that these become pgcreateuser,
pgdestroyuser etc.?
This is an interesting idea.
What is also interesting is that if you have a traditional postgresql
installation (/usr/local/pgsql), you can get even wierder results if /usr/bin
contains one createuser and /usr/local/pgsql/bin contains another. Depending
upon your PATH, you could get unwanted results in a hurry.
So, it IS an interesting thought -- while it would initially create a good deal
of confusion, what is the consensus of the hackers on this issue?? Prepending
"pg_" to all postgresql commands seems to me to be a good idea (after all, we
already hav pg_dump, pg_dumpall, pg_upgrade, etc.).
Thoughts??
Lamar Owen
WGCR Internet Radio
From bouncefilter Sat Sep 18 16:46:25 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA84872
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 16:46:08 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id QAA20852
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 16:45:37 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: setheapoverride() considered harmful
Date: Sat, 18 Sep 1999 16:45:37 -0400
Message-ID: <20849.937687537@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I think we need to get rid of setheapoverride().
As far as I can tell, its purpose is to make tuples created in the
current transaction's current command be considered valid, whereas
ordinarily they'd not be considered valid until the next command starts.
But there is another way to make just-written tuples become valid:
CommandCounterIncrement(). Looking around, I see that some code is
using CommandCounterIncrement() to achieve the same result that other
code is using setheapoverride() for.
The trouble with setheapoverride is that you can turn it off. For
example, execMain.c uses the following code to start a SELECT INTO:
intoRelationId = heap_create_with_catalog(intoName,
tupdesc, RELKIND_RELATION, parseTree->isTemp);
setheapoverride(true);
intoRelationDesc = heap_open(intoRelationId,
AccessExclusiveLock);
setheapoverride(false);
The pg_class tuple inserted by heap_create will not be valid in
the current command, so we have to do *something* to allow heap_open
to see it. The problem with the above sequence is that once we do
setheapoverride(false), all of a sudden we can't see the tuples inserted
by heap_create anymore. What happens if we need to see them again
during the current command?
An example where we will actually crash and burn (I believe; haven't
tried to make it happen) is if an SI Reset message arrives later during
the startup of the SELECT INTO, say while we are acquiring read locks
on the source table(s). relcache.c will try to rebuild all the relcache
entries, and will fail on the intoRelation because it can't see the
pg_class tuple for it.
It seems to me that a much cleaner and safer implementation is
intoRelationId = heap_create_with_catalog(intoName,
tupdesc, RELKIND_RELATION, parseTree->isTemp);
/* Start a new command so that we see results of heap_create */
CommandCounterIncrement();
intoRelationDesc = heap_open(intoRelationId,
AccessExclusiveLock);
since this way the tuples still look valid if we look at them again
later in the same command.
Comments? Anyone know a reason not to get rid of setheapoverride?
regards, tom lane
From bouncefilter Sat Sep 18 16:53:25 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA85632
for <pgsql-hackers@postgresql.org>;
Sat, 18 Sep 1999 16:52:38 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA61283
for <pgsql-hackers@postgresql.org>;
Sat, 18 Sep 1999 17:52:50 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 18 Sep 1999 17:52:50 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: v6.5.2 vacuum...?
Message-ID: <Pine.BSF.4.10.9909181751330.27097-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Just tried to do a vacuum analyze on a new database, and the backend
started spewing out:
FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32
Fresh build of the server, FreeBSD 3.3...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sat Sep 18 17:03:25 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA87096
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 17:02:35 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA20972;
Sat, 18 Sep 1999 17:00:41 -0400 (EDT)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-reply-to: Your message of Sat, 18 Sep 1999 16:27:08 -0400
<99091816355500.00581@lowen.wgcr.org>
Date: Sat, 18 Sep 1999 17:00:41 -0400
Message-ID: <20970.937688441@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Lamar Owen <lamar.owen@wgcr.org> writes:
So, it IS an interesting thought -- while it would initially create a
good deal of confusion, what is the consensus of the hackers on this
issue?? Prepending "pg_" to all postgresql commands seems to me to be
a good idea (after all, we already hav pg_dump, pg_dumpall,
pg_upgrade, etc.).
I don't see a need to change the names of psql or ecpg, which just
happen to be the things most commonly invoked by users. I'd be in favor
of prepending pg_ to all the "admin-type" commands like createuser.
Especially the createXXX/destroyXXX/initXXX ones, which seem the most
likely to cause naming conflicts.
While we are thinking about this, I wonder if it wouldn't be a good idea
to separate out the executables that aren't really intended to be
executed willy-nilly, and put them in a different directory.
postmaster, postgres, and initdb have no business being in users' PATH
at all, ever. You could make a case that some of the other executables
are admin tools not intended for ordinary mortals, as well, and should
not live in a directory that might be put in users' PATH.
Of course, the other way an admin can handle that issue is not to put
/usr/local/pgsql/bin into PATH, but to make symlinks from a more popular
directory (say, /usr/local/bin) for the programs that users are expected
to execute. I suppose such an admin could stick pg_ on the front of the
symlinks anyway. But then the program names don't match the
documentation we supply, which would be confusing.
regards, tom lane
From bouncefilter Sat Sep 18 17:27:25 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA89872
for <pgsql-hackers@postgresql.org>;
Sat, 18 Sep 1999 17:26:47 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from lowen.wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id RAA09637;
Sat, 18 Sep 1999 17:23:31 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
Date: Sat, 18 Sep 1999 17:15:07 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
Cc: Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
References: <20970.937688441@sss.pgh.pa.us>
MIME-Version: 1.0
Message-Id: <99091817232103.00581@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit
On Sat, 18 Sep 1999, Tom Lane wrote:
While we are thinking about this, I wonder if it wouldn't be a good idea
to separate out the executables that aren't really intended to be
executed willy-nilly, and put them in a different directory.
postmaster, postgres, and initdb have no business being in users' PATH
at all, ever.
Such as /usr/sbin on a Linux FSSTND-compliant system (such as RedHat). In
fact, I may just do that with the RPM distribution (after consulting with RedHat
on the issue). Thomas?? The same goes for the admin commands' man pages --
they should be in section 8 on the typical Linux box.
to execute. I suppose such an admin could stick pg_ on the front of the
symlinks anyway. But then the program names don't match the
documentation we supply, which would be confusing.
Well, as things stand, the documentation and the rpm distribution don't match
in other areas -- I personally would have absolutely no problem whatsoever in
doing such a renaming -- hey, I can do such inside the RPM, for that matter,
but I don't want to. Of course, I would follow whatever the core group decides
-- that is the standard. I'm just tossing ideas.
Lamar Owen
WGCR Internet Radio
From bouncefilter Sat Sep 18 17:31:26 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA90461
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 17:30:49 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA19558;
Sat, 18 Sep 1999 17:25:44 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909182125.RAA19558@candle.pha.pa.us>
Subject: Re: [HACKERS] setheapoverride() considered harmful
In-Reply-To: <20849.937687537@sss.pgh.pa.us> from Tom Lane at "Sep 18,
1999 04:45:37 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 18 Sep 1999 17:25:43 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I think we need to get rid of setheapoverride().
I have always wondered what it did. It is in my personal TODO with a
questionmark. Never figured out its purpose.
since this way the tuples still look valid if we look at them again
later in the same command.Comments? Anyone know a reason not to get rid of setheapoverride?
Yes, please remove it.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sat Sep 18 18:01:26 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA94002
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 18:00:45 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA19883;
Sat, 18 Sep 1999 17:36:11 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909182136.RAA19883@candle.pha.pa.us>
Subject: Re: [HACKERS] Some progress on INSERT/SELECT/GROUP BY bugs
In-Reply-To: <13811.926640105@sss.pgh.pa.us> from Tom Lane at "May 13,
1999 08:01:45 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 18 Sep 1999 17:36:11 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tom, is this fixed?
I believe I've identified the main cause of the peculiar behavior we
are seeing with INSERT ... SELECT ... GROUP/ORDER BY: it's a subtle
parser bug.Here is the test case I'm looking at:
CREATE TABLE si_tmpverifyaccountbalances (
type int4 NOT NULL,
memberid int4 NOT NULL,
categoriesid int4 NOT NULL,
amount numeric);CREATE TABLE invoicelinedetails (
invoiceid int4,
memberid int4,
totshippinghandling numeric,
invoicelinesid int4);INSERT INTO si_tmpverifyaccountbalances SELECT invoiceid+3,
memberid, 1, totshippinghandling FROM invoicelinedetails
GROUP BY invoiceid+3, memberid, totshippinghandling;ERROR: INSERT has more expressions than target columns
The reason this is coming out is that the matching of GROUP BY (also ORDER BY) items to targetlist entries is fundamentally broken in this context. The GROUP BY items "memberid" and "totshippinghandling" are simply unvarnished Ident nodes when they arrive at findTargetlistEntry() in parse_clause.c; what findTargetlistEntry() does with them is to try to match them against the resdom names of the existing targetlist items. I think that's correct behavior in the plain SELECT case (but note it means "SELECT a AS b, b AS c GROUP BY b" will really group by a not b --- is that per spec??). But it fails miserably in the INSERT/SELECT case, because by the time control gets here, the targetlist items have been given resdom names *corresponding to the column names of the target table*.So, in the example at hand, "memberid" is matched to the correct column
by pure luck (because it has the same name in the destination table),
and then "totshippinghandling" is not recognized as one of the existing
TLEs because it does not match any destination column name.Now, call me silly, but it seems to me that SELECT ... GROUP BY ought
to mean the same thing no matter whether there is an INSERT in front of
it or not, and thus that letting target column names affect the meaning
of GROUP BY items is dead wrong. (Don't have a spec to check this with,
however.)I believe the most reasonable fix for this is to postpone relabeling
of the targetlist entries with destination column names until after
analysis of the SELECT's subsidiary clauses is complete. In particular,
it should *not* be done instantly when each TLE is made, which is what
MakeTargetEntryIdent currently does. The TLEs should have the same
resnames as in the SELECT case until after subsidiary clause processing
is done.(MakeTargetEntryIdent is broken anyway because it tries to associate
a destination column with every TLE, even the resjunk ones. The reason
we see the quoted error message in this situation is that after
findTargetlistEntry fails to detect that totshippinghandling is already
a TLE, it calls MakeTargetEntryIdent to make a junk TLE for
totshippinghandling, and then MakeTargetEntryIdent tries to find a
target column to go with the junk TLE. So the revised code should only
assign dest column names to non-junk TLEs.)I'm not really familiar enough with the parser to want to tackle this
size of change by myself --- Thomas, do you want to do it? I think it's
largely a matter of moving code around, but I'm not sure where is the
right place for it...regards, tom lane
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sat Sep 18 18:02:26 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA94090
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 18:01:37 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA19904;
Sat, 18 Sep 1999 17:38:16 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909182138.RAA19904@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <20970.937688441@sss.pgh.pa.us> from Tom Lane at "Sep 18,
1999 05:00:41 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 18 Sep 1999 17:38:16 -0400 (EDT)
CC: Lamar Owen <lamar.owen@wgcr.org>, Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lamar Owen <lamar.owen@wgcr.org> writes:
So, it IS an interesting thought -- while it would initially create a
good deal of confusion, what is the consensus of the hackers on this
issue?? Prepending "pg_" to all postgresql commands seems to me to be
a good idea (after all, we already hav pg_dump, pg_dumpall,
pg_upgrade, etc.).I don't see a need to change the names of psql or ecpg, which just
happen to be the things most commonly invoked by users. I'd be in favor
of prepending pg_ to all the "admin-type" commands like createuser.
Especially the createXXX/destroyXXX/initXXX ones, which seem the most
likely to cause naming conflicts.
I have been thinking, the destroy should be drop, in keeping with SQL.
destroy was a QUEL'ism.
While we are thinking about this, I wonder if it wouldn't be a good idea
to separate out the executables that aren't really intended to be
executed willy-nilly, and put them in a different directory.
postmaster, postgres, and initdb have no business being in users' PATH
at all, ever. You could make a case that some of the other executables
are admin tools not intended for ordinary mortals, as well, and should
not live in a directory that might be put in users' PATH.
Seems like it could make it harder for newbies.
Of course, the other way an admin can handle that issue is not to put
/usr/local/pgsql/bin into PATH, but to make symlinks from a more popular
directory (say, /usr/local/bin) for the programs that users are expected
to execute. I suppose such an admin could stick pg_ on the front of the
symlinks anyway. But then the program names don't match the
documentation we supply, which would be confusing.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sat Sep 18 18:08:26 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA95068
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 18:08:15 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA23106;
Sat, 18 Sep 1999 18:07:33 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Some progress on INSERT/SELECT/GROUP BY bugs
In-reply-to: Your message of Sat, 18 Sep 1999 17:36:11 -0400 (EDT)
<199909182136.RAA19883@candle.pha.pa.us>
Date: Sat, 18 Sep 1999 18:07:33 -0400
Message-ID: <23104.937692453@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
Tom, is this fixed?
I believe I've identified the main cause of the peculiar behavior we
are seeing with INSERT ... SELECT ... GROUP/ORDER BY: it's a subtle
parser bug.
I believe the most reasonable fix for this is to postpone relabeling
of the targetlist entries with destination column names until after
analysis of the SELECT's subsidiary clauses is complete.
Yes, for 6.6. There are some other INSERT ... SELECT cases that can't
be fixed until we have separate targetlists for the INSERT and the
source SELECT --- but I did take care of this particular issue. The
column relabeling etc doesn't happen until after we've finished with
analyzing the SELECT subclause.
regards, tom lane
From bouncefilter Sat Sep 18 18:20:26 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA98418
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 18:19:40 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA23189;
Sat, 18 Sep 1999 18:18:36 -0400 (EDT)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] v6.5.2 vacuum...?
In-reply-to: Your message of Sat, 18 Sep 1999 17:52:50 -0300 (ADT)
<Pine.BSF.4.10.9909181751330.27097-100000@thelab.hub.org>
Date: Sat, 18 Sep 1999 18:18:36 -0400
Message-ID: <23187.937693116@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Just tried to do a vacuum analyze on a new database, and the backend
started spewing out:
FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32
I'm not seeing it here with a REL6_5 build from Thursday. It looks
suspiciously like a problem I thought I'd fixed a good while back,
wherein the backend didn't behave too gracefully if the client
disconnected early.
regards, tom lane
From bouncefilter Sat Sep 18 18:40:26 1999
Received: from durham2-011.dsl.gtei.net (postfix@durham2-011.dsl.gtei.net
[4.3.2.11]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA01114
for <pgsql-hackers@postgresql.org>;
Sat, 18 Sep 1999 18:39:27 -0400 (EDT)
(envelope-from mdorman@durham2-011.dsl.gtei.net)
Received: by durham2-011.dsl.gtei.net (Postfix, from userid 1000)
id 776CFCB802; Sat, 18 Sep 1999 18:38:55 -0400 (EDT)
Sender: mdorman@juliet.private.net
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <20970.937688441@sss.pgh.pa.us>
<99091817232103.00581@lowen.wgcr.org>
From: Michael Alan Dorman <mdorman@debian.org>
Date: 18 Sep 1999 18:38:55 -0400
In-Reply-To: Lamar Owen's message of "Sat, 18 Sep 1999 17:15:07 -0400"
Message-ID: <87emfvhmkg.fsf@juliet.private.net>
Lines: 11
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lamar Owen <lamar.owen@wgcr.org> writes:
Such as /usr/sbin on a Linux FSSTND-compliant system (such as RedHat). In
fact, I may just do that with the RPM distribution (after consulting with RedHat
on the issue).
Actually, I would even advocate what GNU configure calls the "libexec"
directory---a directory like /usr/lib/emacs/i386-linux, which has
movemail and a couple of other things that aren't meant to be run by
users, but invoked by other programs.
Mike.
From bouncefilter Sat Sep 18 19:30:27 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA06894
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 19:30:13 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id UAA62141;
Sat, 18 Sep 1999 20:30:27 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 18 Sep 1999 20:30:23 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] v6.5.2 vacuum...?
In-Reply-To: <23187.937693116@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9909182029040.27097-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Okay, was able to do a subsequent vacuum and vacuum analyze...but, the
psql was running onthe same machine as the server, so I'm curious as to
why it would have disconnected...?
Also, side note...\h vacuum shows that 'vacuum [verbose] analyze' should
work, but if you try and run it,it gives an error...error in psql's help,
or the backend?
On Sat, 18 Sep 1999, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Just tried to do a vacuum analyze on a new database, and the backend
started spewing out:FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32I'm not seeing it here with a REL6_5 build from Thursday. It looks
suspiciously like a problem I thought I'd fixed a good while back,
wherein the backend didn't behave too gracefully if the client
disconnected early.regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sat Sep 18 19:32:27 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA07045
for <hackers@postgreSQL.org>; Sat, 18 Sep 1999 19:32:00 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id TAA24634;
Sat, 18 Sep 1999 19:31:27 -0400 (EDT)
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] case bug?
In-reply-to: Your message of Sat, 18 Sep 1999 15:37:17 -0400
<20727.937683437@sss.pgh.pa.us>
Date: Sat, 18 Sep 1999 19:31:27 -0400
Message-ID: <24631.937697487@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
Then I tried inserting a NULL into the table, which the
case statement then treated as 0 and not null.
This is a bug: the test expressions i < 0 etc are actually returning
NULL, but ExecEvalCase is failing to check for a NULL condition result.
It should treat a NULL as false, I expect, just as WHERE does.
Fixed --- here is the patch for REL6_5.
regards, tom lane
*** src/backend/executor/execQual.c.orig Sat Jun 12 15:22:40 1999
--- src/backend/executor/execQual.c Sat Sep 18 19:28:46 1999
***************
*** 1128,1136 **** /*
* if we have a true test, then we return the result, since the
! * case statement is satisfied.
*/
! if (DatumGetInt32(const_value) != 0)
{
const_value = ExecEvalExpr((Node *) wclause->result,
econtext,
--- 1128,1137 ---- /*
* if we have a true test, then we return the result, since the
! * case statement is satisfied. A NULL result from the test is
! * not considered true.
*/
! if (DatumGetInt32(const_value) != 0 && ! *isNull)
{
const_value = ExecEvalExpr((Node *) wclause->result,
econtext,
From bouncefilter Sat Sep 18 19:40:27 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA08596
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 19:39:40 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id TAA24672;
Sat, 18 Sep 1999 19:38:33 -0400 (EDT)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] v6.5.2 vacuum...?
In-reply-to: Your message of Sat, 18 Sep 1999 20:30:23 -0300 (ADT)
<Pine.BSF.4.10.9909182029040.27097-100000@thelab.hub.org>
Date: Sat, 18 Sep 1999 19:38:33 -0400
Message-ID: <24670.937697913@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Also, side note...\h vacuum shows that 'vacuum [verbose] analyze' should
work, but if you try and run it,it gives an error...error in psql's help,
or the backend?
??? Works for me ... in fact that's how I usually run vacuum:
play=> vacuum verbose analyze;
NOTICE: --Relation pg_type--
NOTICE: Pages 2: Changed 0, Reapped 1, Empty 0, New 0; Tup 114: Vac 1, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 109, MaxLen 109; Re-using: Free/Avail. Space 3076/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec.
NOTICE: Index pg_type_typname_index: Pages 2; Tuples 114: Deleted 1. Elapsed 0/0 sec.
NOTICE: Index pg_type_oid_index: Pages 2; Tuples 114: Deleted 1. Elapsed 0/0 sec.
NOTICE: --Relation pg_attribute--
NOTICE: Pages 6: Changed 0, Reapped 1, Empty 0, New 0; Tup 422: Vac 7, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 97, MaxLen 97; Re-using: Free/Avail. Space 3080/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec.
NOTICE: Index pg_attribute_attrelid_index: Pages 4; Tuples 422: Deleted 7. Elapsed 0/0 sec.
[ etc etc etc ]
What error do you get exactly?
regards, tom lane
From bouncefilter Sat Sep 18 20:03:27 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA36586
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 20:02:38 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA62266;
Sat, 18 Sep 1999 21:00:55 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 18 Sep 1999 21:00:54 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] v6.5.2 vacuum...?
In-Reply-To: <24670.937697913@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9909182100370.27097-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Odd...I must have typ'd something wrong the last time, cause now it works
for me too *sigh*
On Sat, 18 Sep 1999, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Also, side note...\h vacuum shows that 'vacuum [verbose] analyze' should
work, but if you try and run it,it gives an error...error in psql's help,
or the backend???? Works for me ... in fact that's how I usually run vacuum:
play=> vacuum verbose analyze;
NOTICE: --Relation pg_type--
NOTICE: Pages 2: Changed 0, Reapped 1, Empty 0, New 0; Tup 114: Vac 1, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 109, MaxLen 109; Re-using: Free/Avail. Space 3076/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec.
NOTICE: Index pg_type_typname_index: Pages 2; Tuples 114: Deleted 1. Elapsed 0/0 sec.
NOTICE: Index pg_type_oid_index: Pages 2; Tuples 114: Deleted 1. Elapsed 0/0 sec.
NOTICE: --Relation pg_attribute--
NOTICE: Pages 6: Changed 0, Reapped 1, Empty 0, New 0; Tup 422: Vac 7, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 97, MaxLen 97; Re-using: Free/Avail. Space 3080/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec.
NOTICE: Index pg_attribute_attrelid_index: Pages 4; Tuples 422: Deleted 7. Elapsed 0/0 sec.
[ etc etc etc ]What error do you get exactly?
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sat Sep 18 22:17:29 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA59024
for <pgsql-hackers@postgreSQL.org>;
Sat, 18 Sep 1999 22:16:28 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id WAA22498;
Sat, 18 Sep 1999 22:07:19 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909190207.WAA22498@candle.pha.pa.us>
Subject: Re: [HACKERS] v6.5.2 vacuum...?
In-Reply-To: <Pine.BSF.4.10.9909182029040.27097-100000@thelab.hub.org> from
The
Hermit Hacker at "Sep 18, 1999 08:30:23 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Sat, 18 Sep 1999 22:07:19 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Okay, was able to do a subsequent vacuum and vacuum analyze...but, the
psql was running onthe same machine as the server, so I'm curious as to
why it would have disconnected...?Also, side note...\h vacuum shows that 'vacuum [verbose] analyze' should
work, but if you try and run it,it gives an error...error in psql's help,
or the backend?
Worked here:
vacuum verbose analyze pg_class;
On Sat, 18 Sep 1999, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Just tried to do a vacuum analyze on a new database, and the backend
started spewing out:FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32I'm not seeing it here with a REL6_5 build from Thursday. It looks
suspiciously like a problem I thought I'd fixed a good while back,
wherein the backend didn't behave too gracefully if the client
disconnected early.regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org************
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sat Sep 18 23:07:30 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA65620;
Sat, 18 Sep 1999 23:06:33 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from lowen.wgcr.org (dial-18.r9.ncbrvr.Infoave.Net [206.74.37.146])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id XAA09913;
Sat, 18 Sep 1999 23:06:41 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: pgsql-ports@postgresql.org, pgsql-hackers@postgresql.org,
lockhart@alumni.caltech.edu, jbj@redhat.com
Subject: PostgreSQL-6.5.1-0.7lo RPMs available.
Date: Sat, 18 Sep 1999 22:41:43 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99091823062602.00629@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit
While I realize 6.5.2 is now an Official Release (TM), per RedHat's wishes I
have limited myself to 6.5.1 for my RPM series until a working upgradeable
release. Hopefully, this is it.
Announcing beta-quality, Version 6.5.1, release 0.7lo rpms with UPGRADING!!!
also featuring automatic database initialization after installation (if there's
no database there already, that is). No more wishing for the days of the
postgresql-data package.
Get the scoop at http://www.ramifordistat.net/postgres. PLEASE PLEASE pound on
this release. I have successfully upgraded a virgin RedHat 6.0 machine (NOT
the one on which the RPM's were built) from the version 6.4.2 rpms that shipped
with RedHat 6.0. The sequence to complete an upgrade is found in
/usr/doc/postgresql-6.5.1/README.rpm after installation/upgrade.
Binary rpms are available built for RedHat 6.0/Intel. A SRPM is also available,
as will be RedHat 5.2 RPM's for Intel after Monday or Tuesday. A tested build
on Alpha and Sparc would be most appreciated. Bang on it!
Many many thanks to Oliver Elphick, who had already been down a similar (but
not identical) road with Debian, and had already conquered some of the issues --
and a ready-built script that needed moderate modification for the RedHat
context. Oliver, it is scary how much alike we think -- although I envy you:
Debian has far fewer restrictions in package scripts than RedHat.
Send bug reports to me, with a CC: to Thomas Lockhart and Jeff Johnson.
Lamar Owen
WGCR Internet Radio
Changelog:
* Sat Sep 18 1999 Lamar Owen <lamar.owen@wgcr.org>
- 0.7lo
- First stab at integrating modified versions of the Debian migration scripts.
-- Courtesy Oliver Elphick, Debian package maintainer, PostgreSQL Global
-- Development Group.
- /usr/lib/pgsql/backup/pg_dumpall_new -- a modifed pg_dumpall used in the
-- migration -- modified to work with the older executables.
- /usr/bin/postgresql-dump -- the migration script.
- Upgrade strategy:
-- 1.) %pre for main package saves old package's executables
-- 2.) the postgresql init script in -server detects PGDATA existence
-- and version, notifies user if upgrade is necessary
-- 3.) Rather than fully automating upgrade, the tools are provided:
-- a.) /usr/bin/postgresql_dump
-- b.) /usr/lib/pgsql/backup/pg_dumpall_new
-- c.) The executables backed up by %pre in /usr/lib/pgsql/backup
-- 4.) Documentation on RPM differences and upgrades in README.rpm
-- 5.) A fully automatic upgrade can be facilitated by some more code
-- in /etc/rc.d/init.d/postgresql, if desired.
- added documentation for rpm setup, and upgrade (README.rpm)
- added newer man pages from Thomas Lockhart
- Put the PL's in the right place -- /usr/lib/pgsql, not /usr/lib. My error.
- Added Requires: postgresql = %{version} for all sub packages.
- Need to reorganize sources in next release, as the current number of source
-- files is a little large.
* Tue Sep 07 1999 Cristian Gafton <gafton@redhat.com>
- upgraded pgaccess to the latest 0.98 stable version
- fix braindead pgaccess installation and add pgaccess dosucmenattaion to
the package containing pgaccess rather than main package
- add missing templates tp the /usr/lib/pgsql directory
- added back the PostgreSQL howto (I wish people will STOP removing
documentation from this package!)
- get rid of the perl handling overkill (what the hell was that needed for?)
- "chkconfig --del" should be done in the server package, not the main
package
- make server packeg own only /etc/rc.d/init.d/postgresql, not the whole
/etc/rc.d (doh!)
- don't ship OS2 executable client as documenatation...
- if we have a -tcl subpackage, make sure that other packages don't need tcl
anymore by moving tcl-dependent binaries in the -tcl package... [pltcl.so]
- if we are using /sbin/chkconfig we don't need the /etc/rc.d/rc?.d symlinks
* Sat Sep 4 1999 Jeff Johnson <jbj@redhat.com>
- use _arch not (unknown!) buildarch macro (#4913).
* Fri Aug 20 1999 Jeff Johnson <jbj@redhat.com>
- obsolete postgres-clients (not conflicts).
* Thu Aug 19 1999 Jeff Johnson <jbj@redhat.com>
- add to Red Hat 6.1.
* Wed Aug 11 1999 Lamar Owen <lamar.owen@wgcr.org>
- Release 3lo
- Picked up pgaccess README.
- Built patch set for rpm versus tarball idiosyncrasies:
-- munged some paths in the regression tests (_OBJWD_), trigger functions
-- munged USER for regression tests.
-- Added perl and python examples -- required patching the shebang to drop
-- local in /usr/local/bin
- Changed rc.d level from S99 to S75, as there are a few server daemons that
-- might actually need to load AFTER pgsql -- AOLserver is an example.
- config.guess included in server package by default -- used by regress tests.
- Preliminary test subpackage, containing entire src/test tree.
- Prebuild of binaries in the test subpackage.
- Added pgaccess-0.97 beta as /usr/bin/pgaccess97 for testing
- Removed the DATABASE-HOWTO; it was SO old, and the newer release of it
-- is a stock part of the RedHat HOWTOS package.
- Put in the RIGHT postgresql.init ('/etc/rc.d/init.d/postgresql')
- Noted that the perl client is operational.
* Fri Aug 6 1999 Lamar Owen <lamar.owen@wgcr.org>
- Release 2lo
- Added alpha patches courtesy Ryan Kirkpatrick and Uncle George
- Renamed lamar owen series of RPMS with release of #lo
- Put Ramifordistat as vendor and URL for lamar owen RPM series, until non-beta
-- release coordinated with PGDG.
* Mon Jul 19 1999 Lamar Owen <lamar.owen@wgcr.org>
- Correct some file misappropriations:
-- /usr/lib/pgsql was in wrong package
-- createlang, destroylang, and vacuumdb now in main package
-- ipcclean now in server subpackage
-- The static libraries are now in the devel subpackage
-- /usr/lib/plpgsql.so and /usr/lib/pltcl.so now in server
- Cleaned up some historical artifacts for readability -- left references
- to these artifacts in the changelog
* Sat Jun 19 1999 Thomas Lockhart <lockhart@alumni.caltech.edu>
- deprecate clients rpm, and define a server rpm for the backend
- version 6.5
- updated pgaccess to version 0.96
- build ODBC interface library
- split tcl and ODBC packages into separate binary rpms
* Sat Apr 17 1999 Jeff Johnson <jbj@redhat.com>
- exclude alpha for Red Hat 6.0.
* Sun Mar 21 1999 Cristian Gafton <gafton@redhat.com>
- auto rebuild in the new build environment (release 2)
* Wed Feb 03 1999 Cristian Gafton <gafton@redhat.com>
- version 6.4.2
- get rid of the -data package (shipping it was a BAD idea)
* Sat Oct 10 1998 Cristian Gafton <gafton@redhat.com>
- strip all binaries
- use defattr in all packages
- updated pgaccess to version 0.90
- /var/lib/pgsql/pg_pwd should not be 666
* Sun Jun 21 1998 Jeff Johnson <jbj@redhat.com>
- create /usr/lib/pgsql (like /usr/include/pgsql)
- resurrect libpq++.so*
- fix name problem in startup-script (problem #533)
* Fri Jun 19 1998 Jeff Johnson <jbj@redhat.com>
- configure had "--prefix=$RPM_BUILD_ROOT/usr"
- move all include files below /usr/include/pgsql.
- resurrect perl client file lists.
* Tue May 05 1998 Prospector System <bugs@redhat.com>
- translations modified for de, fr, tr
* Tue May 05 1998 Cristian Gafton <gafton@redhat.com>
- build on alpha
* Sat May 02 1998 Cristian Gafton <gafton@redhat.com>
- enhanced initscript
* Tue Apr 21 1998 Cristian Gafton <gafton@redhat.com>
- finally v6.3.2 is here !
* Wed Apr 15 1998 Cristian Gafton <gafton@redhat.com>
- added the include files in the devel package
* Wed Apr 01 1998 Cristian Gafton <gafton@redhat.com>
- finally managed to get a patch for 6.3.1 to make it install corectly. Boy,
what a mess ! ;-(
* Tue Mar 03 1998 Cristian Gafton <gafton@redhat.com>
- upgraded tp 6.3 release
* Sat Feb 28 1998 Cristian Gafton <gafton@redhat.com>
- upgraded to the latest snapshot
- splitted yet one more subpackage: clients
* Tue Jan 20 1998 Cristian Gafton <gafton@redhat.com>
- the installed devel-library is no longer stripped (duh!)
- added the 7 patches found on the ftp.postgresql.org site
- corrected the -rh patch to patch configure.in rather than configure; we
now use autoconf
- added a patch to fix the broken psort function
- build TCL and C++ libraries as well
- updated pgaccess to version 0.76
* Thu Oct 23 1997 Cristian Gafton <gafton@redhat.com>
- cleaned up the spec file for version 6.2.1
- splited devel subpackage
- added chkconfig support in %preun and %post
- added optional data package
* Mon Oct 13 1997 Elliot Lee <sopwith@cuc.edu> 6.2-3
- Fixed lots of bung-ups in the spec file, made it FSSTND compliant, etc.
- Removed jdbc package, jdk isn't stable yet as far as what goes where.
- Updated to v 6.2.1
* Thu Oct 9 1997 10:58:14 dan
- on pre-installation script now the `data' dir is renamed to
`data.rpmorig' (no more wild deletions!).
- added `postgresql-jdbc' sub-package.
- postgresql.sh script: defined function `add_to_path()' and
changed the location of postgresql.jar in the CLASSPATH.
* Sat Oct 4 1997 10:27:43 dan
- updated to version 6.2.
- added auto installation's scripts (pre, post, preun, postun)
From bouncefilter Sat Sep 18 23:03:30 1999
Received: from db.geocrawler.com (db.gotocity.com [165.90.140.10])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA65008
for <pgsql-hackers@hub.org>; Sat, 18 Sep 1999 23:02:46 -0400 (EDT)
(envelope-from nobody@db.geocrawler.com)
Received: (from nobody@localhost)
by db.geocrawler.com (8.8.8/8.8.8) id WAA31085;
Sat, 18 Sep 1999 22:04:14 -0500
Date: Sat, 18 Sep 1999 22:04:14 -0500
Message-Id: <199909190304.WAA31085@db.geocrawler.com>
To: pgsql-hackers@hub.org
Subject: money;money;money
From: "Geocrawler.com" <archiver@db.geocrawler.com>
Reply-To: "Kent Diskey" <diskey@nwark.net>
This message was sent from Geocrawler.com by "Kent Diskey" <diskey@nwark.net>
Be sure to reply to that address.
READING THIS COULD CHANGE YOUR LIFE!
I found this
on a bulletin board and decided to try it. A
little
while back, I
was browsing through newsgroups and came across
an article similar to this that said you could make
thousands of dollars
within weeks with only an initial investment of
$6.00! So I
thought, "Yeah right, this must be a scam", but
like most of
us, I was curious, so I kept reading. Anyway, it
said
that you send
$1.00 to each of the 6 names and addresses stated
in the
article. You then
place your name and address in the bottom of
the list at
#6, and post the article in at least 200 newsgroups.
(There are thousands)
No catch, that was it. So after thinking it
over, and talking
to a few people first, I thought about trying it.
I
figured: "what have
I got to lose except 6 stamps and $6.00,
right?" Then I
invested the measly $6.00. Well GUESS WHAT!!...
within 7 days,
I started getting money in the mail! I was shocked?
I
figured it would
end soon, but the money just kept coming in. In
my
first week, I
made about $25.00. By the end of the second week
I
had
made a total
of over $1,000.00! In the third week I had over
$10,000.00 and it's
still growing. This is now my fourth week and I
have made a
total of just over $42,000.00 and it's still coming in
rapidly. It's certainly
worth $6.00, and 6 stamps, I have spent
more
than that on
the lottery!! Let me tell you how this works and
most
importantly, why it
works... Also, make sure you print a copy of
this
article NOW, so
you can get the information off of it as you
need
it.
I promise you
that if you follow the directions exactly, that you
will start making
more money that you thought possible by doing
something so easy!
Suggestion: Read this
entire message carefully! (print it out or
download it.) Follow
the simple directions and watch the money
come in!
It's easy. It's
legal. And, your investment is only $6.00 (plus
postage).
IMPORTANT: This is
not a rip-off; it is not indecent; it is not
illegal; and it
is virtually no risk - it really works!!!
If all of
the following instructions are adhered to, you will receive
extraordinary dividends.
PLEASE NOTE:
Please follow these
directions EXACTLY, and $50,000 or more can
be
yours in 20
to 60 days. This program remains successful because
of
the honesty and
integrity of the participants. Please continue its
success by carefully adhering to the instructions.
You will now
become part of the Mail Order business. In this
business
your product is
not solid and tangible, it's a service. You are in
the business of
developing Mailing Lists. Many large corporations
are
happy to pay
big bucks for quality lists. However, the money made
from the mailing
lists is secondary to the income which is made
from
people like you
and me asking to be included in that list.
Here are the 4 easy steps to success:
STEP 1: Get
6 separate pieces of paper and write the following on
each piece of
paper "PLEASE PUT ME ON YOUR MAILING LIST."
Now
get 6 US
$1.00 bills and place ONE inside EACH of the 6
pieces of
paper so the
bill will not be seen through the envelope (to prevent
thievery). Next, place
one paper in each of the 6 envelopes and
seal
them. You should
now have 6 sealed envelopes, each with a piece
of
paper stating the
above phrase, your name and address, and a
$1.00
bill. What you
are doing is creating a service. This is absolutely
legal? You are
requesting a legitimate service and you are paying
for
it! Like most
of us I was a little skeptical and a little
worried
about the legal
aspects of it all. So I checked it out with
the U.S.
Post Office (1-800-725-2161)
and they confirmed that it is indeed
legal! Mail the
6 envelopes to the following addresses:
1.) Bill Lijewski
807 Keast
Hutchinson, KS 67501, USA
2.) Rodney Fadler
P.O. Box 244
Herculaneum, MO 63048, USA
3.) Kent Diskey
2114 North tull ave apt#4
Fayetteville, Ar 72704 usa
4.) Robert Sham
1039 Lamplighter Rd.
Niskayuna, NY 12309, USA
5.) Vlïż½ntoiu Gheorghe Serban
C.P. 72-21
Bucharest, ROMANIA
6.) Justin Amoyen
235 Oakridge Dr.
Daly City, CA 94014, USA
STEP 2: Now
take the #1 name off the list that you see
above,
move
the other names
up (6 becomes 5, 5 becomes 4, etc. ...) and
add
YOUR
name as number 6 on the list.
STEP 3: Change
anything you need to, but try to keep this article
as
close to the
original as possible. Now, post your amended article
to
at least 200
newsgroups. (I think there are close to 24,000
groups.)
All you need
is 200, but remember, the more you post, the more
money you make!
This is perfectly
legal! If you have any doubts, refer to Title 18
Sec. 1302 &
1241 of the Postal lottery laws. Keep a copy of
these
steps
for yourself and,
whenever you need money, you can use it again,
and
again.
PLEASE REMEMBER that
this program remains successful because
of
the honesty and
integrity of the participants and by their
carefully adhering to
the directions. Look at it this way, if
you are of
integrity, the program will continue and the money
that so many
others have received will come your way, too.
NOTE: You may
want to retain every name and address sent to
you,
either on a
computer or hard copy and keep the notes people
send
you. This VERIFIES
that you are truly providing a service. (Also,
it might be
a good idea to wrap the $1 bill in dark
paper to reduce
the risk of mail theft.)
So, as each
post is downloaded and the directions carefully
followed,
six members will
be reimbursed for their participation as a List
Developer with one
dollar each. Your name will move up the list
geometrically so that
when your name reached the #1 position
you
will be receiving
thousands of dollars in CASH!!! What an
opportunity
for only $6.00
($1.00 for each of the first six people listed above).
Send it now,
add your own name to the list and you're in
business!
---DIRECTIONS----FOR HOW TO POST TO
NEWSGROUPS------------------
STEP 1:
You do not
need to re-type letter to your own posting. Simply
put your cursor
at the beginning of this letter and drag your
cursor to the
bottom of this document, and select 'copy' from
the edit menu.
This will copy the entire letter into the
computer's memory.
STEP 2:
Open a blank
'notepad' file and place your cursor at the top of
the blank page.
From the 'edit' menu select 'PASTE'. This will
paste a copy
of the letter into notepad so that you can add
your
name to the
bottom of the list and to change the numbers of
the
list.
STEP 3:
Save your new
notepad file as a '.txt' file. If you want to
do
your postings in
different settings, you'll always have this
file to go back to.
STEP 4:
Use Netscape or
Internet Explorer and try search for various
newsgroups (on-line forums,
message boards, chat sites,
discussions).
STEP 5:
Visit these message
boards and post this article as a new
message
by highlighting the
text of this letter and selecting 'PASTE'
from the edit
menu. Fill in the Subject, this will be the header
that everyone sees
as they scroll through the list of postings
in a particular
group, click the post message button. You're done
with your first
one! Congratulations... That is it! All you
have to do
is jump to different newsgroups and post away, after
you
get the hang
of it, it will take about 30 seconds for each
newsgroup! ** REMEMBER, THE MORE NEWSGROUPS YOU POST
IN, THE MORE
MONEY YOU WILL
MAKE!! BUT YOU HAVE TO POST A MINIMUM OF
200**
That is it!
You will begin receiving money form around the world
within
days! You may eventually want to rent a P.O.
Box due to the large amount
of mail you
will receive. If you wish to stay anonymous, you can
invent
a name to
use, as long as the postman will deliver it.
**JUST MAKE SURE ALL THE ADDRESSES ARE CORRECT.**
Now the WHY part:
Out of 200
postings, say I receive only 5 replies (a very low
example). So then
I made $5.00 with my name at #6 on the
letter.
Now, each of
the 5 persons who just sent me $1.00 make the
MINIMUM 200
postings, each with
my name at #5 and only 5 persons respond to
each of the
original 5, this is an additional $25.00 for me.
Now those 25
each make 200 MININUM posts with my name at #4
and only 5
replies each. This
brings in an additional $125.00. Now, those 125
persons turn around
and post the MINIMUM 200 with my name at
#3
and receive 5
replies each, I will make an additional $625.00.
Ok, now here
is the fun part, each of those 625 people post
a
MINIMUM
200 letters with
my name at #2 and they receive 5 replies each.
That
just made me
$3,125.00!!! Those 3,125 persons will all deliver this
message to 200
newsgroups with my name at #1 and if still 5
persons
per 200 react,
I will receive an additional $15,625.00!! With an
investment of only
$6.00! AMAZING! When your name is no longer
on the list,
you just take the latest posting in the newsgroups,
and send out
another $6.00 to names on the list, putting your
name at
number 6 again.
And start posting again. The thing to remeber
is: do you
realize that thousands of people all over the world are
joining the internet
and reading these articles everyday? JUST
LIKE YOU
are now!! So,
can you afford $6.00 and see if it really works??
I
think so... People
have said, "what if the plan is played out and
no
one sends you
the money? So what! What are the chances of
that
Happening when there
are tons of new honest users and new
honest
people who are
joining the internet and newsgroups everyday and
are willing to
give it a try? Anyway, it is only $6.00 for
a chance
at thousands. Estimates
are at 20,000 to 50,000 new users, every
day, with thousands
of those joining the actual internet.
Remember, play FAIRLY
and HONESTLY and this will really work.
You
wouldn't want someone
to cheat you the same way you may be
cheating!
Geocrawler.com - The Knowledge Archive
From bouncefilter Sat Sep 18 23:39:30 1999
Received: from school.cs.indiana.edu (school.cs.indiana.edu [129.79.252.113])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA70600
for <pgsql-hackers@hub.org>; Sat, 18 Sep 1999 23:38:43 -0400 (EDT)
(envelope-from mirobert@cs.indiana.edu)
Received: from localhost (mirobert@localhost)
by school.cs.indiana.edu (8.9.3/8.9.3/IUCS_2.28) with ESMTP id WAA02128;
Sat, 18 Sep 1999 22:38:40 -0500 (EST)
X-Authentication-Warning: school.cs.indiana.edu: mirobert owned process doing
-bs
Date: Sat, 18 Sep 1999 22:38:40 -0500 (EST)
From: "J. Michael Roberts" <mirobert@cs.indiana.edu>
To: Kent Diskey <diskey@nwark.net>
cc: pgsql-hackers@hub.org, chrisc@cnci.net
Subject: Re: [HACKERS] money;money;money -- spam;spam;spam
In-Reply-To: <199909190304.WAA31085@db.geocrawler.com>
Message-ID: <Pine.GSO.4.10.9909182230180.2030-100000@school.cs.indiana.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id XAA70653
I really don't like people who spam to my mailing lists.
1. Kent Diskey of Northwest Arkansas, you're a fool. Thousands of people
post this crap every day and nobody ever gets rich from it. Do the
arithmetic yourself, do you think there are an infinite number of
people in the world or what? Go to http://ga.to and poke around a
little.
2. Geocrawler.com has already been notified that you abused their service.
3. This note is being copied to Chris at CNCI (which is nwark.net) and I
hope they don't like spam, either.
4. You didn't even copy your name into the right slot on this chain
letter. Did you think by skipping some steps you'd get more money?
Christopher Corke, you might want to look into posting a Terms of Service
on your site somewhere so that we, as well as your customers, can
understand your spam policy. Your name was the first of three on your
contact page, which is why you're getting this. Please do something about
it, OK?
Everybody else, sorry you had to witness this sordid exchange.
By the way, even though my mailer doesn't want to include headers, the
headers do indicate use of Geocrawler's Web interface to post this.
Sheesh, Kent, didn't you notice the text right under the submit button
that said they know who you are and not to abuse their service?
On Sat, 18 Sep 1999, Geocrawler.com wrote:
This message was sent from Geocrawler.com by "Kent Diskey" <diskey@nwark.net>
Be sure to reply to that address.READING THIS COULD CHANGE YOUR LIFE!
I found this
on a bulletin board and decided to try it. A
littlewhile back, I
was browsing through newsgroups and came across
an article similar to this that said you could makethousands of dollars
within weeks with only an initial investment of$6.00! So I
thought, "Yeah right, this must be a scam", butlike most of
us, I was curious, so I kept reading. Anyway, it
saidthat you send
$1.00 to each of the 6 names and addresses statedin the
article. You then
place your name and address in the bottom ofthe list at
#6, and post the article in at least 200 newsgroups.(There are thousands)
No catch, that was it. So after thinking itover, and talking
to a few people first, I thought about trying it.
Ifigured: "what have
I got to lose except 6 stamps and $6.00,right?" Then I
invested the measly $6.00. Well GUESS WHAT!!...within 7 days,
I started getting money in the mail! I was shocked?I
figured it would
end soon, but the money just kept coming in. Inmy
first week, I
made about $25.00. By the end of the second week
I
hadmade a total
of over $1,000.00! In the third week I had over$10,000.00 and it's
still growing. This is now my fourth week and Ihave made a
total of just over $42,000.00 and it's still coming inrapidly. It's certainly
worth $6.00, and 6 stamps, I have spent
morethan that on
the lottery!! Let me tell you how this works and
mostimportantly, why it
works... Also, make sure you print a copy of
thisarticle NOW, so
you can get the information off of it as you
need
it.I promise you
that if you follow the directions exactly, that youwill start making
more money that you thought possible by doing
something so easy!Suggestion: Read this
entire message carefully! (print it out ordownload it.) Follow
the simple directions and watch the money
come in!It's easy. It's
legal. And, your investment is only $6.00 (plus
postage).IMPORTANT: This is
not a rip-off; it is not indecent; it is notillegal; and it
is virtually no risk - it really works!!!If all of
the following instructions are adhered to, you will receive
extraordinary dividends.PLEASE NOTE:
Please follow these
directions EXACTLY, and $50,000 or more can
beyours in 20
to 60 days. This program remains successful because
ofthe honesty and
integrity of the participants. Please continue its
success by carefully adhering to the instructions.You will now
become part of the Mail Order business. In this
businessyour product is
not solid and tangible, it's a service. You are inthe business of
developing Mailing Lists. Many large corporations
arehappy to pay
big bucks for quality lists. However, the money madefrom the mailing
lists is secondary to the income which is made
frompeople like you
and me asking to be included in that list.Here are the 4 easy steps to success:
STEP 1: Get
6 separate pieces of paper and write the following oneach piece of
paper "PLEASE PUT ME ON YOUR MAILING LIST."
Nowget 6 US
$1.00 bills and place ONE inside EACH of the 6
pieces ofpaper so the
bill will not be seen through the envelope (to preventthievery). Next, place
one paper in each of the 6 envelopes and
sealthem. You should
now have 6 sealed envelopes, each with a piece
ofpaper stating the
above phrase, your name and address, and a
$1.00bill. What you
are doing is creating a service. This is absolutelylegal? You are
requesting a legitimate service and you are paying
forit! Like most
of us I was a little skeptical and a little
worriedabout the legal
aspects of it all. So I checked it out with
the U.S.Post Office (1-800-725-2161)
and they confirmed that it is indeedlegal! Mail the
6 envelopes to the following addresses:1.) Bill Lijewski
807 Keast
Hutchinson, KS 67501, USA2.) Rodney Fadler
P.O. Box 244
Herculaneum, MO 63048, USA3.) Kent Diskey
2114 North tull ave apt#4
Fayetteville, Ar 72704 usa4.) Robert Sham
1039 Lamplighter Rd.
Niskayuna, NY 12309, USA5.) Vlïż½ntoiu Gheorghe Serban
C.P. 72-21
Bucharest, ROMANIA6.) Justin Amoyen
235 Oakridge Dr.
Daly City, CA 94014, USASTEP 2: Now
take the #1 name off the list that you see
above,
movethe other names
up (6 becomes 5, 5 becomes 4, etc. ...) and
add
YOUR
name as number 6 on the list.STEP 3: Change
anything you need to, but try to keep this articleas
close to the
original as possible. Now, post your amended article
toat least 200
newsgroups. (I think there are close to 24,000
groups.)All you need
is 200, but remember, the more you post, the moremoney you make!
This is perfectly
legal! If you have any doubts, refer to Title 18Sec. 1302 &
1241 of the Postal lottery laws. Keep a copy of
these
stepsfor yourself and,
whenever you need money, you can use it again,
and
again.PLEASE REMEMBER that
this program remains successful because
ofthe honesty and
integrity of the participants and by theircarefully adhering to
the directions. Look at it this way, ifyou are of
integrity, the program will continue and the moneythat so many
others have received will come your way, too.NOTE: You may
want to retain every name and address sent to
you,either on a
computer or hard copy and keep the notes people
sendyou. This VERIFIES
that you are truly providing a service. (Also,it might be
a good idea to wrap the $1 bill in dark
paper to reduce
the risk of mail theft.)So, as each
post is downloaded and the directions carefully
followed,six members will
be reimbursed for their participation as a ListDeveloper with one
dollar each. Your name will move up the listgeometrically so that
when your name reached the #1 position
youwill be receiving
thousands of dollars in CASH!!! What an
opportunityfor only $6.00
($1.00 for each of the first six people listed above).Send it now,
add your own name to the list and you're in
business!---DIRECTIONS----FOR HOW TO POST TO
NEWSGROUPS------------------STEP 1:
You do not
need to re-type letter to your own posting. Simplyput your cursor
at the beginning of this letter and drag yourcursor to the
bottom of this document, and select 'copy' fromthe edit menu.
This will copy the entire letter into the
computer's memory.STEP 2:
Open a blank
'notepad' file and place your cursor at the top ofthe blank page.
From the 'edit' menu select 'PASTE'. This will
paste a copy
of the letter into notepad so that you can add
yourname to the
bottom of the list and to change the numbers of
the
list.STEP 3:
Save your new
notepad file as a '.txt' file. If you want to
doyour postings in
different settings, you'll always have this
file to go back to.STEP 4:
Use Netscape or
Internet Explorer and try search for variousnewsgroups (on-line forums,
message boards, chat sites,
discussions).STEP 5:
Visit these message
boards and post this article as a new
messageby highlighting the
text of this letter and selecting 'PASTE'from the edit
menu. Fill in the Subject, this will be the headerthat everyone sees
as they scroll through the list of postingsin a particular
group, click the post message button. You're donewith your first
one! Congratulations... That is it! All youhave to do
is jump to different newsgroups and post away, after
youget the hang
of it, it will take about 30 seconds for eachnewsgroup! ** REMEMBER, THE MORE NEWSGROUPS YOU POST
IN, THE MOREMONEY YOU WILL
MAKE!! BUT YOU HAVE TO POST A MINIMUM OF
200**That is it!
You will begin receiving money form around the world
within
days! You may eventually want to rent a P.O.
Box due to the large amountof mail you
will receive. If you wish to stay anonymous, you caninvent
a name to
use, as long as the postman will deliver it.**JUST MAKE SURE ALL THE ADDRESSES ARE CORRECT.**
Now the WHY part:
Out of 200
postings, say I receive only 5 replies (a very lowexample). So then
I made $5.00 with my name at #6 on theletter.
Now, each of
the 5 persons who just sent me $1.00 make theMINIMUM 200
postings, each with
my name at #5 and only 5 persons respond toeach of the
original 5, this is an additional $25.00 for me.Now those 25
each make 200 MININUM posts with my name at #4and only 5
replies each. This
brings in an additional $125.00. Now, those 125persons turn around
and post the MINIMUM 200 with my name at
#3and receive 5
replies each, I will make an additional $625.00.Ok, now here
is the fun part, each of those 625 people post
a
MINIMUM200 letters with
my name at #2 and they receive 5 replies each.That
just made me
$3,125.00!!! Those 3,125 persons will all deliver thismessage to 200
newsgroups with my name at #1 and if still 5persons
per 200 react,
I will receive an additional $15,625.00!! With aninvestment of only
$6.00! AMAZING! When your name is no longeron the list,
you just take the latest posting in the newsgroups,and send out
another $6.00 to names on the list, putting your
name atnumber 6 again.
And start posting again. The thing to remeberis: do you
realize that thousands of people all over the world arejoining the internet
and reading these articles everyday? JUST
LIKE YOUare now!! So,
can you afford $6.00 and see if it really works??
Ithink so... People
have said, "what if the plan is played out and
noone sends you
the money? So what! What are the chances of
thatHappening when there
are tons of new honest users and new
honestpeople who are
joining the internet and newsgroups everyday andare willing to
give it a try? Anyway, it is only $6.00 for
a chanceat thousands. Estimates
are at 20,000 to 50,000 new users, everyday, with thousands
of those joining the actual internet.Remember, play FAIRLY
and HONESTLY and this will really work.
Youwouldn't want someone
to cheat you the same way you may be
cheating!Geocrawler.com - The Knowledge Archive
************
From bouncefilter Sun Sep 19 01:30:31 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA86385
for <pgsql-hackers@postgresql.org>;
Sun, 19 Sep 1999 01:29:52 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id CAA64344
for <pgsql-hackers@postgresql.org>;
Sun, 19 Sep 1999 02:29:57 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 19 Sep 1999 02:29:57 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: [6.5.2] join problems ...
Message-ID: <Pine.BSF.4.10.9909190203390.27097-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Morning...
This weekend, up at a clients site working with them on improving
database performance. They are currently running MySQL and I'm trying to
convince them to switch over to PostgreSQL, for various features that they
just don't have with MySQL...
One of the 'queries' that they are currently doing with MySQL
consists of two queries that I can reduce down to one using subqueries,
but its so slow that its ridiculous...so I figured I'd throw it out as a
problem to hopefully solve?
The query I'm starting out with is works out as:
SELECT id, name, url \
FROM aecCategory \
WHERE ppid='$indid' \
AND pid='$divid'";
The results of this get fed into a while look that takes the id
returned and pushes them into:
SELECT distinct b.indid, b.divid, b.catid, a.id, a.mid \
FROM aecEntMain a, aecWebEntry b \
WHERE (a.id=b.id AND a.mid=b.mid) \
AND (a.status like 'active%' and b.status like 'active%')
AND (a.status like '%active:ALL%' and b.status like '%active:ALL%')
AND (a.representation like '%:ALL%')
AND (b.indid='$indid' and b.divid='$divid' and b.catid='$catid')";
Now, I can/have rewritten this as:
SELECT id, name, url
FROM aecCategory
WHERE ppid='$indid'
AND pid='$divid'
AND id IN (
SELECT distinct c.id
FROM aecEntMain a, aecWebEntry b, aecCategory c
WHERE (a.id=b.id AND a.mid=b.mid and b.catid=c.id)
AND (a.status like 'active%' and b.status like 'active%')
AND (a.status like '%active:ALL%' and b.status like '%active:ALL%')
AND (a.representation like '%:ALL%')
AND (b.indid='$indid' and b.divid='$divid' and b.catid IN (
SELECT id FROM aecCategory WHERE ppid='$indid' AND pid='$divid' )
));";
An explain of the above shows:
Index Scan using aeccategory_primary on aeccategory (cost=8.28 rows=1 width=36)
SubPlan
-> Unique (cost=1283.70 rows=21 width=72)
-> Sort (cost=1283.70 rows=21 width=72)
-> Nested Loop (cost=1283.70 rows=21 width=72)
-> Nested Loop (cost=1280.70 rows=1 width=60)
-> Index Scan using aecwebentry_primary on aecwebentry b
(cost=1278.63 rows=1 width=36)
SubPlan
-> Index Scan using aeccategory_primary on aeccategory
(cost=8.28 rows=1 width=12)
-> Index Scan using aecentmain_primary on aecentmain a
(cost=2.07 rows=348 width=24)
-> Index Scan using aeccategory_id on aeccategory c
(cost=3.00 rows=1170 width=12)
Now, a few things bother me with the above explain output, based on me
hopefully reading this right...
The innermost SubPlan reports an estimated rows returned of 1...the
actual query returns 59 rows...slightly off?
The one that bothers me is the one that reports 1170 rows returned...if you
look at the query, the only thing that would/should use aeccategory_id is the
line that goes "SELECT distinct c.id"...if I run just that section of the
query, it yields a result of 55 rows...way off??
All of my queries are currently on static data, after a vacuum analyze has
been performed...everything is faster if I split things up and do a SELECT
on a per id basis on return values, but, as the list of 'ids' grow, the
number of iterations of the while loop required will slow down the query...
I'm not sure what else to look at towards optimizing the query further,
or is this something that we still are/need to look at in the server itself?
The machine we are working off of right now is an idle Dual-PIII 450Mhz with
512Meg of RAM, very fast SCSI hard drives on a UW controller...and that query
is the only thing running while we test things...so we aren't under-powered :)
ideas?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Sep 19 01:41:31 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA87866
for <hackers@postgreSQL.org>; Sun, 19 Sep 1999 01:40:38 -0400 (EDT)
(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 FAA06714;
Sun, 19 Sep 1999 05:39:55 GMT
Sender: lockhart@hub.org
Message-ID: <37E4772A.46B7E4EE@alumni.caltech.edu>
Date: Sun, 19 Sep 1999 05:39:54 +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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Keith Parks <emkxp01@mtcc.demon.co.uk>, hackers@postgreSQL.org
Subject: Re: [HACKERS] case bug?
References: <24631.937697487@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Fixed --- here is the patch for REL6_5.
Thanks. I'll keep poking at join syntax instead of looking at this...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Sun Sep 19 01:52:32 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA89348
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 01:52:20 -0400 (EDT)
(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 FAA06732;
Sun, 19 Sep 1999 05:51:22 GMT
Sender: lockhart@hub.org
Message-ID: <37E479DA.6FDFA5F4@alumni.caltech.edu>
Date: Sun, 19 Sep 1999 05:51:22 +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: Lamar Owen <lamar.owen@wgcr.org>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <20970.937688441@sss.pgh.pa.us>
<99091817232103.00581@lowen.wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
While we are thinking about this, I wonder if it wouldn't be a good idea
to separate out the executables that aren't really intended to be
executed willy-nilly, and put them in a different directory.
postmaster, postgres, and initdb have no business being in users' PATH
at all, ever.Such as /usr/sbin on a Linux FSSTND-compliant system (such as RedHat). In
fact, I may just do that with the RPM distribution (after consulting with RedHat
on the issue). Thomas?? The same goes for the admin commands' man pages --
they should be in section 8 on the typical Linux box.
Man page sections can be reassigned for the next release. afaik
/usr/sbin tends to contain programs executed by root, which is not
usually the case for Postgres. Is there a precedent for other programs
of this type in that directory?
I suppose such an admin could stick pg_ on the front of the
symlinks anyway. But then the program names don't match the
documentation we supply, which would be confusing.
Underscores in program names suck. To paraphrase Ali, "no opinion,
just fact" ;)
If we are going to rename programs wholesale, let's do it for release
7.0, and if we must have "pg" in front of everything, then do it as,
e.g. "pgcreateuser". We could rename "pg_dump" as "pgdump" at the same
time.
btw, is it only me or do other people refer to this as "pig dump"?
Well, as things stand, the documentation and the rpm distribution don't match
in other areas -- I personally would have absolutely no problem whatsoever in
doing such a renaming -- hey, I can do such inside the RPM, for that matter,
but I don't want to. Of course, I would follow whatever the core group decides
-- that is the standard. I'm just tossing ideas.
The docs don't claim to match the rpm (or any other real system; as
the intro claims it is just used as an example). The docs *do* claim
to know about what program you should run, so those names should never
change unless done in the official distro.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Sun Sep 19 02:11:31 1999
Received: from argh.demon.co.uk (IDENT:grim@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA91820
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 02:11:23 -0400 (EDT)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id HAA24060;
Sun, 19 Sep 1999 07:14:57 +0100
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199909190614.HAA24060@argh.demon.co.uk>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
To: lockhart@alumni.caltech.edu (Thomas Lockhart)
Date: Sun, 19 Sep 1999 07:14:57 +0100 (BST)
Cc: lamar.owen@wgcr.org (Lamar Owen), tgl@sss.pgh.pa.us (Tom Lane),
theo@flame.co.za (Theo Kramer),
pgsql-hackers@postgreSQL.org (pgsql-hackers@postgreSQL.org)
In-Reply-To: <37E479DA.6FDFA5F4@alumni.caltech.edu> from "Thomas Lockhart" at
Sep 19, 1999 05:51:22 AM
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
on the issue). Thomas?? The same goes for the admin commands' man pages --
they should be in section 8 on the typical Linux box.Man page sections can be reassigned for the next release. afaik
/usr/sbin tends to contain programs executed by root, which is not
usually the case for Postgres. Is there a precedent for other programs
of this type in that directory?
IIRC majordomo puts the whole slew of commands in the same directory, usually
/usr/local/bin when you install it. Most of these are not really user commands
btw, is it only me or do other people refer to this as "pig dump"?
I try and steer clear of pig dump in all its forms {;-)
~Michael
From bouncefilter Sun Sep 19 12:31:39 1999
Received: from argh.demon.co.uk (IDENT:root@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA78436
for <pgsql-hackers@postgresql.org>;
Sun, 19 Sep 1999 12:31:26 -0400 (EDT)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id HAA24118
for pgsql-hackers@postgresql.org; Sun, 19 Sep 1999 07:36:08 +0100
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199909190636.HAA24118@argh.demon.co.uk>
Subject: Command Locations (was Re: HISTORY for 6.5....)
To: pgsql-hackers@postgresql.org
Date: Sun, 19 Sep 1999 07:36:08 +0100 (BST)
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
One idea, which takes into account the thought that moving the admin commands
out of /usr/bin is a good thing, but moving them into /usr/sbin is bad, and
we want to keep it simple for new people.
Hows about the commands are stored in ~postgres (or whateber you are using
as an admin account). This is obviously configurable with --admin-dir in the
configure script.
This would probably work as:
a ) new admins that arent familiar with a system will likely have . in the
user paths, thus the commands will work
b ) experienced admins can just choose where to install things
~Michael
From bouncefilter Sun Sep 19 03:17:32 1999
Received: from web119.yahoomail.com (web119.yahoomail.com [205.180.60.120])
by hub.org (8.9.3/8.9.3) with SMTP id DAA02886
for <pgsql-hackers@postgresql.org>;
Sun, 19 Sep 1999 03:17:27 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19990919071724.20897.rocketmail@web119.yahoomail.com>
Received: from [206.246.185.100] by web119.yahoomail.com;
Sun, 19 Sep 1999 00:17:24 PDT
Date: Sun, 19 Sep 1999 00:17:24 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] [6.5.2] join problems ...
To: The Hermit Hacker <scrappy@hub.org>
Cc: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
The query you've presented is rather convoluted, but
if I'm reading your query correctly, it should reduce
to a simple, three-way join:
SELECT c.id, c.name, c.url
FROM aecEntMain a, aecWebEntry b, aecCategory c
WHERE a.status LIKE 'active:ALL%'
AND a.representation LIKE '%:ALL%'
AND b.status LIKE 'active:ALL%'
AND b.indid='$indid'
AND b.divid='$divid'
AND (a.id,a.mid = b.id,b.mid)
AND (b.catid,b.indid,b.divid = c.id,c.ppid,c.pid);
with the following indexes:
aecEntMain: (status) and (id,mid)
aecWebEntry: (status), (indid), (divid), and
(catid,indid,divid)
aecCategory: (id,ppid,pid)
Now, there are some differences between the above and
what you wrote. For example, the above requires that
the status begins with 'active:ALL'. Your query
requires the status begin with 'active' and must also
contain the pattern 'active:ALL'. So for the above
to be equivalent, you can't have a status such as
'active <some stuff> active:ALL'.
With respect to subqueries and PostgreSQL, as you
know, the IN clause requires a nested scan. If you
are going to use subqueries, correlated subqueries
using EXISTS clauses can use indexes:
SELECT c.id, c.name, c.url
FROM aecCategory c
WHERE EXISTS (
SELECT a.status
FROM aecEntMain a, aecWebEntry b
WHERE a.status LIKE 'active:ALL%'
AND a.representation LIKE '%:ALL%'
AND b.status LIKE 'active:ALL%'
AND b.indid='$indid'
AND b.divid='$divid'
AND (a.id,a.mid = b.id,b.mid)
AND (b.catid,b.indid,b.divid = c.id,c.ppid,c.pid));
Unfortunately, the lack of index support in IN
subqueries affects more than just the IN subquery
clause, since INTERSECT/EXCEPT uses the rewriter to
rewrite such queries as UNIONS of two queries with
an IN/NOT IN subquery, respectively. This makes the
INTERSECT/EXCEPT feature functionally useless except
on very small tables.
Hope that helps (and is equivalent),
Mike Mascari (mascarim@yahoo.com)
--- The Hermit Hacker <scrappy@hub.org> wrote:Morning...
This weekend, up at a clients site working with
them on improving
database performance. They are currently running
MySQL and I'm trying to
convince them to switch over to PostgreSQL, for
various features that they
just don't have with MySQL...One of the 'queries' that they are currently doing
with MySQL
consists of two queries that I can reduce down to
one using subqueries,
but its so slow that its ridiculous...so I figured
I'd throw it out as a
problem to hopefully solve?The query I'm starting out with is works out as:
SELECT id, name, url \
FROM aecCategory \
WHERE ppid='$indid' \
AND pid='$divid'";The results of this get fed into a while look that
takes the id
returned and pushes them into:SELECT distinct b.indid, b.divid, b.catid,
a.id, a.mid \
FROM aecEntMain a, aecWebEntry b \
WHERE (a.id=b.id AND a.mid=b.mid) \
AND (a.status like 'active%' and b.status
like 'active%')
AND (a.status like '%active:ALL%' and
b.status like '%active:ALL%')
AND (a.representation like '%:ALL%')
AND (b.indid='$indid' and
b.divid='$divid' and b.catid='$catid')";Now, I can/have rewritten this as:
SELECT id, name, url
FROM aecCategory
WHERE ppid='$indid'
AND pid='$divid'
AND id IN (
SELECT distinct c.id
FROM aecEntMain a, aecWebEntry b, aecCategory c
WHERE (a.id=b.id AND a.mid=b.mid and b.catid=c.id)
AND (a.status like 'active%' and b.status like
'active%')
AND (a.status like '%active:ALL%' and b.status
like '%active:ALL%')
AND (a.representation like '%:ALL%')
AND (b.indid='$indid' and b.divid='$divid' and
b.catid IN (
SELECT id FROM aecCategory WHERE
ppid='$indid' AND pid='$divid' )
));";An explain of the above shows:
Index Scan using aeccategory_primary on aeccategory
(cost=8.28 rows=1 width=36)
SubPlan
-> Unique (cost=1283.70 rows=21 width=72)
-> Sort (cost=1283.70 rows=21 width=72)
-> Nested Loop (cost=1283.70 rows=21
width=72)
-> Nested Loop (cost=1280.70 rows=1
width=60)
-> Index Scan using aecwebentry_primary
on aecwebentry b
(cost=1278.63 rows=1 width=36)
SubPlan
-> Index Scan using
aeccategory_primary on aeccategory
(cost=8.28 rows=1
width=12)
-> Index Scan using aecentmain_primary on
aecentmain a
(cost=2.07 rows=348 width=24)
-> Index Scan using aeccategory_id on
aeccategory c
(cost=3.00 rows=1170 width=12)Now, a few things bother me with the above explain
output, based on me
hopefully reading this right...The innermost SubPlan reports an estimated rows
returned of 1...the
actual query returns 59 rows...slightly off?The one that bothers me is the one that reports
1170 rows returned...if you
look at the query, the only thing that would/should
use aeccategory_id is the
line that goes "SELECT distinct c.id"...if I run
just that section of the
query, it yields a result of 55 rows...way off??All of my queries are currently on static data,
after a vacuum analyze has
been performed...everything is faster if I split
things up and do a SELECT
on a per id basis on return values, but, as the list
of 'ids' grow, the
number of iterations of the while loop required will
slow down the query...I'm not sure what else to look at towards
optimizing the query further,
or is this something that we still are/need to look
at in the server itself?The machine we are working off of right now is an
idle Dual-PIII 450Mhz with
512Meg of RAM, very fast SCSI hard drives on a UW
controller...and that query
is the only thing running while we test things...so
we aren't under-powered :)ideas?
Marc G. Fournier ICQ#7615664
IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary:
scrappy@{freebsd|postgresql}.org
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
From bouncefilter Sun Sep 19 05:43:34 1999
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net
[194.217.242.38]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA18847
for <hackers@postgresql.org>; Sun, 19 Sep 1999 05:43:25 -0400 (EDT)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
id 11SdVE-000FSF-0A; Sun, 19 Sep 1999 09:43:24 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id KAA12537; Sun, 19 Sep 1999 10:43:17 +0100 (BST)
Message-Id: <199909190943.KAA12537@mtcc.demon.co.uk>
Date: Sun, 19 Sep 1999 10:43:17 +0100 (BST)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] case bug?
To: tgl@sss.pgh.pa.us, lockhart@alumni.caltech.edu
Cc: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: cW4+rIUPjosFMfqNQj/Crg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc
Thanks guys, that was swift work.
Keith.
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
Fixed --- here is the patch for REL6_5.
Thanks. I'll keep poking at join syntax instead of looking at this...
- Thomas
From bouncefilter Sun Sep 19 15:17:40 1999
Received: from voicenet.com (mail12.voicenet.com [207.103.0.6])
by hub.org (8.9.3/8.9.3) with SMTP id PAA99694
for <pgsql-ports@postgreSQL.org>; Sun, 19 Sep 1999 15:16:57 -0400 (EDT)
(envelope-from gatgul@voicenet.com)
Received: (qmail 28235 invoked from network); 19 Sep 1999 19:16:52 -0000
Received: from dialpool0544-pri.voicenet.com (HELO voicenet.com)
(209.71.86.44)
by mail12.voicenet.com with SMTP; 19 Sep 1999 19:16:52 -0000
Sender: gat
Message-ID: <37E4BC22.31C8461B@voicenet.com>
Date: Sun, 19 Sep 1999 06:34:10 -0400
From: Uncle George <gatgul@voicenet.com>
Organization: Big-Endian
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: Ryan Kirkpatrick <pgsql@rkirkpat.net>, pgsql-hackers@postgreSQL.org,
pgsql-patches@postgreSQL.org, pgsql-ports@postgreSQL.org,
Lamar Owen <lamar.owen@wgcr.org>
Subject: Re: [PORTS] Linux/Alpha patches for Postgresql 6.5.2
References: <Pine.LNX.4.10.9909181110380.30766-101000@excelsior.rkirkpat.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Not its not. It is the 'cost' of the 'parsed' branch trees that are causing the final
display to be slightly different. If one were to change the size of an 'internal' 'C struct'
to be the same size of an 'i386' 'C struct' then the results are the same ( or at least make
the sizeof() values the same ) then the results would be the same.
as for the differences in the 'off by a small fraction' is due to i386 having 80bit float
operations, and the alpha does 64bit float operations. ( Both under the same ieee mandate to
do the same algorithm)
gat
Ryan Kirkpatrick wrote:
The only regression tests that are failing are the sames ones as
for 6.5.1, geometry (off by one in nth decimal place) and rules (with
no-predefined sorting method, alpha's default sort is different than the
rest).
From bouncefilter Sun Sep 19 09:31:36 1999
Received: from mail.intekom.com (smtp.intekom.com [196.25.69.22])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA52369;
Sun, 19 Sep 1999 09:31:20 -0400 (EDT)
(envelope-from jason@intekom.co.za)
Received: from ndf53-01-p27.gt.saix.net ([196.15.182.27] helo=pug.galaxy.net)
by mail.intekom.com with esmtp (Exim 3.02 #4)
id 11Sh36-00028T-00; Sun, 19 Sep 1999 15:30:37 +0200
Received: from jason ([192.168.1.10])
by pug.galaxy.net (8.9.3/8.9.3) with SMTP id NAA18627;
Sun, 19 Sep 1999 13:18:58 +0200
Message-Id: <199909191118.NAA18627@pug.galaxy.net>
From: "Jason Doller" <jason@intekom.co.za>
To: pgsql-interfaces@postgresql.org, hackers@postgresql.org
Date: Sun, 19 Sep 1999 13:17:49 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: PERL
Reply-to: rjd@intekom.co.za
X-Confirm-Reading-To: rjd@intekom.co.za
X-pmrqc: 1
Priority: normal
In-reply-to: <199909182010.QAA18416@candle.pha.pa.us>
References: <35E0ABF0.578694C8@bellatlantic.net> from David Hartwig at "Aug
23,
1998 07:55:29 pm"
X-mailer: Pegasus Mail for Win32 (v3.11)
Hi All
I'm a bit lost! Where can I find documentation on accessing postgres
from inside PERL (5)?
Any help will be appreciated. (The thing is, I'm sure I've seen the info
somewhere, but for the life of me I can't remember where...)
Thanks
Jason Doller
From bouncefilter Sun Sep 19 09:03:36 1999
Received: from db.geocrawler.com (db.gotocity.com [165.90.140.10])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA49197
for <pgsql-hackers@hub.org>; Sun, 19 Sep 1999 09:03:27 -0400 (EDT)
(envelope-from nobody@db.geocrawler.com)
Received: (from nobody@localhost)
by db.geocrawler.com (8.8.8/8.8.8) id IAA21956;
Sun, 19 Sep 1999 08:04:53 -0500
Date: Sun, 19 Sep 1999 08:04:53 -0500
Message-Id: <199909191304.IAA21956@db.geocrawler.com>
To: pgsql-hackers@hub.org
Subject: Spam
From: "Geocrawler.com" <archiver@db.geocrawler.com>
Reply-To: "Tim Perdue" <tim@perdue.net>
This message was sent from Geocrawler.com by "Tim Perdue" <tim@perdue.net>
Be sure to reply to that address.
Sorry about the spam that came from my site, Geocrawler. I have revoked the user's rights.
Here is the info that Kent registered with, if anyone wishes to take this further with his ISP:
Kent Diskey
diskey@nwark.net
208.136.254.134
springdale-058.nwark.net
19990918215911pm
I hate spammers and go to great lengths to protect email addresses and mail lists from it, but nothing is foolproof when you are dealing with "these types of people".
Tim Perdue
tim@geocrawler.com
Geocrawler.com - The Knowledge Archive
From bouncefilter Sun Sep 19 09:49:36 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA54440
for <pgsql-hackers@postgresql.org>;
Sun, 19 Sep 1999 09:48:58 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id KAA66349;
Sun, 19 Sep 1999 10:49:10 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 19 Sep 1999 10:49:10 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Mike Mascari <mascarim@yahoo.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [6.5.2] join problems ...
In-Reply-To: <19990919071724.20897.rocketmail@web119.yahoomail.com>
Message-ID: <Pine.BSF.4.10.9909191046050.27097-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 19 Sep 1999, Mike Mascari wrote:
SELECT c.id, c.name, c.url
FROM aecEntMain a, aecWebEntry b, aecCategory c
WHERE a.status LIKE 'active:ALL%'
AND a.representation LIKE '%:ALL%'
AND b.status LIKE 'active:ALL%'
AND b.indid='$indid'
AND b.divid='$divid'
AND (a.id,a.mid = b.id,b.mid)
AND (b.catid,b.indid,b.divid = c.id,c.ppid,c.pid);
Only point I'd like to make (thanks for all the details, gives me alot to
work with...) is that the above is not valid in PostgreSQL, it seems...I
changed the last two AND lines to be:
AND (a.id=b.id AND a.mid=b.mid)
AND (b.catid=c.id AND b.indid=c.ppid AND b.divid=c.pid)
and it eliminiated the error, but gave me zero results...
Please note, in my own defence...I'm working on cleaning up a mess created
by someone else using MySQL...what has to be done is a cleanup of the
tables themselves, but trying to fix some of the SQL first appears to be
the "route of least resistance" :( Or, at least, it appeared to
be...starting to change my mind on that one heavily :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Sep 19 10:40:37 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA60959
for <pgsql-hackers@postgresql.org>;
Sun, 19 Sep 1999 10:39:55 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id LAA66549
for <pgsql-hackers@postgresql.org>;
Sun, 19 Sep 1999 11:39:56 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 19 Sep 1999 11:39:56 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: All things equal, we are still alot slower then MySQL?
Message-ID: <Pine.BSF.4.10.9909191114330.27097-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Using the exact same data, and the exact same queries (dbi is cool):
MySQL: 0.498u 0.150s 0:02.50 25.6% 10+1652k 0+0io 0pf+0w
PgSQL: 0.494u 0.061s 0:19.78 2.7% 10+1532k 0+0io 0pf+0w
The main query that appears to be "dog slow" is:
SELECT distinct b.indid, b.divid, b.catid, a.id, a.mid \
FROM aecEntMain a, aecWebEntry b \
WHERE (a.id=b.id AND a.mid=b.mid) \
AND (a.status like 'active%' and b.status like 'active%')
AND (a.status like '%active:ALL%' and b.status like '%active:ALL%')
AND (a.representation like '%:ALL%')
AND (b.indid=? and b.divid=? and b.catid=?)";
Where, unfortunately, getting rid of those LIKE comparisons will be next to
impossible in the short time...
From the 'time' numbers, MySQL is running ~17sec faster, but uses up 23%
more CPU to do this...so where is our slowdown? Obviously it isn't a lack
of CPU...all else is equal...hardware wise, both are running on the same
machine.
If I get rid of the three lines above that deal with LIKE, the results
are:
MySQL: 0.497u 0.168s 0:01.48 43.9% 9+1519k 0+0io 0pf+0w
PgSQL: 0.504u 0.052s 0:17.81 3.0% 10+1608k 0+0io 0pf+0w
So, blaming things on the LIKE conditions is totally inappropriate...
And looking at the EXPLAIN of the above, I have enough indices:
NOTICE: QUERY PLAN:
Unique (cost=1271.15 rows=5 width=84)
-> Sort (cost=1271.15 rows=5 width=84)
-> Nested Loop (cost=1271.15 rows=5 width=84)
-> Index Scan using aecwebentry_primary on aecwebentry b (cost=1269.08 rows=1 width=60)
-> Index Scan using aecentmain_primary on aecentmain a (cost=2.07 rows=16560 width=24)
EXPLAIN
I'm starting the server as:
#!/bin/tcsh
setenv POSTMASTER /usr/local/db/pgsql/bin/postmaster
rm /tmp/.s.P*
${POSTMASTER} -o "-F -o /usr/local/db/pgsql/errout -S 32768" \
-i -p 5432 -D/usr/local/db/pgsql/data -B 256 &
So I think I'm dedicating *more* then enough resources to the server, no?
Again, this data is static...hasn't changed for either database since we
loaded it yesterday...a vacuum analyze has been done on the PostgreSQL
database, but we haven't done anything with the MySQL one (no vacuum, no
special run parameters)
I'm going to be working with this company towards cleaning up the table
structures over the next little while, with an eye towards moving it to
PostgreSQL, but, all things considered equal except for the DB software
itself...how is it that we are *so* much slower?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Sep 19 10:57:37 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA63422
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 10:56:43 -0400 (EDT)
(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 OAA07293;
Sun, 19 Sep 1999 14:54:47 GMT
Sender: lockhart@hub.org
Message-ID: <37E4F937.D2345321@alumni.caltech.edu>
Date: Sun, 19 Sep 1999 14:54:47 +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: The Hermit Hacker <scrappy@hub.org>
CC: Mike Mascari <mascarim@yahoo.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [6.5.2] join problems ...
References: <Pine.BSF.4.10.9909191046050.27097-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
<snip>
AND (a.id,a.mid = b.id,b.mid)
AND (b.catid,b.indid,b.divid = c.id,c.ppid,c.pid);... the above is not valid in PostgreSQL, it seems...
I have to resort to looking at gram.y for this, since I currently have
the Postgres parser in bits and pieces all over the garage floor ;)
The expressions are *almost* valid for Postgres. The difference is
that you need to put parens around each side of the "row expression":
| '(' row_descriptor ')' row_op '(' row_descriptor ')'
{
$$ = makeRowExpr($4, $2, $6);
}
;
I had implemented this using Date and Darwen as a reference, and afaik
the SQL standard (and any sensible parser) *requires* parens around
the row expression, referred to in gram.y as a "row descriptor".
So, the following should work:
AND ((a.id,a.mid) = (b.id,b.mid))
AND ((b.catid,b.indid,b.divid) = (c.id,c.ppid,c.pid));
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Sun Sep 19 10:57:48 1999
Received: from access1.lan2wan.com (root@access1.lan2wan.com [205.177.8.10])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA63463;
Sun, 19 Sep 1999 10:57:00 -0400 (EDT)
(envelope-from bmccoy@lan2wan.com)
Received: from dragosani.lan2wan.com (pm1-13.lan2wan.com [205.177.8.53]) by
access1.lan2wan.com (8.8.5/) with ESMTP id LAA08543;
Sun, 19 Sep 1999 11:16:12 -0400 (EDT)
Received: from localhost (bmccoy@localhost)
by dragosani.lan2wan.com (8.8.7/8.8.7) with ESMTP id KAA01041;
Sun, 19 Sep 1999 10:57:43 -0400
X-Authentication-Warning: dragosani.lan2wan.com: bmccoy owned process doing
-bs
Date: Sun, 19 Sep 1999 10:57:40 -0400 (EDT)
From: "Brett W. McCoy" <bmccoy@lan2wan.com>
To: rjd@intekom.co.za
cc: pgsql-interfaces@postgresql.org, hackers@postgresql.org
Subject: Re: [INTERFACES] PERL
In-Reply-To: <199909191118.NAA18627@pug.galaxy.net>
Message-ID: <Pine.LNX.4.04.9909191054490.890-100000@dragosani.lan2wan.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 19 Sep 1999, Jason Doller wrote:
I'm a bit lost! Where can I find documentation on accessing postgres
from inside PERL (5)?Any help will be appreciated. (The thing is, I'm sure I've seen the info
somewhere, but for the life of me I can't remember where...)
Under the source tree, go to the interfaces directory, and there is a
directory for the perl interface (Pg.pm). You have to enable the Perl
option when you run configure, and you will also have to install the
module as root, since it gets installed under the module hierarchy
wherever you have Perl installed. Then you only need to do a 'perldoc Pg'
to see the documentation on it. See the build instructions for more
information on the how to install the Perl module.
Brett W. McCoy
http://www.lan2wan.com/~bmccoy/
-----------------------------------------------------------------------
Don't let your mind wander -- it's too little to be let out alone.
From bouncefilter Sun Sep 19 11:08:37 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA65378
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 11:08:14 -0400 (EDT)
(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 PAA07338;
Sun, 19 Sep 1999 15:07:42 GMT
Sender: lockhart@hub.org
Message-ID: <37E4FC3E.29CA62E8@alumni.caltech.edu>
Date: Sun, 19 Sep 1999 15:07:42 +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: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
References: <Pine.BSF.4.10.9909191114330.27097-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Using the exact same data, and the exact same queries (dbi is cool):
MySQL: 0.498u 0.150s 0:02.50 25.6% 10+1652k 0+0io 0pf+0w
PgSQL: 0.494u 0.061s 0:19.78 2.7% 10+1532k 0+0io 0pf+0wFrom the 'time' numbers, MySQL is running ~17sec faster, but uses up 23%
more CPU to do this...so where is our slowdown?
I don't remember if you gave details on the sizes of tables, but in
any case I'm going to guess that you are spending almost all of your
time in the optimizer. Try manipulating the parameters to force the
genetic optimizer and see if it helps. Lots of quals but only two
tables gives you a non-optimal case for the default exhaustive
optimizer.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Sun Sep 19 11:25:38 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA68224
for <hackers@postgresql.org>; Sun, 19 Sep 1999 11:24:56 -0400 (EDT)
(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 PAA07608;
Sun, 19 Sep 1999 15:24:23 GMT
Sender: lockhart@hub.org
Message-ID: <37E50026.EE334BD7@alumni.caltech.edu>
Date: Sun, 19 Sep 1999 15:24:22 +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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: INSERT/DEFAULT VALUES broken?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom, can you check to see if
insert into <tablename> default values;
works on an unmodified current tree? I've got things ripped apart, but
I would have expected this to work, and am suspecting that it is a
problem introduced in your rewrite of this area a month or two ago.
(On a table without explicit default values, it should fill with
NULLs, but on my system I get an Assert failure because the target
list is never filled in.)
As usual, there is no coverage of this in the regression tests, so
there is no reason we should have caught this earlier... :(
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Sun Sep 19 11:30:38 1999
Received: from aurora-borealis.satimex.tvnet.hu
(mail@aurora-borealis.satimex.tvnet.hu [195.38.97.151])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA69187
for <pgsql-general@postgresql.org>;
Sun, 19 Sep 1999 11:30:06 -0400 (EDT) (envelope-from infrared@a-b.hu)
Received: from localhost by mail.a-b.hu id 11Siub-0002O5-00;
Sun, 19 Sep 1999 17:29:57 +0200
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-UIDL: 0f5d51cd4b070000
Received: by aurora-borealis (mbox infrared) (with Cubic Circle's cucipop
(v1.31 1998/05/13) Sun Sep 19 17:27:32 1999)
X-From_: infrared@a-b.hu Sun Sep 19 17:27:10 1999
Received: from localhost by mail.a-b.hu id 11Sirr-0002NP-00;
Sun, 19 Sep 1999 17:27:07 +0200
Message-ID: <37E500CA.3FF5DB37@a-b.hu>
Date: Sun, 19 Sep 1999 17:29:57 +0200 (CEST)
Organization: aurora-borealis
X-Mailer: XFMail 1.3.1 [p0] on Linux
X-Accept-Language: en
Sender: infrared@a-b.hu
From: InfraRED <infrared@a-b.hu>
To: pgsql-general@postgresql.org
Subject: when are indexes used?
I noticed that indexes are not used sometimes when they could speed up
queries:
explain select * from auth where uid=30;
Index Scan using auth_uid_key on auth (cost=2.05 rows=1 width=40)
explain select * from auth where uid<30;
Seq Scan on auth (cost=2.06 rows=11 width=40)
explain select * from auth order by uid;
Sort (cost=2.06 rows=32 width=40)
-> Seq Scan on auth (cost=2.06 rows=32 width=40)
are there any ways to speed up queries like these?
the exact usage alg. of indexes is documented somewhere?
when is this going to be fixed?
finally some enhancement ideas:
persistent views: like select into, but the view gets updated every time
the table(s) it was created from change. (gives no further functionality
over views, but when used wisely, can speed up things)
pertable fsync behaviour
inmemory tables: table data should not be saved to disk (maybe except
for swapping), because contains rapidly changing data, which would
expire before restarting the backend
ps: sorry for my bad english
--
InfraRED of aurora-borealis/Veres Tibor
E-Mail: infrared@a-b.hu
From bouncefilter Sun Sep 19 11:48:38 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA72090
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 11:48:07 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA66815;
Sun, 19 Sep 1999 12:48:06 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 19 Sep 1999 12:48:06 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
In-Reply-To: <37E4FC3E.29CA62E8@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.10.9909191223320.27097-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 19 Sep 1999, Thomas Lockhart wrote:
Using the exact same data, and the exact same queries (dbi is cool):
MySQL: 0.498u 0.150s 0:02.50 25.6% 10+1652k 0+0io 0pf+0w
PgSQL: 0.494u 0.061s 0:19.78 2.7% 10+1532k 0+0io 0pf+0wFrom the 'time' numbers, MySQL is running ~17sec faster, but uses up 23%
more CPU to do this...so where is our slowdown?
I don't remember if you gave details on the sizes of tables, but in
any case I'm going to guess that you are spending almost all of your
time in the optimizer. Try manipulating the parameters to force the
genetic optimizer and see if it helps. Lots of quals but only two
tables gives you a non-optimal case for the default exhaustive
optimizer.
With default GEQO == 11 relations:
0.506u 0.045s 0:19.51 2.7% 10+1596k 0+0io 0pf+0w
With GEQO == 2 relations:
0.522u 0.032s 0:19.47 2.8% 9+1385k 0+0io 0pf+0w
If I use that big SUBSELECT that I posted earlier, with GEQO==2:
0.005u 0.020s 0:07.84 0.2% 120+486k 0+0io 0pf+0w
And with GEQO==11:
0.008u 0.016s 0:07.83 0.1% 144+556k 0+0io 0pf+0w
So, going with one large SELECT call with two SUBSELECTs in it cuts off
12secs, but its a web application, and we're still talking 5 seconds
response slower...and alot less CPU being used, which is nice...
But I'm trying to compare apples->apples as much as possible, and MySQL
won't allow us to do that large SUBSELECT call...gives errors, so I'm
guessing its unsupported...
Other ideas, or am I stuck with accepting 7secs? (Realizing that as each
new release comes out, that 7secs tends to have a habit of dropping with
all the optimizations and cleans up we do to the server itself) If so,
then I'm going to have to spend time trying to fix the tables themselves
before delving into switching over to PostgreSQL...which hurts :(
Okay, table sizes for the data are:
aecCategory == 1170
Table = aeccategory
+----------------------------------+----------------------------------+-------+
| Field | Type | Length|
+----------------------------------+----------------------------------+-------+
| ppid | varchar() not null default '' | 6 |
| pid | varchar() not null default '' | 6 |
| id | varchar() not null default '' | 6 |
| name | varchar() not null default '' | 255 |
| description | varchar() | 255 |
| url | varchar() | 255 |
| comidsrc | int4 | 4 |
| datelast | timestamp | 4 |
+----------------------------------+----------------------------------+-------+
Indices: aeccategory_id
aeccategory_primaryaecEntMain == 16560
Table = aecentmain
+----------------------------------+----------------------------------+-------+
| Field | Type | Length|
+----------------------------------+----------------------------------+-------+
| id | varchar() not null default '' | 6 |
| mid | char() not null default '' | 2 |
| name | varchar() not null default '' | 200 |
| description | text | var |
| url | varchar() | 255 |
| street | varchar() | 255 |
| city | varchar() | 255 |
| state | varchar() | 255 |
| postal | varchar() | 255 |
| country | varchar() | 255 |
| servarea | varchar() | 255 |
| business | varchar() | 255 |
| representation | varchar() | 255 |
| status | varchar() | 255 |
| datecreate | varchar() | 14 |
| whocreate | varchar() | 255 |
| datelast | timestamp | 4 |
| wholast | varchar() | 255 |
+----------------------------------+----------------------------------+-------+
Indices: aecentmain_entityname
aecentmain_primaryaecWebEntry == 58316
Table = aecwebentry
+----------------------------------+----------------------------------+-------+
| Field | Type | Length|
+----------------------------------+----------------------------------+-------+
| indid | varchar() not null default '' | 6 |
| divid | varchar() not null default '' | 6 |
| catid | varchar() not null default '' | 6 |
| id | varchar() not null default '' | 6 |
| mid | char() not null default '' | 2 |
| webdetid | int4 | 4 |
| status | varchar() | 255 |
| datecreate | varchar() | 14 |
| whocreate | varchar() | 255 |
| datelast | timestamp | 4 |
| wholast | varchar() | 255 |
+----------------------------------+----------------------------------+-------+
Index: aecwebentry_primaryMarc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Sep 19 11:54:38 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA73281
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 11:54:08 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA27364;
Sun, 19 Sep 1999 11:53:01 -0400 (EDT)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
In-reply-to: Your message of Sun, 19 Sep 1999 11:39:56 -0300 (ADT)
<Pine.BSF.4.10.9909191114330.27097-100000@thelab.hub.org>
Date: Sun, 19 Sep 1999 11:53:01 -0400
Message-ID: <27362.937756381@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
MySQL: 0.498u 0.150s 0:02.50 25.6% 10+1652k 0+0io 0pf+0w
PgSQL: 0.494u 0.061s 0:19.78 2.7% 10+1532k 0+0io 0pf+0w
From the 'time' numbers, MySQL is running ~17sec faster, but uses up 23%
more CPU to do this...so where is our slowdown?
It's gotta be going into I/O, obviously. (I hate profilers that can't
count disk accesses...) My guess is that the index scans are losing
because they wind up touching too many disk pages. You show
NOTICE: QUERY PLAN:
Unique (cost=1271.15 rows=5 width=84)
-> Sort (cost=1271.15 rows=5 width=84)
-> Nested Loop (cost=1271.15 rows=5 width=84)
-> Index Scan using aecwebentry_primary on aecwebentry b (cost=1269.08 rows=1 width=60)
-> Index Scan using aecentmain_primary on aecentmain a (cost=2.07 rows=16560 width=24)EXPLAIN
which means this should be a great plan if the optimizer is guessing
right about the selectivity of the index scans: it's estimating only
one tuple returned from the aecwebentry scan, hence only one iteration
of the nested scan over aecentmain, which it is estimating will yield
only five output tuples to be sorted and uniquified.
I am betting these estimates are off rather badly :-(. The indexscans
are probably hitting way more pages than the optimizer guessed they will.
It may just be that I have optimizer on the brain from having spent too
much time looking at it, but this smells to me like bad-plan-resulting-
from-bad-selectivity-estimation syndrome. Perhaps I can fix it for 6.6
as a part of the optimizer cleanups I am doing. I'd like to get as much
info as I can about the test case.
How many tuples *does* your test query produce, anyway? If you
eliminate all the joining WHERE-clauses and just consider the
restriction clauses for each of the tables, how many tuples?
In other words, what do you get from
SELECT count(*)
FROM aecEntMain a
WHERE (a.id=??? AND a.mid=???)
AND (a.status like 'active%')
AND (a.status like '%active:ALL%')
AND (a.representation like '%:ALL%');
SELECT count(*)
FROM aecWebEntry b
WHERE (b.status like 'active%')
AND (b.status like '%active:ALL%')
AND (b.indid=? and b.divid=? and b.catid=?);
(In the first of these, substitute a representative id/mid pair from
table b for the ???, to simulate what will happen in any one iteration
of the inner scan over table a.) Also, how many rows in each table?
regards, tom lane
From bouncefilter Sun Sep 19 12:00:38 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA74397
for <hackers@postgresql.org>; Sun, 19 Sep 1999 12:00:14 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA27408;
Sun, 19 Sep 1999 11:59:10 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: INSERT/DEFAULT VALUES broken?
In-reply-to: Your message of Sun, 19 Sep 1999 15:24:22 +0000
<37E50026.EE334BD7@alumni.caltech.edu>
Date: Sun, 19 Sep 1999 11:59:10 -0400
Message-ID: <27406.937756750@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Tom, can you check to see if
insert into <tablename> default values;
works on an unmodified current tree? I've got things ripped apart, but
I would have expected this to work, and am suspecting that it is a
problem introduced in your rewrite of this area a month or two ago.
It bombs for me too, so I suspect you are right that I broke it when
I rearranged the analysis of INSERT. It's probably a minor oversight
someplace in there.
Do you want me to fix it in current tree, or would it be wasted work
considering that you are busy doing major parser rearrangements
yourself?
regards, tom lane
From bouncefilter Sun Sep 19 12:04:38 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA74829
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 12:04:34 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA27448;
Sun, 19 Sep 1999 12:03:00 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
In-reply-to: Your message of Sun, 19 Sep 1999 15:07:42 +0000
<37E4FC3E.29CA62E8@alumni.caltech.edu>
Date: Sun, 19 Sep 1999 12:03:00 -0400
Message-ID: <27446.937756980@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Using the exact same data, and the exact same queries (dbi is cool):
MySQL: 0.498u 0.150s 0:02.50 25.6% 10+1652k 0+0io 0pf+0w
PgSQL: 0.494u 0.061s 0:19.78 2.7% 10+1532k 0+0io 0pf+0wFrom the 'time' numbers, MySQL is running ~17sec faster, but uses up 23%
more CPU to do this...so where is our slowdown?
I don't remember if you gave details on the sizes of tables, but in
any case I'm going to guess that you are spending almost all of your
time in the optimizer.
No --- if he were, it'd be all CPU time, not 2.7% CPU usage. The time's
got to be going into disk accesses. I'm perfectly prepared to blame
the optimizer, but I think it's because of a bad plan not too much time
spent making the plan...
regards, tom lane
From bouncefilter Sun Sep 19 12:27:38 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA77662
for <hackers@postgresql.org>; Sun, 19 Sep 1999 12:26:53 -0400 (EDT)
(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 QAA07710;
Sun, 19 Sep 1999 16:26:18 GMT
Sender: lockhart@hub.org
Message-ID: <37E50EAA.29169BED@alumni.caltech.edu>
Date: Sun, 19 Sep 1999 16:26:18 +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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: INSERT/DEFAULT VALUES broken?
References: <27406.937756750@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom, can you check to see if
insert into <tablename> default values;
works on an unmodified current tree? I've got things ripped apart, but
I would have expected this to work, and am suspecting that it is a
problem introduced in your rewrite of this area a month or two ago.It bombs for me too, so I suspect you are right that I broke it when
I rearranged the analysis of INSERT. It's probably a minor oversight
someplace in there.
Do you want me to fix it in current tree, or would it be wasted work
considering that you are busy doing major parser rearrangements
yourself?
If it isn't too much trouble, it would be great if you could look at
it. I'd like to stay focused on the join syntax (for inner joins at
the moment), but need to regression test things like this to make sure
new stuff hasn't introduced breakage...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Sun Sep 19 12:29:39 1999
Received: from excelsior.rkirkpat.net (dhcp-210-85.letu.edu [204.158.210.85])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA77950;
Sun, 19 Sep 1999 12:29:35 -0400 (EDT)
(envelope-from rkirkpat@rkirkpat.net)
Received: from localhost (rkirkpat@localhost)
by excelsior.rkirkpat.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id
LAA01052; Sun, 19 Sep 1999 11:29:14 -0500
Date: Sun, 19 Sep 1999 11:29:14 -0500 (CDT)
From: Ryan Kirkpatrick <pgsql@rkirkpat.net>
X-Sender: rkirkpat@excelsior.rkirkpat.net
To: Adriaan Joubert <a.joubert@albourne.com>
cc: Postgresql <pgsql-hackers@postgreSQL.org>, pgsql-patches@postgreSQL.org
Subject: Re: [PATCHES] Patches for alpha w. cc
In-Reply-To: <37E3C9E5.DAE0BC75@albourne.com>
Message-ID: <Pine.LNX.4.10.9909191127480.30766-100000@excelsior.rkirkpat.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.10.9909191127482.30766@excelsior.rkirkpat.net>
On Sat, 18 Sep 1999, Adriaan Joubert wrote:
Needed the following patches to get it to compile on a DS20. It is an
ev6, so it wasn't recognised and one of the defines in s_lock.h was
wrong.
Is this for Tru64 (or OSF) for Alpha or for Linux/Alpha? I only
have an XLT Alpha running Linux, so there could be issues for pgsql on
Linux/Alpha with the newer 21264 chips, hence the reason I ask. Thanks.
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
From bouncefilter Sun Sep 19 13:24:39 1999
Received: from web112.yahoomail.com (web112.yahoomail.com [205.180.60.82])
by hub.org (8.9.3/8.9.3) with SMTP id NAA84839
for <pgsql-hackers@postgresql.org>;
Sun, 19 Sep 1999 13:23:39 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19990919172146.29199.rocketmail@web112.yahoomail.com>
Received: from [206.246.185.100] by web112.yahoomail.com;
Sun, 19 Sep 1999 10:21:46 PDT
Date: Sun, 19 Sep 1999 10:21:46 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] [6.5.2] join problems ...
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Yes, sorry. Typo. I MEANT to put the parens around
the field list, but...
Mike Mascari
--- Thomas Lockhart <lockhart@alumni.caltech.edu>
wrote:<snip>
AND (a.id,a.mid = b.id,b.mid)
AND (b.catid,b.indid,b.divid =c.id,c.ppid,c.pid);
... the above is not valid in PostgreSQL, it
seems...
I have to resort to looking at gram.y for this,
since I currently have
the Postgres parser in bits and pieces all over the
garage floor ;)The expressions are *almost* valid for Postgres. The
difference is
that you need to put parens around each side of the
"row expression":| '(' row_descriptor ')' row_op '('
row_descriptor ')'
{
$$ = makeRowExpr($4, $2, $6);
}
;I had implemented this using Date and Darwen as a
reference, and afaik
the SQL standard (and any sensible parser)
*requires* parens around
the row expression, referred to in gram.y as a "row
descriptor".So, the following should work:
AND ((a.id,a.mid) = (b.id,b.mid))
AND ((b.catid,b.indid,b.divid) =
(c.id,c.ppid,c.pid));- Thomas
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
From bouncefilter Sun Sep 19 13:26:39 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA85269
for <hackers@postgresql.org>; Sun, 19 Sep 1999 13:26:14 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id NAA27921;
Sun, 19 Sep 1999 13:25:08 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: INSERT/DEFAULT VALUES broken?
In-reply-to: Your message of Sun, 19 Sep 1999 16:26:18 +0000
<37E50EAA.29169BED@alumni.caltech.edu>
Date: Sun, 19 Sep 1999 13:25:07 -0400
Message-ID: <27919.937761907@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
insert into <tablename> default values;
It bombs for me too, so I suspect you are right that I broke it when
I rearranged the analysis of INSERT. It's probably a minor oversight
someplace in there.
Nope, not a parser problem at all; rewriter brain damage. It's been
broken at least since 6.4, but only if you do INSERT ... DEFAULT VALUES
into a table that has no columns with default values, and only if you
have Asserts turned on (so the average user wouldn't see it anyway).
Fix is to dike out incorrect Assert...
regards, tom lane
From bouncefilter Sun Sep 19 13:35:39 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA86624
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 13:35:15 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id NAA27955;
Sun, 19 Sep 1999 13:34:09 -0400 (EDT)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
In-reply-to: Your message of Sun, 19 Sep 1999 12:03:00 -0400
<27446.937756980@sss.pgh.pa.us>
Date: Sun, 19 Sep 1999 13:34:09 -0400
Message-ID: <27953.937762449@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
MySQL: 0.498u 0.150s 0:02.50 25.6% 10+1652k 0+0io 0pf+0w
PgSQL: 0.494u 0.061s 0:19.78 2.7% 10+1532k 0+0io 0pf+0w
No --- if he were, it'd be all CPU time, not 2.7% CPU usage.
Er, wait a second. Are we measuring backend-process runtime here,
or is that the result of 'time' applied to a *client* ?
regards, tom lane
From bouncefilter Sun Sep 19 14:49:40 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA95584
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 14:49:05 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id OAA28183
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 14:48:29 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Anyone understand shared buffer refcount mechanism?
Date: Sun, 19 Sep 1999 14:48:28 -0400
Message-ID: <28180.937766908@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
You may recall I was complaining a while back of "out of free buffers:
time to abort !" errors when running the regression tests with
nonstandard optimizer flags. Those are still there, but still hard to
reproduce. Also, I have been trying to fix ALTER TABLE RENAME so that
it flushes buffers for the target table before renaming the underlying
files (otherwise subsequent mdblindwrt will fail), and have been seeing
that code fail because of buffers being left pinned (refcount > 0) when
the only running backend claims that it does not have them pinned
(PrivateRefCount & LastRefCount are 0). So I am pretty sure that
something is rotten in the buffer refcount accounting.
In trying to understand what the code is doing, I am confused by the
buffer refcount save/restore mechanism. Why does the executor want
to save/restore buffer refcounts? I can sort of see that that might
be a way to clean up buffers that have been pinned and need to be
unpinned, but it seems like it's a kluge around failure to unpin in
the code that did the pinning, if so. If it *is* a way to do that,
shouldn't BufferRefCountRestore unpin the buffer completely if it
restores PrivateRefCount & LastRefCount to 0? I am not sure that this
is where the refcount is getting leaked, but it looks like a possibility.
Also, it bothers me that there is a separation between PrivateRefCount
and LastRefCount. Why not just have PrivateRefCount and let the
save/restore mechanisms save/restore those values, without zeroing out
PrivateRefCount during BufferRefCountReset? The zeroing seems to have
the effect of having BufferValid claim in the inner executor context
that buffers pinned in the outer executor context aren't pinned ---
which is weird at best.
If anyone understands why this mechanism is designed this way,
please tell me about it.
regards, tom lane
From bouncefilter Sun Sep 19 15:41:03 1999
Received: from trends.net (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA02311
for <pgsql-hackers@postgresql.org>;
Sun, 19 Sep 1999 15:40:06 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from www.wgcr.org (root@www.wgcr.org [206.74.232.194])
by trends.net (8.8.8/8.8.8) with ESMTP id PAA10305
for <pgsql-hackers@postgresql.org>;
Sun, 19 Sep 1999 15:39:50 -0400 (EDT)
Received: from lowen.wgcr.org ([207.144.84.176])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id PAA10584;
Sun, 19 Sep 1999 15:33:14 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Michael Simms <grim@argh.demon.co.uk>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Command Locations (was Re: HISTORY for 6.5....)
Date: Sun, 19 Sep 1999 15:17:29 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
References: <199909190636.HAA24118@argh.demon.co.uk>
MIME-Version: 1.0
Message-Id: <99091915330200.00572@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit
On Sun, 19 Sep 1999, Michael Simms wrote:
One idea, which takes into account the thought that moving the admin commands
out of /usr/bin is a good thing, but moving them into /usr/sbin is bad, and
we want to keep it simple for new people.Hows about the commands are stored in ~postgres (or whateber you are using
as an admin account). This is obviously configurable with --admin-dir in the
configure script.
Under RedHat, ~postgres is /var/lib/pgsql, not the _obvious_ /home/postgres.
No, there needs to be a particular place for such commands. And /usr/sbin is
THE FSSTND-mandated place (now called the FHS -- www.pathname.com/fhs). Quoting
FHS 2.0:
---------------------------------------
Filesystem Hierarchy Standard
4.7 /usr/sbin : Non-essential standard system binaries
This directory contains any non-essential binaries used exclusively by the system
administrator. System administration programs that are required for system
repair, system recovery, mounting /usr, or other essential functions should be
placed in /sbin instead.
Typically, /usr/sbin contains networking daemons, any non-essential administration t
ools, and binaries for non-critical server programs. These server programs are used
when entering the System V states known as "run level 2" (multi-user state)
and "run level 3" (networked state) or the BSD state known as "multi-user
mode". At this point the system is making services available to users (e.g.,
printer support) and to other hosts (e.g., NFS exports).
-----------------------
Now, looking into my /usr/sbin, I find two owners -- root, and uucp. That's
right -- most of the uucp stuff that is not executed except during daemon-time
(uucico, uuxqt, and friends) is in /usr/sbin. Making the database service
available in "multi-user" mode is a good job for a binary in /usr/sbin.
Now, this is only if PostgreSQL is being installed in an FHS-compliant manner.
Otherwise, make a /usr/local/pgsql/sbin.
It might be useful to provide an FHS-compliant configure option (hey, it would
make it easier for us packagers ;-)).
a ) new admins that arent familiar with a system will likely have . in the
user paths, thus the commands will work
Whoa. Hold on. Having '.' in PATH is a _major_ security hole. It is almost
never a good idea for '.' to be on the PATH. If you want to go the ~postgres
route, make a bin or sbin dir under ~postgres, and add '~postgres/bin' to PATH
in .profile.
IMHO.
Lamar Owen
WGCR Internet Radio
From bouncefilter Sun Sep 19 15:53:10 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA03090
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 15:52:44 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from lowen.wgcr.org ([207.144.84.176])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id PAA10592;
Sun, 19 Sep 1999 15:47:04 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
Date: Sun, 19 Sep 1999 15:33:21 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
References: <37E479DA.6FDFA5F4@alumni.caltech.edu>
MIME-Version: 1.0
Message-Id: <99091915465201.00572@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit
On Sun, 19 Sep 1999, Thomas Lockhart wrote:
Such as /usr/sbin on a Linux FSSTND-compliant system (such as RedHat). In
fact, I may just do that with the RPM distribution (after consulting with RedHat
on the issue). Thomas?? The same goes for the admin commands' man pages --
they should be in section 8 on the typical Linux box.Man page sections can be reassigned for the next release. afaik
/usr/sbin tends to contain programs executed by root, which is not
usually the case for Postgres. Is there a precedent for other programs
of this type in that directory?
The uucp programs uuxqt and uucico live in /usr/sbin (on RedHat 6). They are
owned by and executed as user uucp. See other message for FHS quote re:
/usr/sbin.
Underscores in program names suck. To paraphrase Ali, "no opinion,
just fact" ;)
I thought VACUUM sucked.... ;-P In all seriousness, I totally agree -- either
replace the _ with -, or drop it altogether.
If we are going to rename programs wholesale, let's do it for release
7.0, and if we must have "pg" in front of everything, then do it as,
e.g. "pgcreateuser". We could rename "pg_dump" as "pgdump" at the same
time.
Sounds good to me.
btw, is it only me or do other people refer to this as "pig dump"?
Worse -- I see '/usr/lib/pgsql' and say "user-lib-pigsqueal."
So, with have a var-lib-pigsqueal, user-lib-pigsqueal, and a
user-local-pigsqueal. Yuck.
The docs don't claim to match the rpm (or any other real system; as
the intro claims it is just used as an example). The docs *do* claim
to know about what program you should run, so those names should never
change unless done in the official distro.
Agreed. Like I said, I'm just tossing some ideas -- if they make it in, Ok, if
not, Ok. As far as I am concerned, it really doesn't matter -- RedHat has
never had a namespace conflict with the PostgreSQL executables residing in
/usr/bin. The only advantage I see is removing certain admin commands from the
standard PATH. Then, for user postgres, add to PATH the admin commands'
residence. Make it part of the .profile for user postgres, give postgres a
different home (under RedHat, ~postgres is currently /var/lib/pgsql), and things
should work fine.
Lamar Owen
WGCR Internet Radio
From bouncefilter Sun Sep 19 20:24:46 1999
Received: from postal.dn.net (postal.dn.net [207.226.170.20])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA44497
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 20:24:32 -0400 (EDT)
(envelope-from frankpit@pop.dn.net)
From: frankpit@pop.dn.net
Received: from pop.dn.net (pm-93.ppp.wdc.dn.net [207.226.188.93])
by postal.dn.net (8.9.3/postal) with ESMTP id UAA21771;
Sun, 19 Sep 1999 20:23:29 -0400 (EDT)
Sender: bernie@postal.dn.net
Message-ID: <37E543E7.9D621F95@pop.dn.net>
Date: Sun, 19 Sep 1999 16:13:28 -0400
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.34 i686)
MIME-Version: 1.0
To: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <37E479DA.6FDFA5F4@alumni.caltech.edu>
<99091915465201.00572@lowen.wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lamar Owen wrote:
btw, is it only me or do other people refer to this as "pig dump"?
Worse -- I see '/usr/lib/pgsql' and say "user-lib-pigsqueal."
The first time my wife, saw the title of this mail-list she pronounced
pgsql `pig squeal', and was rather upset at the thought of
pgsql-hackers.
Bernie Frankpitt
From bouncefilter Sun Sep 19 16:55:03 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA10835
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 16:54:42 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id QAA03329;
Sun, 19 Sep 1999 16:54:28 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909192054.QAA03329@candle.pha.pa.us>
Subject: Re: [HACKERS] Command Locations (was Re: HISTORY for 6.5....)
In-Reply-To: <199909190636.HAA24118@argh.demon.co.uk> from Michael Simms at
"Sep 19, 1999 07:36:08 am"
To: Michael Simms <grim@argh.demon.co.uk>
Date: Sun, 19 Sep 1999 16:54:28 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
One idea, which takes into account the thought that moving the admin commands
out of /usr/bin is a good thing, but moving them into /usr/sbin is bad, and
we want to keep it simple for new people.
I assume this is only an RPM discussion. All third party stuff should
go in /usr/local I think.
Hows about the commands are stored in ~postgres (or whateber you are using
as an admin account). This is obviously configurable with --admin-dir in the
configure script.This would probably work as:
a ) new admins that arent familiar with a system will likely have . in the
user paths, thus the commands will workb ) experienced admins can just choose where to install things
~Michael
************
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sun Sep 19 16:56:42 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA11279
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 16:56:37 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id QAA03340;
Sun, 19 Sep 1999 16:55:38 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909192055.QAA03340@candle.pha.pa.us>
Subject: Re: [HACKERS] [6.5.2] join problems ...
In-Reply-To: <19990919071724.20897.rocketmail@web119.yahoomail.com> from Mike
Mascari at "Sep 19, 1999 00:17:24 am"
To: Mike Mascari <mascarim@yahoo.com>
Date: Sun, 19 Sep 1999 16:55:38 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
With respect to subqueries and PostgreSQL, as you
know, the IN clause requires a nested scan. If you
are going to use subqueries, correlated subqueries
using EXISTS clauses can use indexes:SELECT c.id, c.name, c.url
FROM aecCategory c
WHERE EXISTS (
SELECT a.status
FROM aecEntMain a, aecWebEntry b
WHERE a.status LIKE 'active:ALL%'
AND a.representation LIKE '%:ALL%'
AND b.status LIKE 'active:ALL%'
AND b.indid='$indid'
AND b.divid='$divid'
AND (a.id,a.mid = b.id,b.mid)
AND (b.catid,b.indid,b.divid = c.id,c.ppid,c.pid));Unfortunately, the lack of index support in IN
subqueries affects more than just the IN subquery
clause, since INTERSECT/EXCEPT uses the rewriter to
rewrite such queries as UNIONS of two queries with
an IN/NOT IN subquery, respectively. This makes the
INTERSECT/EXCEPT feature functionally useless except
on very small tables.
Yes, we are aware of that IN limitation, and I keep trying to get it
fixed.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sun Sep 19 17:31:06 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA16392
for <pgsql-hackers@postgresql.org>;
Sun, 19 Sep 1999 17:31:03 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from lowen.wgcr.org ([207.144.84.137])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id RAA10682;
Sun, 19 Sep 1999 17:30:56 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Bruce Momjian <maillist@candle.pha.pa.us>,
Michael Simms <grim@argh.demon.co.uk>
Subject: Re: [HACKERS] Command Locations (was Re: HISTORY for 6.5....)
Date: Sun, 19 Sep 1999 17:17:18 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
Cc: pgsql-hackers@postgresql.org
References: <199909192054.QAA03329@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <99091917303502.00572@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit
On Sun, 19 Sep 1999, Bruce Momjian wrote:
One idea, which takes into account the thought that moving the admin commands
out of /usr/bin is a good thing, but moving them into /usr/sbin is bad, and
we want to keep it simple for new people.I assume this is only an RPM discussion. All third party stuff should
go in /usr/local I think.
You assume partially correctly -- it started out that way. In the meantime,
the general issue of administrative commands versus user commands arose, and
with it, the administrative man page thingy.
I state things the way I do because RedHat is shipping PostgreSQL as a piece of
bona-fide Systems software -- fundamentally part of their distribution. This
changes all the rules -- turns them on end, in reality. While a FHS-compliant
linux distribution that does not ship PostgreSQL would need PostgreSQL in
/usr/local (after all, an OS upgrade could destroy it if it's installed
elsewhere), RedHat needs it in the FHS-mandated locations, because PostgreSQL
is part of RedHat's OS. And, I am attempting to maintain a peice that is
shipping as part of their OS -- which gives me a slightly different point of
view from other PostgreSQL developers/maintainers.
More information about the RedHat-ized PostgreSQL install locations is at:
http://www.ramifordistat.net/postgres/build-it/README.rpm.postgresql-6.5.1
Lamar Owen
WGCR Internet Radio
From bouncefilter Sun Sep 19 20:31:05 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA45491
for <pgsql-hackers@postgresql.org>;
Sun, 19 Sep 1999 20:30:51 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id UAA07772;
Sun, 19 Sep 1999 20:02:35 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909200002.UAA07772@candle.pha.pa.us>
Subject: Re: [HACKERS] Command Locations (was Re: HISTORY for 6.5....)
In-Reply-To: <99091917303502.00572@lowen.wgcr.org> from Lamar Owen at "Sep 19,
1999 05:17:18 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Sun, 19 Sep 1999 20:02:35 -0400 (EDT)
CC: Michael Simms <grim@argh.demon.co.uk>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I state things the way I do because RedHat is shipping PostgreSQL as a piece of
bona-fide Systems software -- fundamentally part of their distribution. This
changes all the rules -- turns them on end, in reality. While a FHS-compliant
linux distribution that does not ship PostgreSQL would need PostgreSQL in
/usr/local (after all, an OS upgrade could destroy it if it's installed
elsewhere), RedHat needs it in the FHS-mandated locations, because PostgreSQL
is part of RedHat's OS. And, I am attempting to maintain a peice that is
shipping as part of their OS -- which gives me a slightly different point of
view from other PostgreSQL developers/maintainers.
Sure, makes sense.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Sun Sep 19 21:25:06 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA54648
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 21:24:50 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id JAA15819;
Mon, 20 Sep 1999 09:24:32 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E58CCF.32C57B87@krs.ru>
Date: Mon, 20 Sep 1999 09:24:31 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Notice: heap_open/close changes committed
References: <20706.937683095@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
2. I made most opens of system relations grab AccessShareLock if
read-only, or RowExclusiveLock if read-write, on the theory that
^^^^^^^^^^^^^^^^
these accesses correspond to an ordinary search or update of a user
relation. This maximizes concurrency of access to the system tables.
There are problems here. In the case of normal UPDATE/DELETE
(when RowExclusiveLock is acquired) Executor takes care about
the-same-row writers, but other parts of system don't check
is tuple read being updated concurrent transaction or not.
This is the old bug (pre-6.5.X released WRITE lock just after
system table was modified). I had no time to fix it and so
just changed old WRITE lock with new AccessExclusiveLock.
But we have to handle this in proper way (wait if t_xmax
is id of an active transaction).
Vadim
From bouncefilter Sun Sep 19 21:29:46 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA55262
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 21:29:15 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id JAA15829;
Mon, 20 Sep 1999 09:25:48 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E58D1B.F7196D10@krs.ru>
Date: Mon, 20 Sep 1999 09:25:47 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Why do we need pg_vlock?
References: <199909182025.QAA18799@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
It seems to me there's no fundamental reason why there couldn't be
two VACUUMs running concurrently in a database. With the locking
we are doing now, it should be safe enough. So, I'd like to propose
that we get rid of the pg_vlock lock file. It doesn't have any useful
purpose but it does force manual intervention by the dbadmin to recover
if a VACUUM crashes :-(Comments? Did I miss something about why we can't have more than one
vacuum process?I vote for removal. Lock files are hacks, usually.
Agreed.
Vadim
From bouncefilter Sun Sep 19 21:58:46 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA59236
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 21:58:12 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id JAA15935;
Mon, 20 Sep 1999 09:56:40 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E59458.64D563D@krs.ru>
Date: Mon, 20 Sep 1999 09:56:40 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Anyone understand shared buffer refcount mechanism?
References: <28180.937766908@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
In trying to understand what the code is doing, I am confused by the
buffer refcount save/restore mechanism. Why does the executor want
to save/restore buffer refcounts? I can sort of see that that might
...
If anyone understands why this mechanism is designed this way,
please tell me about it.
This bothered me for long time too.
The only explanation I see in execMain.c:
/*
* reset buffer refcount. the current refcounts are saved and will be
* restored when ExecutorEnd is called
*
* this makes sure that when ExecutorRun's are called recursively as for
* postquel functions, the buffers pinned by one ExecutorRun will not
* be unpinned by another ExecutorRun.
*/
But buffers pinned by one Executor invocation SHOULDN'T
be unpinned by another one (if there are no bugs in code,
but this is another story).
So, try to remove this save/restore mechanism and let's see...
Vadim
From bouncefilter Sun Sep 19 22:18:46 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA62614
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 22:18:06 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id KAA16147;
Mon, 20 Sep 1999 10:17:18 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E5992E.FDEE6427@krs.ru>
Date: Mon, 20 Sep 1999 10:17:18 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] couldn't rollback cache ?
References: <29176.937576653@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
But as far as I see,neither relation cache nor system catalog cache
aren't be rollbacked correctly.
I added time_qualification_check to SearchSysCache() on trial
(see the patch at the end of this posting).Hmm. This must be a bug of very long standing; surprising it hasn't
been noticed before. I think you are probably right, because a little
glimpsing shows that SearchSysCache() is the *only* place in the whole
system where HeapKeyTest() is called directly --- everyone else goes
through HeapTupleSatisfies() which adds a timequal check of one sort or
another. I don't know the timequal stuff at all, but it seems likely
that we want one here. (Vadim, is this fix right?)
Sorry, but currently I have no ability to deal with anything
but WAL. As for cache/SI issues, I would like to see shared
catalog cache implemented (and remove current SI stuff),
but I was not able to do it for ~ 2 years, -:(
Vadim
From bouncefilter Sun Sep 19 22:44:47 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA65968
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 22:44:26 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id LAA11427; Mon, 20 Sep 1999 11:44:20 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] couldn't rollback cache ?
Date: Mon, 20 Sep 1999 11:47:49 +0900
Message-ID: <000701bf0312$87096de0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <29176.937576653@sss.pgh.pa.us>
Importance: Normal
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, September 17, 1999 10:58 PM
To: Hiroshi Inoue
Cc: pgsql-hackers
Subject: Re: [HACKERS] couldn't rollback cache ?"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
But as far as I see,neither relation cache nor system catalog cache
aren't be rollbacked correctly.
I added time_qualification_check to SearchSysCache() on trial
(see the patch at the end of this posting).Hmm. This must be a bug of very long standing; surprising it hasn't
been noticed before. I think you are probably right, because a little
glimpsing shows that SearchSysCache() is the *only* place in the whole
system where HeapKeyTest() is called directly --- everyone else goes
through HeapTupleSatisfies() which adds a timequal check of one sort or
another. I don't know the timequal stuff at all, but it seems likely
that we want one here. (Vadim, is this fix right?)After this change,
abort;
ABORT
select * from t1;
ERROR: Relation t1 does not have attribute dt1Seems relation cache is not invalidated yet.
I also tried to add time_qualification_check to RelationId(Name)-
CacheGetRelation(). But unfortunately,Relation doesn't have
such a information.I think the real bug here is in inval.c: see
InvalidationMessageCacheInvalidate, which scans pending SI messages
at abort time. If we had committed, we'd have sent an SI message
telling other backends to refresh their relcache entries for t1;
so there is an entry for t1 in the pending-SI-message list. We can
use that entry to tell us to invalidate our own relcache entry instead.
It looks like this is done correctly for tuple SI messages but not for
I think it's not done correctly for tuple SI messages either.
I didn't use current cache invalidation mechanism when I made the
patch for SearchSysCache() because of the following 2 reasons.
1. SI messages are eaten by CommandCounterIncrement(). So they
may vanish before transaction end/aborts.
2. The tuples which should be invalidated in case of abort are different
from ones in case of commit.
In case of commit,deleting old tuples should be invalidated for all
backends.
In case of abort,insert(updat)ing new tuples should be invalidated
for the insert(updat)ing backend.
Currently heap_insert() calls RelationInvalidateHeapTuple() for a
inserting new tuple but heap_replace() doesn't call RelationInvalid-
ateHeapTuple() for a updating new tuple. I don't understand which
is right.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Sun Sep 19 23:08:47 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA69230
for <pgsql-hackers@postgreSQL.org>;
Sun, 19 Sep 1999 23:08:28 -0400 (EDT)
(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 DAA08340;
Mon, 20 Sep 1999 03:04:39 GMT
Sender: lockhart@hub.org
Message-ID: <37E5A446.6D69755A@alumni.caltech.edu>
Date: Mon, 20 Sep 1999 03:04:38 +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: Tom Lane <tgl@sss.pgh.pa.us>
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
References: <27953.937762449@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
MySQL: 0.498u 0.150s 0:02.50 25.6% 10+1652k 0+0io 0pf+0w
PgSQL: 0.494u 0.061s 0:19.78 2.7% 10+1532k 0+0io 0pf+0wNo --- if he were, it'd be all CPU time, not 2.7% CPU usage.
Er, wait a second. Are we measuring backend-process runtime here,
or is that the result of 'time' applied to a *client* ?
Right. That was my point; unless he is firing up the backend using
"time", or running it standalone, it is hard to measure real CPU
time...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Sun Sep 19 23:10:47 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA69671
for <hackers@postgresql.org>; Sun, 19 Sep 1999 23:10:26 -0400 (EDT)
(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 DAA08345;
Mon, 20 Sep 1999 03:06:49 GMT
Sender: lockhart@hub.org
Message-ID: <37E5A4C8.EB9E446@alumni.caltech.edu>
Date: Mon, 20 Sep 1999 03:06:48 +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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: INSERT/DEFAULT VALUES broken?
References: <27919.937761907@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
insert into <tablename> default values;
Nope, not a parser problem at all; rewriter brain damage. It's been
broken at least since 6.4, but only if you do INSERT ... DEFAULT VALUES
into a table that has no columns with default values, and only if you
have Asserts turned on (so the average user wouldn't see it anyway).
Fix is to dike out incorrect Assert...
Sorry about that; I usually don't run with Assert enabled, so wouldn't
have caught it earlier. Thanks for looking into it.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Sun Sep 19 23:35:48 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA73122
for <hackers@postgreSQL.org>; Sun, 19 Sep 1999 23:35:28 -0400 (EDT)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id LAA16617
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 11:35:25 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E5AB7D.F8EA85D4@krs.ru>
Date: Mon, 20 Sep 1999 11:35:25 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: why do shmem attach?
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Exec-on-startup was removed by Bruce long time ago.
Why we still attach to shmem after fork?
Or shmem inheritance is not portable?
Also, all this ShmemIndex stuff seems to be useless
(except of backend PID lookup but it's for sure
should be in separate hash table).
And why separate shmem segment (!!!) is used for
Slocks (ipc.c:CreateAndInitSLockMemory(), etc) - they
use so small amount of memory!
Just wondering...
I'm going to use old shmem init code for WAL but would like
to denote that shmem stuff need in cleanup.
Vadim
From bouncefilter Sun Sep 19 23:48:48 1999
Received: from netrinsics.com (robinson@[202.106.181.154])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA75094
for <pgsql-hackers@hub.org>; Sun, 19 Sep 1999 23:48:38 -0400 (EDT)
(envelope-from robinson@netrinsics.com)
Received: (from robinson@localhost) by netrinsics.com (8.9.3/8.8.7) id
LAA00452
for pgsql-hackers@hub.org; Mon, 20 Sep 1999 11:44:55 +0800 (CST)
(envelope-from robinson)
Date: Mon, 20 Sep 1999 11:44:55 +0800 (CST)
From: Michael Robinson <robinson@netrinsics.com>
Message-Id: <199909200344.LAA00452@netrinsics.com>
To: pgsql-hackers@hub.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
Tom Lane <tgl@sss.pgh.pa.us> writes:
MySQL: 0.498u 0.150s 0:02.50 25.6% 10+1652k 0+0io 0pf+0w
PgSQL: 0.494u 0.061s 0:19.78 2.7% 10+1532k 0+0io 0pf+0wNo --- if he were, it'd be all CPU time, not 2.7% CPU usage.
Er, wait a second. Are we measuring backend-process runtime here,
or is that the result of 'time' applied to a *client* ?
Yeah, that would explain a lot. When I first saw the numbers, I was so
excited because they showed that PostgreSQL is *faster* than MySQL (with
more memory, and better I/O).
That didn't make any sense, though. MySQL is faster than every real DBMS,
because it doesn't have transactions, triggers, locking, or any other sort
of useful features to slow it down.
The question should always be, is PostgreSQL faster than Oracle, Informix,
or Sybase?
-Michael
From bouncefilter Mon Sep 20 00:31:19 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA83293
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 00:30:58 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id AAA06848;
Mon, 20 Sep 1999 00:04:02 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909200404.AAA06848@candle.pha.pa.us>
Subject: Re: [HACKERS] why do shmem attach?
In-Reply-To: <37E5AB7D.F8EA85D4@krs.ru> from Vadim Mikheev at "Sep 20,
1999 11:35:25 am"
To: Vadim Mikheev <vadim@krs.ru>
Date: Mon, 20 Sep 1999 00:04:02 -0400 (EDT)
CC: PostgreSQL Developers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset koi8-r unsupported, filtering to ASCII...]
Exec-on-startup was removed by Bruce long time ago.
Why we still attach to shmem after fork?
No idea. I know the shared memory stuff is not copy-on-write for forked
children, so I am not sure why you would have to attach to it.
Or shmem inheritance is not portable?
If it works on your machine with it removed, commit the change and I can
test it here. I don't know of any portability problems with shared
memory children.
Also, all this ShmemIndex stuff seems to be useless
(except of backend PID lookup but it's for sure
should be in separate hash table).
And why separate shmem segment (!!!) is used for
Slocks (ipc.c:CreateAndInitSLockMemory(), etc) - they
use so small amount of memory!
No idea.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 00:31:29 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA83292
for <pgsql-hackers@hub.org>; Mon, 20 Sep 1999 00:30:57 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id AAA06875;
Mon, 20 Sep 1999 00:06:36 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909200406.AAA06875@candle.pha.pa.us>
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
In-Reply-To: <199909200344.LAA00452@netrinsics.com> from Michael Robinson at
"Sep 20, 1999 11:44:55 am"
To: Michael Robinson <robinson@netrinsics.com>
Date: Mon, 20 Sep 1999 00:06:36 -0400 (EDT)
CC: pgsql-hackers@hub.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tom Lane <tgl@sss.pgh.pa.us> writes:
MySQL: 0.498u 0.150s 0:02.50 25.6% 10+1652k 0+0io 0pf+0w
PgSQL: 0.494u 0.061s 0:19.78 2.7% 10+1532k 0+0io 0pf+0wNo --- if he were, it'd be all CPU time, not 2.7% CPU usage.
Er, wait a second. Are we measuring backend-process runtime here,
or is that the result of 'time' applied to a *client* ?Yeah, that would explain a lot. When I first saw the numbers, I was so
excited because they showed that PostgreSQL is *faster* than MySQL (with
more memory, and better I/O).That didn't make any sense, though. MySQL is faster than every real DBMS,
because it doesn't have transactions, triggers, locking, or any other sort
of useful features to slow it down.The question should always be, is PostgreSQL faster than Oracle, Informix,
or Sybase?
I am told we are the same as Ingres, and slower than Oracle with no -F,
and faster than Oracle with -F.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 01:37:11 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA91682
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 01:37:04 -0400 (EDT)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id NAA17119;
Mon, 20 Sep 1999 13:33:39 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E5C733.ABE1902D@krs.ru>
Date: Mon, 20 Sep 1999 13:33:39 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] why do shmem attach?
References: <199909200404.AAA06848@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Or shmem inheritance is not portable?
If it works on your machine with it removed, commit the change and I can
test it here. I don't know of any portability problems with shared
memory children.
I wrote simple test program and it works under FreeBSD and Solaris
(on Ultra). Currently I'm not able to do more. Actually, I worry
does this work under MS Windows.
Vadim
From bouncefilter Mon Sep 20 01:53:52 1999
Received: from ritchie.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA93600
for <pgsql-hackers@postgresql.org>;
Mon, 20 Sep 1999 01:53:42 -0400 (EDT)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by ritchie.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id JAA20061;
Mon, 20 Sep 1999 09:53:35 +0400 (MSK/MSD)
X-Real-To: lamar.owen@wgcr.org
Received: (from dms@localhost)
by woland.wplus.net (8.9.2/8.9.1/wplus.2) id JAA01259;
Mon, 20 Sep 1999 09:53:29 +0400 (MSD)
Message-ID: <XFMail.990920095329.dms@wplus.net>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <37E543E7.9D621F95@pop.dn.net>
Date: Mon, 20 Sep 1999 09:53:29 +0400 (MSD)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: frankpit@pop.dn.net
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
Cc: pgsql-hackers@postgresql.org, Lamar Owen <lamar.owen@wgcr.org>
On 19-Sep-99 frankpit@pop.dn.net wrote:
Lamar Owen wrote:
btw, is it only me or do other people refer to this as "pig dump"?
Worse -- I see '/usr/lib/pgsql' and say "user-lib-pigsqueal."
The first time my wife, saw the title of this mail-list she pronounced
pgsql `pig squeal', and was rather upset at the thought of
^^^^^^^^^^^
It's good reason to change postgres's logo - I'can remade site in
pig's colors ;-))))
---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...
From bouncefilter Mon Sep 20 02:25:49 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA97922
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 02:25:19 -0400 (EDT)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id PAA11531; Mon, 20 Sep 1999 15:24:19 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Vadim Mikheev" <vadim@krs.ru>,
"Bruce Momjian" <maillist@candle.pha.pa.us>
Cc: "PostgreSQL Developers List" <hackers@postgreSQL.org>
Subject: RE: [HACKERS] why do shmem attach?
Date: Mon, 20 Sep 1999 15:27:48 +0900
Message-ID: <000001bf0331$4211b200$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <37E5C733.ABE1902D@krs.ru>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Vadim Mikheev
Sent: Monday, September 20, 1999 2:34 PM
To: Bruce Momjian
Cc: PostgreSQL Developers List
Subject: Re: [HACKERS] why do shmem attach?Bruce Momjian wrote:
Or shmem inheritance is not portable?
If it works on your machine with it removed, commit the change and I can
test it here. I don't know of any portability problems with shared
memory children.I wrote simple test program and it works under FreeBSD and Solaris
(on Ultra). Currently I'm not able to do more. Actually, I worry
does this work under MS Windows.
Where do we attach to shmem after fork() ?
I couldn't find the place.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Sep 20 03:00:50 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA05520
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 03:00:44 -0400 (EDT)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id OAA17568;
Mon, 20 Sep 1999 14:58:03 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E5DAFB.18D54027@krs.ru>
Date: Mon, 20 Sep 1999 14:58:03 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] why do shmem attach?
References: <000001bf0331$4211b200$2801007e@cadzone.tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hiroshi Inoue wrote:
Where do we attach to shmem after fork() ?
I couldn't find the place.
Ops, sorry, you're right - postinit.c:InitCommunication():
if (!IsUnderPostmaster) /* postmaster already did this */
{
PostgresIpcKey = key;
AttachSharedMemoryAndSemaphores(key);
}
Though, AttachSharedMemoryAndSemaphores():
if (key == PrivateIPCKey)
{
CreateSharedMemoryAndSemaphores(key, 16);
return;
}
... and useless shmem attachment stuff follows after this ...
Cleanup is still required, but subj is closed, thanks -:)
Vadim
From bouncefilter Mon Sep 20 03:23:10 1999
Received: from flame.flame.co.za (flame.flame.co.za [160.124.170.1])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA08448
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 03:23:01 -0400 (EDT)
(envelope-from theo@flame.co.za)
Received: from flame.co.za (flame [160.124.170.1])
by flame.flame.co.za (8.8.7/8.8.7) with ESMTP id JAA09181
for <pgsql-hackers@postgreSQL.org>; Mon, 20 Sep 1999 09:28:40 +0200
Sender: theo@flame.flame.co.za
Message-ID: <37E5E228.F3E1321D@flame.co.za>
Date: Mon, 20 Sep 1999 09:28:40 +0200
From: Theo Kramer <theo@flame.co.za>
Organization: Flame Computing Enterprises
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.35 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <20970.937688441@sss.pgh.pa.us>
<99091817232103.00581@lowen.wgcr.org>
<37E479DA.6FDFA5F4@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
Underscores in program names suck. To paraphrase Ali, "no opinion,
just fact" ;)If we are going to rename programs wholesale, let's do it for release
7.0, and if we must have "pg" in front of everything, then do it as,
e.g. "pgcreateuser". We could rename "pg_dump" as "pgdump" at the same
time.
I agree regarding the underscore. I do think that changing the names
sooner would create less hassle in the long run. Especially now when
more and more folk are starting to use postgres.
btw, is it only me or do other people refer to this as "pig dump"?
grunt :-)
--------
Regards
Theo
From bouncefilter Mon Sep 20 06:02:52 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id GAA35513
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 06:02:28 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11T0Dx-0003kLC; Mon, 20 Sep 99 11:59 MET DST
Message-Id: <m11T0Dx-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: Referential Integrity In PostgreSQL
To: massimo.lambertini@everex.it (Massimo)
Date: Mon, 20 Sep 1999 11:59:05 +0200 (MET DST)
Cc: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37E2C81A.9F65978E@everex.it> from "Massimo" at Sep 18,
99 01:00:42 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Hi , Jan
my name is Max .
Hi Max,
I have contributed to SPI interface ,
that with external Trigger try to make
a referential integrity.If I can Help , in something ,
I'm here .
You're welcome.
I've CC'd the hackers list because we might get some ideas
from there too (and to surface once in a while - Bruce
already missed me).
Currently I'm very busy for serious work so I don't find
enough spare time to start on such a big change to
PostgreSQL. But I'd like to give you an overview of what I
have in mind so far so you can decide if you're able to help.
Referential integrity (RI) is based on constraints defined in
the schema of a database. There are some different types of
constraints:
1. Uniqueness constraints.
2. Foreign key constraints that ensure that a key value used
in an attribute exists in another relation. One
constraint must ensure you're unable to INSERT/UPDATE to
a value that doesn't exist, another one must prevent
DELETE on a referenced key item or that it is changed
during UPDATE.
3. Cascading deletes that let rows referring to a key follow
on DELETE silently.
Even if not defined in the standard (AFAIK) there could be
others like letting references automatically follow on UPDATE
to a key value.
All constraints can be enabled and/or default to be deferred.
That means, that the RI checks aren't performed when they are
triggerd. Instead, they're checked at transaction end or if
explicitly invoked by some special statement. This is really
important because someone must be able to setup cyclic RI
checks that could never be satisfied if the checks would be
performed immediately. The major problem on this is the
amount of data affected until the checks must be performed.
The number of statements executed, that trigger such deferred
constraints, shouldn't be limited. And one single
INSERT/UPDATE/DELETE could affect thousands of rows.
Due to these problems I thought, it might not be such a good
idea to remember CTID's or the like to get back OLD/NEW rows
at the time the constraints are checked. Instead I planned to
misuse the rule system for it. Unfortunately, the rule system
has damned tricky problems itself when it comes to having-,
distinct and other clauses and extremely on aggregates and
subselects. These problems would have to get fixed first. So
it's a solution that cannot be implemented right now.
Fallback to CTID remembering though. There are problems too
:-(. Let's enhance the trigger mechanism with a deferred
feature. First this requires two additional bool attributes
in the pg_trigger relation that tell if this trigger is
deferrable and if it is deferred by default. While at it we
should add another bool that tells if the trigger is enabled
(ALTER TRIGGER {ENABLE|DISABLE} trigger).
Second we need an internal list of triggers, that are
currently DEFINED AS DEFERRED. Either because they default to
it, or the user explicitly asked to deferr it.
Third we need an internal list of triggers that must be
invoked later because at the time an event occured where they
should have been triggered, they appeared in the other list
and their execution is delayed until transaction end or
explicit execution. This list must remember the OID of the
trigger to invoke (to identify the procedure and the
arguments), the relation that caused the trigger and the
CTID's of the OLD and NEW row.
That last list could grow extremely! Think of a trigger
that's executing commands over SPI which in turn activate
deferred triggers. Since the order of trigger execution is
very important for RI, I can't see any chance to
simplify/condense this information. Thus it is 16 bytes at
least per deferred trigger call (2 OID's plus 2 CTID's). I
think one or more temp files would fit best for this.
A last tricky point is if one of a bunch of deferred triggers
is explicitly called for execution. At this time, the entries
for it in the temp file(s) must get processed and marked
executed (maybe by overwriting the triggers OID with the
invalid OID) while other trigger events still have to get
recorded.
Needless to say that reading thousands of those entries just
to find a few isn't good on performance. But better have this
special case slow that dealing with hundreds of temp files or
other overhead slowing down the usual case where ALL deferred
triggers get called at transaction end.
Trigger invocation is simple now - fetch the OLD and NEW rows
by CTID and execute the trigger as done by the trigger
manager. Oh - well - vacuum shouldn't touch relations where
deferred triggers are outstanding. Might require some
special lock entry - Vadim?
Did I miss something?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Mon Sep 20 09:31:54 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA60893
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 09:31:29 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id JAA18372;
Mon, 20 Sep 1999 09:21:04 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909201321.JAA18372@candle.pha.pa.us>
Subject: Re: [HACKERS] why do shmem attach?
In-Reply-To: <37E5C733.ABE1902D@krs.ru> from Vadim Mikheev at "Sep 20,
1999 01:33:39 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Mon, 20 Sep 1999 09:21:04 -0400 (EDT)
CC: PostgreSQL Developers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Or shmem inheritance is not portable?
If it works on your machine with it removed, commit the change and I can
test it here. I don't know of any portability problems with shared
memory children.I wrote simple test program and it works under FreeBSD and Solaris
(on Ultra). Currently I'm not able to do more. Actually, I worry
does this work under MS Windows.
This code was not added for MS Windows, so it is anyone's guess whether
it needs it. Let's remove it and see.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 09:32:14 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA60946
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 09:32:06 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id JAA18526;
Mon, 20 Sep 1999 09:23:19 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909201323.JAA18526@candle.pha.pa.us>
Subject: Re: [HACKERS] why do shmem attach?
In-Reply-To: <37E5DAFB.18D54027@krs.ru> from Vadim Mikheev at "Sep 20,
1999 02:58:03 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Mon, 20 Sep 1999 09:23:19 -0400 (EDT)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL Developers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hiroshi Inoue wrote:
Where do we attach to shmem after fork() ?
I couldn't find the place.Ops, sorry, you're right - postinit.c:InitCommunication():
if (!IsUnderPostmaster) /* postmaster already did this */
{
PostgresIpcKey = key;
AttachSharedMemoryAndSemaphores(key);
}Though, AttachSharedMemoryAndSemaphores():
if (key == PrivateIPCKey)
{
CreateSharedMemoryAndSemaphores(key, 16);
return;
}... and useless shmem attachment stuff follows after this ...
Cleanup is still required, but subj is closed, thanks -:)
My guess is that this is something I missed when removing the exec().
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 09:31:14 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA60839
for <pgsql-hackers@hub.org>; Mon, 20 Sep 1999 09:30:56 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id JAA18590;
Mon, 20 Sep 1999 09:27:10 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909201327.JAA18590@candle.pha.pa.us>
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
In-Reply-To: <386D3F80.EE1DB6F3@tech.com.au> from Chris Bitmead at "Jan 1,
2000
10:42:56 am"
To: Chris Bitmead <chris@tech.com.au>
Date: Mon, 20 Sep 1999 09:27:10 -0400 (EDT)
CC: pgsql-hackers@hub.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I am told we are the same as Ingres, and slower than Oracle with no -F,
and faster than Oracle with -F.What is "-F"?
-F is postgres option for no-fsync.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 09:36:14 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA61593
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 09:35:55 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id JAA18743
for pgsql-hackers@postgreSQL.org; Mon, 20 Sep 1999 09:35:51 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909201335.JAA18743@candle.pha.pa.us>
Subject: Status on Jan Wieck
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 20 Sep 1999 09:35:51 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 09:49:54 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA64943
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 09:49:09 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id VAA19789;
Mon, 20 Sep 1999 21:40:45 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E6395D.AEB27F50@krs.ru>
Date: Mon, 20 Sep 1999 21:40:45 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Status on Jan Wieck
References: <199909201335.JAA18743@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.
Is he going to implement RI for 6.6?
Vadim
From bouncefilter Mon Sep 20 09:45:54 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA64283
for <hackers@postgresql.org>; Mon, 20 Sep 1999 09:45:35 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA13481;
Mon, 20 Sep 1999 09:44:10 -0400 (EDT)
To: Vadim Mikheev <vadim@krs.ru>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL Developers List <hackers@postgresql.org>
Subject: Re: [HACKERS] why do shmem attach?
In-reply-to: Your message of Mon, 20 Sep 1999 14:58:03 +0800
<37E5DAFB.18D54027@krs.ru>
Date: Mon, 20 Sep 1999 09:44:09 -0400
Message-ID: <13479.937835049@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Vadim Mikheev <vadim@krs.ru> writes:
Though, AttachSharedMemoryAndSemaphores():
if (key == PrivateIPCKey)
{
CreateSharedMemoryAndSemaphores(key, 16);
return;
}
... and useless shmem attachment stuff follows after this ...
That path is used for a standalone backend. Is that useless?
Cleanup is still required, but subj is closed, thanks -:)
I don't think it's worth messing with either. It'd be nice for code
beautification purposes to (a) combine the three shared-mem segments
we currently have into one, and (b) rely on the postmaster's having
attached the segment, so that all backends will see it at the same
location in their address space, which would let us get rid of the
MAKE_OFFSET/MAKE_PTR cruft. But getting the full benefit would
require cleaning up a lot of code, and it just doesn't seem like
a high-priority task. I'm also a little worried that we'd be
sacrificing portability --- some day we might be glad that we can
move those segments around...
regards, tom lane
From bouncefilter Mon Sep 20 12:30:16 1999
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA93673
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 12:29:44 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U117.dialup.udm.net [192.168.53.117])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id VAA36924;
Mon, 20 Sep 1999 21:27:36 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37E63B94.103BDE68@udmnet.ru>
Date: Mon, 20 Sep 1999 18:50:12 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
References: <27362.937756381@sss.pgh.pa.us>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
MySQL: 0.498u 0.150s 0:02.50 25.6% 10+1652k 0+0io 0pf+0w
PgSQL: 0.494u 0.061s 0:19.78 2.7% 10+1532k 0+0io 0pf+0w
From the 'time' numbers, MySQL is running ~17sec faster, but uses up 23%
more CPU to do this...so where is our slowdown?It's gotta be going into I/O, obviously. (I hate profilers that can't
count disk accesses...) My guess is that the index scans are losing
because they wind up touching too many disk pages. You show
On that particular machine that can be verified easily, I hope.
(there seems to be enough RAM). You can simply issue 10 to 100 such
queries in a row. Hopefully after the first query all needed info
will be in a disk cache, so the rest queries will not draw info from
disk. That will be a clean experiment.
--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.
From bouncefilter Mon Sep 20 09:56:54 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA66897
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 09:56:23 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA13535;
Mon, 20 Sep 1999 09:55:19 -0400 (EDT)
To: Vadim Mikheev <vadim@krs.ru>
cc: PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] why do shmem attach?
In-reply-to: Your message of Mon, 20 Sep 1999 11:35:25 +0800
<37E5AB7D.F8EA85D4@krs.ru>
Date: Mon, 20 Sep 1999 09:55:19 -0400
Message-ID: <13533.937835719@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Vadim Mikheev <vadim@krs.ru> writes:
Also, all this ShmemIndex stuff seems to be useless
(except of backend PID lookup but it's for sure
should be in separate hash table).
Have I got a deal for you ;-). I have uncommitted changes that add
a pointer (SHMEM_OFFSET that is) to each backend's PROC struct into
the per-backend info array that already existed in shmem.c. The
routines in shmem.c that searched for PROC structures are now in
sinval.c, and just do a simple scan of the ProcState array to find
the PROC structs. They should be a whole lot faster --- which is
good since these things run with spinlocks held...
These changes are intermixed with other things that are currently
triggering a lot of NOTICE: Buffer Leak messages in the regress tests,
so I don't want to commit until I've puzzled out the buffer refcount
issue. But I've got 'em and they seem to work fine.
And why separate shmem segment (!!!) is used for
Slocks (ipc.c:CreateAndInitSLockMemory(), etc) - they
use so small amount of memory!
Historical reasons I suppose. shmem.c does assume that spinlocks
are already up and running when it is initialized, so combining
everything into one segment would require care. But it's surely
doable if someone wants to take the time. (I don't.)
regards, tom lane
From bouncefilter Mon Sep 20 10:02:13 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA68031
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 10:01:47 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA13574;
Mon, 20 Sep 1999 10:00:40 -0400 (EDT)
To: Vadim Mikheev <vadim@krs.ru>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Notice: heap_open/close changes committed
In-reply-to: Your message of Mon, 20 Sep 1999 09:24:31 +0800
<37E58CCF.32C57B87@krs.ru>
Date: Mon, 20 Sep 1999 10:00:39 -0400
Message-ID: <13572.937836039@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Vadim Mikheev <vadim@krs.ru> writes:
Tom Lane wrote:
2. I made most opens of system relations grab AccessShareLock if
read-only, or RowExclusiveLock if read-write, on the theory that^^^^^^^^^^^^^^^^
There are problems here. In the case of normal UPDATE/DELETE
(when RowExclusiveLock is acquired) Executor takes care about
the-same-row writers, but other parts of system don't check
is tuple read being updated concurrent transaction or not.
Drat. I was afraid I might be getting in over my head :-(
This is the old bug (pre-6.5.X released WRITE lock just after
system table was modified). I had no time to fix it and so
just changed old WRITE lock with new AccessExclusiveLock.
I do not think changing RowExclusiveLock back to AccessExclusiveLock
will fix it unless we hold the lock till end of transaction, no?
That seems like much too high a price to pay.
But we have to handle this in proper way (wait if t_xmax
is id of an active transaction).
Yes. Where is the code that does this right in the regular executor?
I will see what needs to be done to make the system table accesses
act the same.
regards, tom lane
From bouncefilter Mon Sep 20 10:14:14 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA69925
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 10:13:27 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA13643;
Mon, 20 Sep 1999 10:07:52 -0400 (EDT)
To: Vadim Mikheev <vadim@krs.ru>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Anyone understand shared buffer refcount mechanism?
In-reply-to: Your message of Mon, 20 Sep 1999 09:56:40 +0800
<37E59458.64D563D@krs.ru>
Date: Mon, 20 Sep 1999 10:07:52 -0400
Message-ID: <13641.937836472@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Vadim Mikheev <vadim@krs.ru> writes:
Tom Lane wrote:
In trying to understand what the code is doing, I am confused by the
buffer refcount save/restore mechanism. Why does the executor want
to save/restore buffer refcounts? I can sort of see that that might
This bothered me for long time too.
The only explanation I see in execMain.c:
* this makes sure that when ExecutorRun's are called recursively as for
* postquel functions, the buffers pinned by one ExecutorRun will not
* be unpinned by another ExecutorRun.
The case that is currently failing for me is postquel function calls
(the "misc" regress test contains some, and it's spewing Buffer Leak
notices like crazy, now that I fixed BufferLeakCheck to notice nonzero
LastRefCount as well as nonzero PrivateRefCount). So there's something
rotten here. I will keep looking at it.
So, try to remove this save/restore mechanism and let's see...
It does seem that BufferRefCountRestore is actually unpinning some
things (things got much better after I fixed it to really do the
unpin when restoring a nonzero refcount to zero). So I don't
think I want to try to take out the save/restore entirely. What
it looks like right now is that a few specific paths through the
executor restore the wrong counts...
regards, tom lane
From bouncefilter Mon Sep 20 10:17:14 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA70632
for <hackers@postgresql.org>; Mon, 20 Sep 1999 10:16:30 -0400 (EDT)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id WAA19935;
Mon, 20 Sep 1999 22:09:20 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E64010.D1C1BA81@krs.ru>
Date: Mon, 20 Sep 1999 22:09:20 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL Developers List <hackers@postgresql.org>
Subject: Re: [HACKERS] why do shmem attach?
References: <13479.937835049@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Vadim Mikheev <vadim@krs.ru> writes:
Though, AttachSharedMemoryAndSemaphores():
if (key == PrivateIPCKey)
{
CreateSharedMemoryAndSemaphores(key, 16);
return;
}
... and useless shmem attachment stuff follows after this ...That path is used for a standalone backend. Is that useless?
Isn't key equal to PrivateIPCKey for standalone backend?
Cleanup is still required, but subj is closed, thanks -:)
I don't think it's worth messing with either. It'd be nice for code
beautification purposes to (a) combine the three shared-mem segments
we currently have into one, and (b) rely on the postmaster's having
I would try to use more than one segment for buffer pool if
max seg size is not enough for all buffers.
attached the segment, so that all backends will see it at the same
location in their address space, which would let us get rid of the
MAKE_OFFSET/MAKE_PTR cruft. But getting the full benefit would
require cleaning up a lot of code, and it just doesn't seem like
a high-priority task. I'm also a little worried that we'd be
sacrificing portability --- some day we might be glad that we can
move those segments around...
We can't. MAKE_OFFSET/MAKE_PTR was used because of after
fork/exec/shmat backend' ShmemBase was different from
postmaster' one. But we can't move *BufferDescriptors
if some running backend already uses BufferDescriptors.
But I agreed - this is not high-priority task -:)
Vadim
From bouncefilter Mon Sep 20 10:13:14 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA69840
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 10:13:00 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id KAA01543;
Mon, 20 Sep 1999 10:12:04 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909201412.KAA01543@candle.pha.pa.us>
Subject: Re: [HACKERS] Status on Jan Wieck
In-Reply-To: <37E6395D.AEB27F50@krs.ru> from Vadim Mikheev at "Sep 20,
1999 09:40:45 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Mon, 20 Sep 1999 10:12:04 -0400 (EDT)
CC: "PostgreSQL-development"@candle.pha.pa.us, pgsql-hackers@postgreSQL.org,
Jan Wieck <jwieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Is he going to implement RI for 6.6?
OK, let's CC him with the question. Jan, can you do referential
integrity for 6.6?
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 10:13:19 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA69776
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 10:12:32 -0400 (EDT)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id WAA19940;
Mon, 20 Sep 1999 22:12:28 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E640CC.5AC9C432@krs.ru>
Date: Mon, 20 Sep 1999 22:12:28 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] why do shmem attach?
References: <13533.937835719@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Vadim Mikheev <vadim@krs.ru> writes:
Also, all this ShmemIndex stuff seems to be useless
(except of backend PID lookup but it's for sure
should be in separate hash table).Have I got a deal for you ;-). I have uncommitted changes that add
a pointer (SHMEM_OFFSET that is) to each backend's PROC struct into
the per-backend info array that already existed in shmem.c. The
routines in shmem.c that searched for PROC structures are now in
sinval.c, and just do a simple scan of the ProcState array to find
the PROC structs. They should be a whole lot faster --- which is
good since these things run with spinlocks held...
Nice. I have new member for PROC that should be searched
sometime -:)
Vadim
From bouncefilter Mon Sep 20 10:14:19 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA69998
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 10:14:11 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id KAA01560;
Mon, 20 Sep 1999 10:13:48 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909201413.KAA01560@candle.pha.pa.us>
Subject: Re: [HACKERS] why do shmem attach?
In-Reply-To: <13479.937835049@sss.pgh.pa.us> from Tom Lane at "Sep 20,
1999 09:44:09 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 20 Sep 1999 10:13:48 -0400 (EDT)
CC: Vadim Mikheev <vadim@krs.ru>, Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL Developers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I don't think it's worth messing with either. It'd be nice for code
beautification purposes to (a) combine the three shared-mem segments
we currently have into one, and (b) rely on the postmaster's having
attached the segment, so that all backends will see it at the same
location in their address space, which would let us get rid of the
MAKE_OFFSET/MAKE_PTR cruft. But getting the full benefit would
require cleaning up a lot of code, and it just doesn't seem like
a high-priority task. I'm also a little worried that we'd be
sacrificing portability --- some day we might be glad that we can
move those segments around...
My opinion is that this code is complex enough without additional
complexity. If something can be removed/cleaned, why not do it? It is
usually very easy to do and doesn't take much time. The next person who
has to mess with it will thank us.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 10:29:14 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA73577
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 10:28:43 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA13771;
Mon, 20 Sep 1999 10:28:08 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] couldn't rollback cache ?
In-reply-to: Your message of Mon, 20 Sep 1999 11:47:49 +0900
<000701bf0312$87096de0$2801007e@cadzone.tpf.co.jp>
Date: Mon, 20 Sep 1999 10:28:08 -0400
Message-ID: <13769.937837688@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I think it's not done correctly for tuple SI messages either.
I didn't use current cache invalidation mechanism when I made the
patch for SearchSysCache() because of the following 2 reasons.
1. SI messages are eaten by CommandCounterIncrement(). So they
may vanish before transaction end/aborts.
I think this is OK. The sending backend does not send the SI message
in the first place until it has committed. Other backends can read
the messages at CommandCounterIncrement; it doesn't matter whether the
other backends later commit or abort their own transactions. I think.
Do you have a counterexample?
2. The tuples which should be invalidated in case of abort are different
from ones in case of commit.
In case of commit,deleting old tuples should be invalidated for all
backends.
In case of abort,insert(updat)ing new tuples should be invalidated
for the insert(updat)ing backend.
I wonder whether it wouldn't be cleaner to identify the target tuples
by OID instead of ItemPointer. That way would work for both new and
update tuples...
Currently heap_insert() calls RelationInvalidateHeapTuple() for a
inserting new tuple but heap_replace() doesn't call RelationInvalid-
ateHeapTuple() for a updating new tuple. I don't understand which
is right.
Hmm. Invalidating the old tuple is the right thing for heap_replace in
terms of sending a message to other backends at commit; it's the old
tuple that they might have cached and need to get rid of. But for
getting rid of this backend's uncommitted new tuple in case of abort,
it's not the right thing. OTOH, your change to add a time qual check
to SearchSysCache would fix that, wouldn't it? But invalidating by OID
would make the issue moot.
Possibly heap_insert doesn't need to be calling
RelationInvalidateHeapTuple at all --- a new tuple can't be cached by
any other backend, by definition, until it has committed; so there's no
need to send out an SI message for it. That call must be there to
ensure that the local cache gets purged of the tuple in case of abort.
Maybe we could remove that call (and reduce SI traffic) if we rely on
a time qual to purge bogus entries from the local caches after abort.
regards, tom lane
From bouncefilter Mon Sep 20 10:38:19 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA75716
for <hackers@postgresql.org>; Mon, 20 Sep 1999 10:38:15 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA13851;
Mon, 20 Sep 1999 10:36:32 -0400 (EDT)
To: Vadim Mikheev <vadim@krs.ru>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL Developers List <hackers@postgresql.org>
Subject: Re: [HACKERS] why do shmem attach?
In-reply-to: Your message of Mon, 20 Sep 1999 22:09:20 +0800
<37E64010.D1C1BA81@krs.ru>
Date: Mon, 20 Sep 1999 10:36:31 -0400
Message-ID: <13849.937838191@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Vadim Mikheev <vadim@krs.ru> writes:
I don't think it's worth messing with either. It'd be nice for code
beautification purposes to (a) combine the three shared-mem segments
we currently have into one, and (b) rely on the postmaster's having
I would try to use more than one segment for buffer pool if
max seg size is not enough for all buffers.
Ah, that would be a nice end-run around kernels with small SHMMAX,
wouldn't it?
I'm also a little worried that we'd be
sacrificing portability --- some day we might be glad that we can
move those segments around...
We can't. MAKE_OFFSET/MAKE_PTR was used because of after
fork/exec/shmat backend' ShmemBase was different from
postmaster' one. But we can't move *BufferDescriptors
if some running backend already uses BufferDescriptors.
Right, we can't relocate a segment within the address space of
an already-running backend. What I meant was that being able
to put it at different addresses in different backends might be
needed again someday, even though right now we don't need it.
But I agreed - this is not high-priority task -:)
Yup. Plenty of high-priority ones, too...
regards, tom lane
From bouncefilter Mon Sep 20 10:51:14 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA77586
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 10:50:43 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA13911;
Mon, 20 Sep 1999 10:49:10 -0400 (EDT)
To: Vadim Mikheev <vadim@krs.ru>
cc: PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] why do shmem attach?
In-reply-to: Your message of Mon, 20 Sep 1999 22:12:28 +0800
<37E640CC.5AC9C432@krs.ru>
Date: Mon, 20 Sep 1999 10:49:10 -0400
Message-ID: <13909.937838950@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Vadim Mikheev <vadim@krs.ru> writes:
Tom Lane wrote:
Have I got a deal for you ;-). I have uncommitted changes that add
a pointer (SHMEM_OFFSET that is) to each backend's PROC struct into
the per-backend info array that already existed in shmem.c.
Nice. I have new member for PROC that should be searched
sometime -:)
OK, cool. Easy enough to add now. The reason I did this was that
I added to PROC the OID of the database the backend is attached to,
so that I could make a routine to tell whether any running backends
are connected to a given database. I couldn't quite stomach adding
yet another ShmemIndex-traverser to shmem.c, so...
(I'm sure you can see already where I'm going with that: DESTROY
DATABASE now refuses to destroy a database that has running backends.
I got burnt that way once too often. The interlock against
halfway-started backends was a tad tricky, but I think it works.)
regards, tom lane
From bouncefilter Mon Sep 20 11:00:19 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA79391
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 11:00:08 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA13980;
Mon, 20 Sep 1999 10:58:34 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Status on Jan Wieck
In-reply-to: Your message of Mon, 20 Sep 1999 09:35:51 -0400 (EDT)
<199909201335.JAA18743@candle.pha.pa.us>
Date: Mon, 20 Sep 1999 10:58:33 -0400
Message-ID: <13978.937839513@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.
Good ... I was starting to fear he'd been run over by a truck or
something :-(
Does he have any idea when/if he'll return to Postgres hacking?
regards, tom lane
From bouncefilter Mon Sep 20 11:40:20 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA85224
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 11:40:13 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id LAA03894;
Mon, 20 Sep 1999 11:30:50 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909201530.LAA03894@candle.pha.pa.us>
Subject: Re: [HACKERS] Status on Jan Wieck
In-Reply-To: <13978.937839513@sss.pgh.pa.us> from Tom Lane at "Sep 20,
1999 10:58:33 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 20 Sep 1999 11:30:50 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <maillist@candle.pha.pa.us> writes:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Good ... I was starting to fear he'd been run over by a truck or
something :-(
Yep. He says "don't worry".
Does he have any idea when/if he'll return to Postgres hacking?
I didn't have the heart to ask him. I just hit him with the referential
integrity question. Let's see what he says.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 11:41:20 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA85334
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 11:40:57 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id LAA03910;
Mon, 20 Sep 1999 11:32:16 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909201532.LAA03910@candle.pha.pa.us>
Subject: Re: [HACKERS] Status on Jan Wieck
In-Reply-To: <13978.937839513@sss.pgh.pa.us> from Tom Lane at "Sep 20,
1999 10:58:33 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 20 Sep 1999 11:32:16 -0400 (EDT)
CC: "PostgreSQL-development"@candle.pha.pa.us, pgsql-hackers@postgreSQL.org,
Jan Wieck <jwieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <maillist@candle.pha.pa.us> writes:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Good ... I was starting to fear he'd been run over by a truck or
something :-(Does he have any idea when/if he'll return to Postgres hacking?
That brings up another issue.
Why do people think programmers are throwing themselves in front of
trucks? Any idea? I hear it often.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 11:41:15 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA85304
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 11:40:42 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id LAA03927;
Mon, 20 Sep 1999 11:33:29 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909201533.LAA03927@candle.pha.pa.us>
Subject: Re: [HACKERS] Status on Jan Wieck
In-Reply-To: <37E6395D.AEB27F50@krs.ru> from Vadim Mikheev at "Sep 20,
1999 09:40:45 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Mon, 20 Sep 1999 11:33:29 -0400 (EDT)
CC: "PostgreSQL-development"@candle.pha.pa.us, pgsql-hackers@postgreSQL.org,
Jan Wieck <jwieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Is he going to implement RI for 6.6?
Jan, you know we miss you when you have your own subject thread on the
hackers list.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 11:47:20 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA86444
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 11:46:37 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id XAA20263;
Mon, 20 Sep 1999 23:39:59 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E6554E.8F4C0F13@krs.ru>
Date: Mon, 20 Sep 1999 23:39:58 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Notice: heap_open/close changes committed
References: <13572.937836039@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
This is the old bug (pre-6.5.X released WRITE lock just after
system table was modified). I had no time to fix it and so
just changed old WRITE lock with new AccessExclusiveLock.I do not think changing RowExclusiveLock back to AccessExclusiveLock
will fix it unless we hold the lock till end of transaction, no?
Yes.
That seems like much too high a price to pay.
That's why I proposed to use Exclusive lock (it doesn't conflict
with AccessShareLock used by readers).
But we have to handle this in proper way (wait if t_xmax
is id of an active transaction).Yes. Where is the code that does this right in the regular executor?
I will see what needs to be done to make the system table accesses
act the same.
Sorry - I messed things up: heap_replace/heap_delete wait for
concurrent update, but doesn't update/delete modified tuple.
They return result code (HeapTupleMayBeUpdated etc in utils/tqual.h)
and it's up to caller decide what to do if tuple modified by
concurrent transaction.
For _updated_ tuple TID of new tuple version is also returned
(if requested)...
Examples of how this is handled/used by Executor are
in execMain.c (just search for HeapTupleUpdated).
Vadim
From bouncefilter Mon Sep 20 12:21:15 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA91905
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 12:20:46 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
KAA21866;
Mon, 20 Sep 1999 10:19:49 -0600 (MDT)
Date: Mon, 20 Sep 1999 10:19:49 -0600 (MDT)
Message-Id: <199909201619.KAA21866@biology.nmsu.edu>
X-Authentication-Warning: biology.nmsu.edu: brook set sender to
brook@biology.nmsu.edu using -f
From: Brook Milligan <brook@biology.nmsu.edu>
To: grim@argh.demon.co.uk
CC: lockhart@alumni.caltech.edu, lamar.owen@wgcr.org, tgl@sss.pgh.pa.us,
theo@flame.co.za, pgsql-hackers@postgreSQL.org
In-reply-to: <199909190614.HAA24060@argh.demon.co.uk> (message from Michael
Simms on Sun, 19 Sep 1999 07:14:57 +0100 (BST))
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <199909190614.HAA24060@argh.demon.co.uk>
IIRC majordomo puts the whole slew of commands in the same directory, usually
/usr/local/bin when you install it. Most of these are not really user commands
Majordomo isn't really the best standard for installation
directories. Please do not follow it as a general guideline.
Cheers,
Brook
From bouncefilter Mon Sep 20 12:29:21 1999
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net
[194.217.242.38]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA93576
for <pgsql-hackers@postgresql.org>;
Mon, 20 Sep 1999 12:29:14 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from maidstonebc.demon.co.uk ([158.152.139.246]
helo=gatekeeper.maidstone.gov.uk)
by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
id 11T6JQ-0005D0-0A; Mon, 20 Sep 1999 16:29:09 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id SAA08017;
Mon, 20 Sep 1999 18:22:49 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <S7M83AHT>; Mon, 20 Sep 1999 17:27:30 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E609@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Bruce Momjian'" <maillist@candle.pha.pa.us>
Cc: "PostgreSQL-development"@candle.pha.pa.us, pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] Status on Jan Wieck
Date: Mon, 20 Sep 1999 17:27:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Here in the uk, it's usually a number 42 Bus...
Peter
--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.
-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: 20 September 1999 16:32
To: Tom Lane
Cc: "PostgreSQL-development"@candle.pha.pa.us;
pgsql-hackers@postgreSQL.org; Jan Wieck
Subject: Re: [HACKERS] Status on Jan Wieck
Bruce Momjian <maillist@candle.pha.pa.us> writes:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Good ... I was starting to fear he'd been run over by a truck or
something :-(Does he have any idea when/if he'll return to Postgres hacking?
That brings up another issue.
Why do people think programmers are throwing themselves in front of
trucks? Any idea? I hear it often.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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
19026************
From bouncefilter Mon Sep 20 12:55:16 1999
Received: from etabeta.xt.net (IDENT:root@etabeta.xt.net [62.212.0.40])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA98991
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 12:55:00 -0400 (EDT)
(envelope-from daniele@orlandi.com)
Received: from orlandi.com (nabla.xt.net [62.212.0.41])
by etabeta.xt.net (8.9.3/8.8.8) with ESMTP id SAA02989
for <pgsql-hackers@postgreSQL.org>; Mon, 20 Sep 1999 18:54:56 +0200
Message-ID: <37E666E0.92E37B0C@orlandi.com>
Date: Mon, 20 Sep 1999 18:54:56 +0200
From: Daniele Orlandi <daniele@orlandi.com>
Organization: Utility Line Italia
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: it
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Crash (maybe related to temp tables)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
Using PostgreSQL 6.5.2 just compiled on a RedHat 6.0 box.
------------------------
BEGIN;
SELECT username,count(*) AS nsessions INTO TEMP TABLE active_nsessions FROM
active GROUP BY username
SELECT username,count(*) AS nlinks INTO TEMP TABLE active_nlinks FROM active
GROUP BY username,port,server
SELECT * FROM active,counters,users,active_nsessions,active_nlinks WHERE
active.username=users.username AND active.username=counters.username AND
active.username=active_nsessions.username AND
active.username=active_nlinks.username
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
------------------------
Active table is empty with this structure:
CREATE TABLE active
(
username varchar(32),
server varchar(35),
pop varchar(20),
remAddr varchar(30),
port varchar(15),
service varchar(10),
addr inet,
privilege int2,
authenmethod int2,
authentype int2,
authenservice int2,
starttime datetime,
taskid int4,
callerid varchar(21),
callednumber varchar(21),
rxrate int4,
txrate int4,
bytesin int8,
bytesout int8,
paksin int8,
paksout int8,
watchdog_timeout timespan,
watchdog_lastreset datetime,
logout_requested bool,
logout_request_time datetime
);
Bye!
--
Daniele
-------------------------------------------------------------------------------
Daniele Orlandi - Utility Line Italia - http://www.orlandi.com
Via Mezzera 29/A - 20030 - Seveso (MI) - Italy
-------------------------------------------------------------------------------
From bouncefilter Mon Sep 20 13:05:16 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id NAA01088
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 13:04:34 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11T6kX-0003kLC; Mon, 20 Sep 99 18:57 MET DST
Message-Id: <m11T6kX-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: jwieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Status on Jan Wieck
To: vadim@krs.ru (Vadim Mikheev)
Date: Mon, 20 Sep 1999 18:57:09 +0200 (MET DST)
Cc: maillist@candle.pha.pa.us, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37E6395D.AEB27F50@krs.ru> from "Vadim Mikheev" at Sep 20,
99 09:40:45 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Bruce Momjian wrote:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Is he going to implement RI for 6.6?
Depends on WHEN 6.6 is planned to go into feature-freeze.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Mon Sep 20 13:33:16 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA07504
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 13:32:40 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id BAA20703;
Tue, 21 Sep 1999 01:23:57 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E66DAC.8CD740B4@krs.ru>
Date: Tue, 21 Sep 1999 01:23:56 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: maillist@candle.pha.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status on Jan Wieck
References: <m11T6kX-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jan Wieck wrote:
Bruce Momjian wrote:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Is he going to implement RI for 6.6?
Depends on WHEN 6.6 is planned to go into feature-freeze.
Well, I believe that we have at least 3 months before 1st beta.
We need in DIRTY READs for RI and I'll implement them.
If you'll not be able to do RI itself then we might
change refint.c to use DIRTY READs and so avoid LOCK TABLE
on application level (i.e. restore pre-6.5 refint.c using).
Vadim
From bouncefilter Mon Sep 20 14:01:22 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA13124
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 14:01:03 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id NAA07187;
Mon, 20 Sep 1999 13:39:20 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909201739.NAA07187@candle.pha.pa.us>
Subject: Re: [HACKERS] Status on Jan Wieck
In-Reply-To: <m11T6kX-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Sep 20, 1999 06:57:09 pm"
To: Jan Wieck <wieck@debis.com>
Date: Mon, 20 Sep 1999 13:39:19 -0400 (EDT)
CC: Vadim Mikheev <vadim@krs.ru>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Is he going to implement RI for 6.6?
Depends on WHEN 6.6 is planned to go into feature-freeze.
You tell us... We clearly could wait if you have some idea on a
timeframe. There has been no talk of a 6.6 release schedule yet. Vadim
is still working on logging, and Tom Lane is working too.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 14:30:17 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA17725
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 14:29:31 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id OAA07550;
Mon, 20 Sep 1999 14:14:51 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909201814.OAA07550@candle.pha.pa.us>
Subject: Re: [HACKERS] Status on Jan Wieck
In-Reply-To: <37E66DAC.8CD740B4@krs.ru> from Vadim Mikheev at "Sep 21,
1999 01:23:56 am"
To: Vadim Mikheev <vadim@krs.ru>
Date: Mon, 20 Sep 1999 14:14:51 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Depends on WHEN 6.6 is planned to go into feature-freeze.
Well, I believe that we have at least 3 months before 1st beta.
We need in DIRTY READs for RI and I'll implement them.
If you'll not be able to do RI itself then we might
change refint.c to use DIRTY READs and so avoid LOCK TABLE
on application level (i.e. restore pre-6.5 refint.c using).
Yikes. Three months. That puts us at release in mid-January.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 14:24:17 1999
Received: from spot.pupworks.com (adsl-151-200-22-96.bellatlantic.net
[151.200.22.96]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA16737
for <pgsql-ports@postgreSQL.org>; Mon, 20 Sep 1999 14:23:39 -0400 (EDT)
(envelope-from nrh@spot.pupworks.com)
Received: from spot.pupworks.com (localhost.pupworks.com [127.0.0.1])
by spot.pupworks.com (8.9.3/8.9.3) with ESMTP id OAA16477;
Mon, 20 Sep 1999 14:22:40 -0400 (EDT)
(envelope-from nrh@spot.pupworks.com)
Message-Id: <199909201822.OAA16477@spot.pupworks.com>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Nat Howard <nrh@pupworks.com>, pgsql-ports@postgreSQL.org,
Jan Wieck <jwieck@debis.com>
Subject: Re: [PORTS] plpgsql & bsdi 4.0
In-reply-to: Your message of "Mon, 20 Sep 1999 00:04:39 EDT."
<199909200404.AAA06855@candle.pha.pa.us>
Date: Mon, 20 Sep 1999 14:22:39 -0400
From: Nat Howard <nrh@pupworks.com>
Thanks -- I did a similar change, which had similar results.
I'm afraid I can't be of any help on the question of how
BSDI handles shared libraries. I don't currently have a support
contract with them, so I don't have a graceful "in" to ask them.I would say you have now duplicated the problem I was asking about,
and if someone can solve it, I'll be a very happy fella.Does the new patch make it work, or just fail in a different way?
Hmmm... I might have missed a message, but if by "the new patch" you
mean the patch that declares yyline in pl_comp.c, then the way to
put it is that I get the same failure you do: plpgsql regression
test fails with the same (or nearly the same) error message you
got. The only difference between our patches is that you got rid
of the "extern" in pl_comp.c and I did it in scan.l.
Or, to put it another way:
Virgin 6.5.2 on BSDI 4.0:
Regresion test yields this error in the postmaster output on every
attempt to use plpgsql:
/usr/local/pgsql.new/bin/postmaster: can't resolve symbol 'plpgsql_yylineno'
ERROR: Load of file /usr/local/pgsql.new/lib/plpgsql.so failed: Unable to resolve symbol
I then came up with the patch of removing the "extern" from the declaration
of plpgsql_yylineno in scan.l (actually, it's called "yylineno" there and
changed later. Call that "Nat Patch #1"
You came up with a similar patch with identical consequences: you got
rid of the "extern" from the delcaration of plpgsql_yylineno in
pl_comp.c. Call this "Bruce Patch #1".
6.5.2 with Nat Patch #1 OR Bruce patch #1 fixes *most* of the
plpgsql errors, but the plpgsql regression still fails, in a smaller way:
you get these errors on postmaster output:
...
ERROR: Relation 'tmp' does not have attribute 'k'
NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
ERROR: syntax error at or near "q0xf2&^H^F"
DEBUG: Last error occured while executing PL/pgSQL function pslot_backlink_view
DEBUG: line 1 at return
NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
ERROR: syntax error at or near "q0xf2&^H^F"
DEBUG: Last error occured while executing PL/pgSQL function pslot_backlink_view
DEBUG: line 1 at return
and the regression.diffs file contains this:
*** expected/plpgsql.out Wed Sep 30 23:38:35 1998
--- results/plpgsql.out Sun Sep 19 01:48:14 1999
***************
*** 1275,1319 ****
QUERY: insert into IFace values ('IF', 'orion', 'eth0', 'WS.002.1b');
QUERY: update PSlot set slotlink = 'HS.base.hub1.1' where slotname = 'PS.base.b2';
QUERY: select * from PField_v1 where pfname = 'PF0_1' order by slotname;
! pfname|slotname |backside |patch
! ------+--------------------+--------------------------------------------------------+---------------------------------------------
! PF0_1 |PS.base.a1 |WS.001.1a in room 001 -> Phone PH.hc001 (Hicom standard)|PS.base.ta1 -> Phone line -0 (Central call)
! PF0_1 |PS.base.a2 |WS.001.1b in room 001 -> - |-
! PF0_1 |PS.base.a3 |WS.001.2a in room 001 -> Phone PH.fax001 (Canon fax) |PS.base.ta2 -> Phone line -501 (Fax entrance)
! PF0_1 |PS.base.a4 |WS.001.2b in room 001 -> - |-
! PF0_1 |PS.base.a5 |WS.001.3a in room 001 -> - |-
! PF0_1 |PS.base.a6 |WS.001.3b in room 001 -> - |-
! PF0_1 |PS.base.b1 |WS.002.1a in room 002 -> Phone PH.hc002 (Hicom standard)|PS.base.ta5 -> Phone line -103
! PF0_1 |PS.base.b2 |WS.002.1b in room 002 -> orion IF eth0 (PC) |Patchfield PF0_1 hub slot 1
! PF0_1 |PS.base.b3 |WS.002.2a in room 002 -> Phone PH.hc003 (Hicom standard)|PS.base.tb2 -> Phone line -106
! PF0_1 |PS.base.b4 |WS.002.2b in room 002 -> - |-
! PF0_1 |PS.base.b5 |WS.002.3a in room 002 -> - |-
! PF0_1 |PS.base.b6 |WS.002.3b in room 002 -> - |-
! PF0_1 |PS.base.c1 |WS.003.1a in room 003 -> - |-
! PF0_1 |PS.base.c2 |WS.003.1b in room 003 -> - |-
! PF0_1 |PS.base.c3 |WS.003.2a in room 003 -> - |-
! PF0_1 |PS.base.c4 |WS.003.2b in room 003 -> - |-
! PF0_1 |PS.base.c5 |WS.003.3a in room 003 -> - |-
! PF0_1 |PS.base.c6 |WS.003.3b in room 003 -> - |-
! (18 rows)
!
QUERY: select * from PField_v1 where pfname = 'PF0_2' order by slotname;
! pfname|slotname |backside |patch
! ------+--------------------+------------------------------+----------------------------------------------------------------------
! PF0_2 |PS.base.ta1 |Phone line -0 (Central call) |PS.base.a1 -> WS.001.1a in room 001 -> Phone PH.hc001 (Hicom standard)
! PF0_2 |PS.base.ta2 |Phone line -501 (Fax entrance)|PS.base.a3 -> WS.001.2a in room 001 -> Phone PH.fax001 (Canon fax)
! PF0_2 |PS.base.ta3 |Phone line -102 |-
! PF0_2 |PS.base.ta4 |- |-
! PF0_2 |PS.base.ta5 |Phone line -103 |PS.base.b1 -> WS.002.1a in room 002 -> Phone PH.hc002 (Hicom standard)
! PF0_2 |PS.base.ta6 |Phone line -104 |-
! PF0_2 |PS.base.tb1 |- |-
! PF0_2 |PS.base.tb2 |Phone line -106 |PS.base.b3 -> WS.002.2a in room 002 -> Phone PH.hc003 (Hicom standard)
! PF0_2 |PS.base.tb3 |Phone line -108 |-
! PF0_2 |PS.base.tb4 |Phone line -109 |-
! PF0_2 |PS.base.tb5 |Phone line -121 |-
! PF0_2 |PS.base.tb6 |Phone line -122 |-
! (12 rows)
!
QUERY: insert into PField values ('PF1_1', 'should fail due to unique index');
ERROR: Cannot insert a duplicate key into a unique index
QUERY: update PSlot set backlink = 'WS.not.there' where slotname = 'PS.base.a1';
--- 1275,1285 ----
QUERY: insert into IFace values ('IF', 'orion', 'eth0', 'WS.002.1b');
QUERY: update PSlot set slotlink = 'HS.base.hub1.1' where slotname = 'PS.base.b2';
QUERY: select * from PField_v1 where pfname = 'PF0_1' order by slotname;
! NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
! ERROR: parse error at or near "q0xe2&^H^F"
QUERY: select * from PField_v1 where pfname = 'PF0_2' order by slotname;
! NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
! ERROR: parse error at or near "q0xe2&^H^F"
QUERY: insert into PField values ('PF1_1', 'should fail due to unique index');
ERROR: Cannot insert a duplicate key into a unique index
QUERY: update PSlot set backlink = 'WS.not.there' where slotname = 'PS.base.a1';----------------------
So, the remaining problem is to fix those errors. Now, it's possible
you sent "Bruce Patch #2", and I missed it. Did you?
Or do you still have the error from the regression test shown above?
If you do, then there's still work to do, but if you don't, I missed
something -- please send it again!
Thanks a lot for the help!
From bouncefilter Mon Sep 20 14:53:20 1999
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net
[194.217.242.41]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA21473
for <pgsql-hackers@postgresql.org>;
Mon, 20 Sep 1999 14:52:36 -0400 (EDT)
(envelope-from peter@retep.org.uk)
Received: from maidast.demon.co.uk ([158.152.22.37] helo=maidast.retep.org.uk)
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 11T8Y9-0007q5-0C; Mon, 20 Sep 1999 18:52:29 +0000
Received: from localhost (peter@localhost [127.0.0.1])
by maidast.retep.org.uk (8.9.3/8.9.3) with ESMTP id TAA01950;
Mon, 20 Sep 1999 19:50:43 +0100
Date: Mon, 20 Sep 1999 19:50:43 +0100 (GMT)
From: Peter Mount <peter@retep.org.uk>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Jan Wieck <wieck@debis.com>, Vadim Mikheev <vadim@krs.ru>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Status on Jan Wieck
In-Reply-To: <199909201739.NAA07187@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.9909201949470.28935-100000@maidast.retep.org.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 20 Sep 1999, Bruce Momjian wrote:
Bruce Momjian wrote:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Is he going to implement RI for 6.6?
Depends on WHEN 6.6 is planned to go into feature-freeze.
You tell us... We clearly could wait if you have some idea on a
timeframe. There has been no talk of a 6.6 release schedule yet. Vadim
is still working on logging, and Tom Lane is working too.
I want to get as much of the JDBC api done for 6.6 as well, so I think
there is going to be a lot of new stuff in it.
Peter
--
Peter T Mount peter@retep.org.uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf
From bouncefilter Mon Sep 20 15:01:36 1999
Received: from trends.net (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA23263
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 15:01:20 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by trends.net (8.8.8/8.8.8) with ESMTP id PAA26352
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 15:01:16 -0400 (EDT)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id OAA08883;
Mon, 20 Sep 1999 14:58:00 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909201858.OAA08883@candle.pha.pa.us>
Subject: Re: [PORTS] plpgsql & bsdi 4.0
In-Reply-To: <199909201822.OAA16477@spot.pupworks.com> from Nat Howard at "Sep
20, 1999 02:22:39 pm"
To: Nat Howard <nrh@pupworks.com>
Date: Mon, 20 Sep 1999 14:58:00 -0400 (EDT)
CC: Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Thanks -- I did a similar change, which had similar results.
I'm afraid I can't be of any help on the question of how
BSDI handles shared libraries. I don't currently have a support
contract with them, so I don't have a graceful "in" to ask them.I would say you have now duplicated the problem I was asking about,
and if someone can solve it, I'll be a very happy fella.Does the new patch make it work, or just fail in a different way?
Hmmm... I might have missed a message, but if by "the new patch" you
mean the patch that declares yyline in pl_comp.c, then the way to
put it is that I get the same failure you do: plpgsql regression
test fails with the same (or nearly the same) error message you
got. The only difference between our patches is that you got rid
of the "extern" in pl_comp.c and I did it in scan.l.
So, the remaining problem is to fix those errors. Now, it's possible
you sent "Bruce Patch #2", and I missed it. Did you?Or do you still have the error from the regression test shown above?
If you do, then there's still work to do, but if you don't, I missed
something -- please send it again!
OK, we tried the same thing, and got the same errors. Not sure about a
cause on this one. I am Cc'ing the author. Very strange. Does anyone
else see plpgsql regression failures?
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Wed Sep 29 05:45:36 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id FAA31207;
Wed, 29 Sep 1999 05:20:53 -0400 (EDT) (envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: "David Godin" <godind@REMOVE_THIS.voxco.com>
X-Newsgroups: comp.databases.postgresql.announce,
comp.databases.postgresql.bugs, comp.databases.postgresql.docs,
comp.databases.postgresql.hackers,
comp.databases.postgresql.interfaces,
comp.databases.postgresql.patches,
comp.databases.postgresql.ports, comp.databases
Subject: Installing PostgreSQL
Lines: 129
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0013_01BF0378.CD300B60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID: <fvvF3.295$I6.8383@typ12.nn.bcandid.com>
X-Trace: typ12.nn.bcandid.com 937854027 209.104.83.107 (Mon,
20 Sep 1999 15:00:27 EDT)
Date: Mon, 20 Sep 1999 14:59:55 -0400
To:
pgsql-hackers@postgresql.org.pgsql-announce@postgresql.org.pgsql-bugs@postgresql.org.pgsql-docs@postgresql.org.pgsql-interfaces@postgresql.org.pgsql-patches@postgresql.org.pgsql-ports@postgreSQL.org
This is a multi-part message in MIME format.
------=_NextPart_000_0013_01BF0378.CD300B60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi all,
This is the output of initdb after a clean install of all the 6.5.1-2 =
RPMs
I downloaded from ftp.postgreSQL.org. To install them I did an "rpm -ivh =
post*".
I'm using RedHat 6 on x86 with 64 Meg Ram and 300 Meg of HD space left.
=20
I used "initdb -l /usr/lib/pgsql -r /var/lib/pgsql/data -u postgres -d" =
to=20
initialyse the database (This is what they say in the manual).
Running with debug mode on.
initdb: using /usr/lib/pgsql/local1_template1.bki.source as input to =
create the template database.
initdb: using /usr/lib/pgsql/global1.bki.source as input to create the =
global classes.
initdb: using /usr/lib/pgsql/pg_hba.conf.sample as the host-based =
authentication control file.
We are initializing the database system with username postgres =
(uid=3D104).
This user will own all the files and must also own the server process.
Creating template database in /var/lib/pgsql/data/base/template1
Running: postgres -boot -C -F -D/var/lib/pgsql/data -d template1
initdb: could not create template database
initdb: cleaning up by wiping out /var/lib/pgsql/data/base/template1
This is a "ls -al /var/lib/pgsql"
total 4
drwx------ 3 postgres postgres 1024 Sep 20 14:09 .
drwxr-xr-x 15 root root 1024 Sep 17 11:07 ..
-rw-r--r-- 1 root root 35 Sep 1 00:55 odbcinst.ini
It's obvious i'm doing something wrong! Can someone help me?
David Godin
godind@REMOVE_THIS.voxco.com
------=_NextPart_000_0013_01BF0378.CD300B60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>This is the output of initdb after a =
clean install=20
of all the 6.5.1-2 RPMs</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I downloaded from ftp.postgreSQL.org. =
To install=20
them I did an "rpm -ivh post*".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D260052718-20091999>I'm =
using RedHat 6=20
on x86 with 64 Meg Ram and 300 Meg of HD space left.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I used "initdb -l /usr/lib/pgsql -r=20
/var/lib/pgsql/data -u postgres -d" to </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>initialyse the database (This is what =
they say in=20
the manual).</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Running with debug mode =
on.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>initdb: using=20
/usr/lib/pgsql/local1_template1.bki.source as input to create the =
template=20
database.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>initdb: using =
/usr/lib/pgsql/global1.bki.source as=20
input to create the global classes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>initdb: using =
/usr/lib/pgsql/pg_hba.conf.sample as=20
the host-based authentication control file.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>We are initializing the database system =
with=20
username postgres (uid=3D104).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>This user will own all the files and =
must also own=20
the server process.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Creating template database in=20
/var/lib/pgsql/data/base/template1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Running: postgres -boot -C -F =
-D/var/lib/pgsql/data=20
-d template1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>initdb: could not create template=20
database</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>initdb: cleaning up by wiping out=20
/var/lib/pgsql/data/base/template1</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>This is a "ls -al =
/var/lib/pgsql"</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>total 4</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>drwx------ 3 postgres postgres 1024 Sep =
20 14:09=20
.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>drwxr-xr-x 15 root root 1024 Sep 17 =
11:07=20
..</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>-rw-r--r-- 1 root root 35 Sep 1 00:55=20
odbcinst.ini</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>It's obvious i'm doing something wrong! =
Can someone=20
help me?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>David Godin</FONT></DIV><FONT =
face=3DArial>
<DIV><FONT size=3D2><A=20
href=3D"mailto:godind@REMOVE_THIS.voxco.com">godind@REMOVE_THIS.voxco.com=
</A></FONT></FONT></DIV></FONT></DIV></BODY></HTML>
------=_NextPart_000_0013_01BF0378.CD300B60--
From bouncefilter Mon Sep 20 16:07:24 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA32946
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 16:06:52 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id QAA10407
for pgsql-hackers@postgreSQL.org; Mon, 20 Sep 1999 16:06:45 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909202006.QAA10407@candle.pha.pa.us>
Subject: New TODO detail
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 20 Sep 1999 16:06:45 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have added a doc/TODO.detail directory that contains additional
information about TODO items.
The TODO list now has references to files in that directory.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 16:29:24 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA36454
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 16:29:22 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA78859;
Mon, 20 Sep 1999 17:27:15 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 17:27:15 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Leon <leon@udmnet.ru>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
In-Reply-To: <37E63B94.103BDE68@udmnet.ru>
Message-ID: <Pine.BSF.4.10.9909201717011.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 20 Sep 1999, Leon wrote:
Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
MySQL: 0.498u 0.150s 0:02.50 25.6% 10+1652k 0+0io 0pf+0w
PgSQL: 0.494u 0.061s 0:19.78 2.7% 10+1532k 0+0io 0pf+0w
From the 'time' numbers, MySQL is running ~17sec faster, but uses up 23%
more CPU to do this...so where is our slowdown?It's gotta be going into I/O, obviously. (I hate profilers that can't
count disk accesses...) My guess is that the index scans are losing
because they wind up touching too many disk pages. You showOn that particular machine that can be verified easily, I hope.
(there seems to be enough RAM). You can simply issue 10 to 100 such
queries in a row. Hopefully after the first query all needed info
will be in a disk cache, so the rest queries will not draw info from
disk. That will be a clean experiment.
With the server started as:
${POSTMASTER} -o "-F -o /usr/local/db/pgsql/errout -S 32768" \
-i -p 5432 -D/usr/local/db/pgsql/data -B 256 &
And with me being the only person on that system running against the
PostgreSQL database (ie. I don't believe the SI invalidation stuff comes
into play?), the time to run is the exact same each time:
1st run: 0.488u 0.056s 0:16.34 3.2% 10+1423k 0+0io 0pf+0w
2nd run: 0.500u 0.046s 0:16.34 3.3% 10+1517k 0+0io 0pf+0w
3rd run: 0.496u 0.049s 0:16.33 3.2% 9+1349k 0+0io 0pf+0w
4th run: 0.487u 0.056s 0:16.32 3.2% 14+1376k 0+0io 0pf+0w
Note that the results fed back are *exactly* the same each time...the
data is static, as its purely a test database...
I believe that I have the buffers set "Abnormally high", as well as have
provided more then sufficient sort buffer space...
Using the 'optimized' query, that uses subselects, the runs are similar:
1st run: 0.467u 0.031s 0:08.26 5.9% 15+1345k 0+0io 0pf+0w
2nd run: 0.475u 0.023s 0:08.29 5.9% 15+1384k 0+0io 0pf+0w
3rd run: 0.468u 0.031s 0:08.28 5.9% 10+1325k 0+0io 0pf+0w
4th run: 0.461u 0.031s 0:08.31 5.8% 10+1362k 0+0io 0pf+0w
Time is cut in half, CPU usage goes up a bit...but all runs are pretty
much the same...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 17:19:19 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA45037
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 17:18:29 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA79212;
Mon, 20 Sep 1999 18:16:41 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 18:16:40 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
In-Reply-To: <27362.937756381@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9909201732040.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 19 Sep 1999, Tom Lane wrote:
How many tuples *does* your test query produce, anyway? If you
Depends on what it is fed...could be 270 records returned, could be
5...depends on the values of catid, indid and divid...
eliminate all the joining WHERE-clauses and just consider the
restriction clauses for each of the tables, how many tuples?
In other words, what do you get fromSELECT count(*)
FROM aecEntMain a
WHERE (a.id=??? AND a.mid=???)
AND (a.status like 'active%')
AND (a.status like '%active:ALL%')
AND (a.representation like '%:ALL%');
Returns 1 ...
SELECT count(*)
FROM aecWebEntry b
WHERE (b.status like 'active%')
AND (b.status like '%active:ALL%')
AND (b.indid=? and b.divid=? and b.catid=?);
This one I get 39 ...
(In the first of these, substitute a representative id/mid pair from
table b for the ???, to simulate what will happen in any one iteration
of the inner scan over table a.) Also, how many rows in each table?
aec=> select count(*) from aecEntMain;
count
-----
16560
(1 row)
aec=> select count(*) from aecWebEntry;
count
-----
58316
(1 row)
By doing a 'select distinct id from aecWebEntry', there are 16416 distinct
id's in aecWebEntry, and 16493 distinct id's in aecEntMain, so I'm
guessing that its supposed to be a 1->N relationship between the two
tables...therefore, again, I'm guessing, but the first query above shoudl
never return more then 1 record...
If I run both queries together, as:
SELECT distinct b.indid, b.divid, b.catid, a.id, a.mid
FROM aecEntMain a, aecWebEntry b
WHERE (a.id=b.id AND a.mid=b.mid)
AND (a.status like 'active%' and b.status like 'active%')
AND (a.status like '%active:ALL%' and b.status like '%active:ALL%')
AND (a.representation like '%:ALL%')
AND (b.indid='000001' and b.divid='100016' and b.catid='100300');
The result, in this case, is 39 records...if I change b.catid to be '100400',
its only 35 records, etc...
Does this help? The server isn't live, so if you want me to enable some
debugging, or play with something, its not going to affect anything...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 17:27:19 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA46375
for <pgsql-hackers@postgresql.org>;
Mon, 20 Sep 1999 17:27:09 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA79292;
Mon, 20 Sep 1999 18:27:09 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 18:27:09 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Mike Mascari <mascarim@yahoo.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [6.5.2] join problems ...
In-Reply-To: <19990919071724.20897.rocketmail@web119.yahoomail.com>
Message-ID: <Pine.BSF.4.10.9909201822050.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Comparing my original query against yours, idle machine:
Mine: 0.000u 0.023s 0:07.78 0.2% 48+132k 0+0io 0pf+0w (55 rows)
Your: 0.006u 0.018s 0:12.16 0.0% 408+904k 0+0io 0pf+0w (55 rows)
Takes longer to run, less CPU resources, but, if I'm reading this right,
more memory resources?
On Sun, 19 Sep 1999, Mike Mascari wrote:
The query you've presented is rather convoluted, but
if I'm reading your query correctly, it should reduce
to a simple, three-way join:SELECT c.id, c.name, c.url
FROM aecEntMain a, aecWebEntry b, aecCategory c
WHERE a.status LIKE 'active:ALL%'
AND a.representation LIKE '%:ALL%'
AND b.status LIKE 'active:ALL%'
AND b.indid='$indid'
AND b.divid='$divid'
AND (a.id,a.mid = b.id,b.mid)
AND (b.catid,b.indid,b.divid = c.id,c.ppid,c.pid);with the following indexes:
aecEntMain: (status) and (id,mid)
aecWebEntry: (status), (indid), (divid), and
(catid,indid,divid)
aecCategory: (id,ppid,pid)Now, there are some differences between the above and
what you wrote. For example, the above requires that
the status begins with 'active:ALL'. Your query
requires the status begin with 'active' and must also
contain the pattern 'active:ALL'. So for the above
to be equivalent, you can't have a status such as
'active <some stuff> active:ALL'.With respect to subqueries and PostgreSQL, as you
know, the IN clause requires a nested scan. If you
are going to use subqueries, correlated subqueries
using EXISTS clauses can use indexes:SELECT c.id, c.name, c.url
FROM aecCategory c
WHERE EXISTS (
SELECT a.status
FROM aecEntMain a, aecWebEntry b
WHERE a.status LIKE 'active:ALL%'
AND a.representation LIKE '%:ALL%'
AND b.status LIKE 'active:ALL%'
AND b.indid='$indid'
AND b.divid='$divid'
AND (a.id,a.mid = b.id,b.mid)
AND (b.catid,b.indid,b.divid = c.id,c.ppid,c.pid));Unfortunately, the lack of index support in IN
subqueries affects more than just the IN subquery
clause, since INTERSECT/EXCEPT uses the rewriter to
rewrite such queries as UNIONS of two queries with
an IN/NOT IN subquery, respectively. This makes the
INTERSECT/EXCEPT feature functionally useless except
on very small tables.Hope that helps (and is equivalent),
Mike Mascari (mascarim@yahoo.com)
--- The Hermit Hacker <scrappy@hub.org> wrote:Morning...
This weekend, up at a clients site working with
them on improving
database performance. They are currently running
MySQL and I'm trying to
convince them to switch over to PostgreSQL, for
various features that they
just don't have with MySQL...One of the 'queries' that they are currently doing
with MySQL
consists of two queries that I can reduce down to
one using subqueries,
but its so slow that its ridiculous...so I figured
I'd throw it out as a
problem to hopefully solve?The query I'm starting out with is works out as:
SELECT id, name, url \
FROM aecCategory \
WHERE ppid='$indid' \
AND pid='$divid'";The results of this get fed into a while look that
takes the id
returned and pushes them into:SELECT distinct b.indid, b.divid, b.catid,
a.id, a.mid \
FROM aecEntMain a, aecWebEntry b \
WHERE (a.id=b.id AND a.mid=b.mid) \
AND (a.status like 'active%' and b.status
like 'active%')
AND (a.status like '%active:ALL%' and
b.status like '%active:ALL%')
AND (a.representation like '%:ALL%')
AND (b.indid='$indid' and
b.divid='$divid' and b.catid='$catid')";Now, I can/have rewritten this as:
SELECT id, name, url
FROM aecCategory
WHERE ppid='$indid'
AND pid='$divid'
AND id IN (
SELECT distinct c.id
FROM aecEntMain a, aecWebEntry b, aecCategory c
WHERE (a.id=b.id AND a.mid=b.mid and b.catid=c.id)
AND (a.status like 'active%' and b.status like
'active%')
AND (a.status like '%active:ALL%' and b.status
like '%active:ALL%')
AND (a.representation like '%:ALL%')
AND (b.indid='$indid' and b.divid='$divid' and
b.catid IN (
SELECT id FROM aecCategory WHERE
ppid='$indid' AND pid='$divid' )
));";An explain of the above shows:
Index Scan using aeccategory_primary on aeccategory
(cost=8.28 rows=1 width=36)
SubPlan
-> Unique (cost=1283.70 rows=21 width=72)
-> Sort (cost=1283.70 rows=21 width=72)
-> Nested Loop (cost=1283.70 rows=21
width=72)
-> Nested Loop (cost=1280.70 rows=1
width=60)
-> Index Scan using aecwebentry_primary
on aecwebentry b
(cost=1278.63 rows=1 width=36)
SubPlan
-> Index Scan using
aeccategory_primary on aeccategory
(cost=8.28 rows=1
width=12)
-> Index Scan using aecentmain_primary on
aecentmain a
(cost=2.07 rows=348 width=24)
-> Index Scan using aeccategory_id on
aeccategory c
(cost=3.00 rows=1170 width=12)Now, a few things bother me with the above explain
output, based on me
hopefully reading this right...The innermost SubPlan reports an estimated rows
returned of 1...the
actual query returns 59 rows...slightly off?The one that bothers me is the one that reports
1170 rows returned...if you
look at the query, the only thing that would/should
use aeccategory_id is the
line that goes "SELECT distinct c.id"...if I run
just that section of the
query, it yields a result of 55 rows...way off??All of my queries are currently on static data,
after a vacuum analyze has
been performed...everything is faster if I split
things up and do a SELECT
on a per id basis on return values, but, as the list
of 'ids' grow, the
number of iterations of the while loop required will
slow down the query...I'm not sure what else to look at towards
optimizing the query further,
or is this something that we still are/need to look
at in the server itself?The machine we are working off of right now is an
idle Dual-PIII 450Mhz with
512Meg of RAM, very fast SCSI hard drives on a UW
controller...and that query
is the only thing running while we test things...so
we aren't under-powered :)ideas?
Marc G. Fournier ICQ#7615664
IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary:
scrappy@{freebsd|postgresql}.org__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 17:29:31 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA46671
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 17:29:23 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA79296;
Mon, 20 Sep 1999 18:29:09 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 18:29:09 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Jan Wieck <wieck@debis.com>
cc: Vadim Mikheev <vadim@krs.ru>, maillist@candle.pha.pa.us,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Status on Jan Wieck
In-Reply-To: <m11T6kX-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.BSF.4.10.9909201828010.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 20 Sep 1999, Jan Wieck wrote:
Bruce Momjian wrote:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Is he going to implement RI for 6.6?
Depends on WHEN 6.6 is planned to go into feature-freeze.
After you implement RI? :) Since we've gone the -STABLE branch
fixes/releases route, 6.6 is less of a panic, so if you have some sort of
a timeline for this, its *very* easy to work around it :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 17:33:19 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA47376
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 17:32:55 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA79348;
Mon, 20 Sep 1999 18:30:56 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 18:30:56 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development@candle.pha.pa.us,
pgsql-hackers@postgreSQL.org, Jan Wieck <jwieck@debis.com>
Subject: Re: [HACKERS] Status on Jan Wieck
In-Reply-To: <199909201532.LAA03910@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909201830270.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 20 Sep 1999, Bruce Momjian wrote:
Bruce Momjian <maillist@candle.pha.pa.us> writes:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Good ... I was starting to fear he'd been run over by a truck or
something :-(Does he have any idea when/if he'll return to Postgres hacking?
That brings up another issue.
Why do people think programmers are throwing themselves in front of
trucks? Any idea? I hear it often.
Few of us get the window office on a high enough floor to jump? :) Those
are reserved for the accountants and stock brokers :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 17:35:19 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA47649
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 17:34:57 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA79366;
Mon, 20 Sep 1999 18:32:50 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 18:32:50 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Brook Milligan <brook@biology.nmsu.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pgaccess seems a tad confused]
In-Reply-To: <199909180135.VAA02912@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909201832150.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 17 Sep 1999, Bruce Momjian wrote:
Bruce Momjian <maillist@candle.pha.pa.us> writes:
More importantly, though, any bugs in the Makefile or
whatever will be noticed early by developers and won't wait until the
last moment. Since the basic installation scheme likely doesn't
depend much on the exact pgaccess release, there really isn't much to
be lost by keeping it in the development tree.It is in the development tree, just not the most recent version.
But the point is, if the most recent version had been in the development
tree, we'd have had a better shot at noticing that its makefile was
missing...I guess. The new pgaccess release was so different than the current
one, I just cvs removed all files, and readded everything. That is how
Makefile go lost.
Ewwww...so, like, we lost the 'history' of the files that only changed vs
were new? *raised eyebrow*
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 17:39:25 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA48412
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 17:39:21 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA79431;
Mon, 20 Sep 1999 18:36:32 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 18:36:32 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Lamar Owen <lamar.owen@wgcr.org>,
Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <199909182138.RAA19904@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909201835240.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 18 Sep 1999, Bruce Momjian wrote:
I have been thinking, the destroy should be drop, in keeping with SQL.
destroy was a QUEL'ism.
{create,destroy}{user,db} should be drop'd, personally...admins should use
the SQL commands directly...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 17:41:19 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA48872
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 17:40:38 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA79438;
Mon, 20 Sep 1999 18:40:45 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 18:40:45 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Michael Simms <grim@argh.demon.co.uk>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Command Locations (was Re: HISTORY for 6.5....)
In-Reply-To: <199909192054.QAA03329@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909201839580.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 19 Sep 1999, Bruce Momjian wrote:
One idea, which takes into account the thought that moving the admin commands
out of /usr/bin is a good thing, but moving them into /usr/sbin is bad, and
we want to keep it simple for new people.I assume this is only an RPM discussion. All third party stuff should
go in /usr/local I think.
I can't agree more...I like things going into /usr/local/pgsql by
default...
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 17:51:44 1999
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA51105
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 17:50:23 -0400 (EDT) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id BAA25507
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 01:50:19 +0400 (MSD)
Date: Tue, 21 Sep 1999 01:50:19 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: pgsql-hackers@postgreSQL.org
Subject: create table and default 'now' problem ?
Message-ID: <Pine.GSO.3.96.SK.990921014729.24490A-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
how I could create table with datetime field default to 'now'::text in
a way Jan did in his shoes rule example ?
If I do:
test=> create table test ( a datetime default 'now', b int4);
CREATE
test=> insert into test (b) values (1);
INSERT 1677899 1
test=> insert into test (b) values (2);
INSERT 1677900 1
test=> select * from test;
a |b
----------------------------+-
Tue 21 Sep 01:48:27 1999 MSD|1
Tue 21 Sep 01:48:27 1999 MSD|2
(2 rows)
I always get datetime of the moment I created the table, but I'd like
to have datetime of moment I insert.
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From bouncefilter Mon Sep 20 18:10:19 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA54481
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 18:09:32 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id SAA16351;
Mon, 20 Sep 1999 18:06:29 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909202206.SAA16351@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess seems a tad confused]
In-Reply-To: <Pine.BSF.4.10.9909201832150.66830-100000@thelab.hub.org> from
The
Hermit Hacker at "Sep 20, 1999 06:32:50 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 20 Sep 1999 18:06:29 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Brook Milligan <brook@biology.nmsu.edu>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I guess. The new pgaccess release was so different than the current
one, I just cvs removed all files, and readded everything. That is how
Makefile go lost.Ewwww...so, like, we lost the 'history' of the files that only changed vs
were new? *raised eyebrow*
Yes, thought the pgaccess file was kept I think. I just checked, and
somehow the pgaccess files are not in the stable tree anymore, just the
directories.
I got the final version <24 hours from release. It was in my tree, but
now it isn't, and it isn't in 6.5.2 either.
I asked for the author to verify my work. I am adding it to the tree
now. What do we do?
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 18:18:25 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id SAA55788
for <pgsql-hackers@postgresql.org>;
Mon, 20 Sep 1999 18:18:12 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 11586 invoked by uid 1001); 20 Sep 1999 22:18:15 -0000
Message-ID: <XFMail.990920181815.vev@michvhf.com>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.BSF.4.10.9909201835240.66830-100000@thelab.hub.org>
Date: Mon, 20 Sep 1999 18:18:15 -0400 (EDT)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Lamar Owen <lamar.owen@wgcr.org>,
Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
On 20-Sep-99 The Hermit Hacker wrote:
On Sat, 18 Sep 1999, Bruce Momjian wrote:
I have been thinking, the destroy should be drop, in keeping with SQL.
destroy was a QUEL'ism.{create,destroy}{user,db} should be drop'd, personally...admins should use
the SQL commands directly...
I think it'd be better if they were kept. They're really convenient for
the newbie (I just introduced someone to PostgreSQL and all the way thru
were references to MySQL, including the create user, db, etc. scripts).
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Mon Sep 20 18:30:39 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA58119
for <pgsql-hackers@postgresql.org>;
Mon, 20 Sep 1999 18:29:48 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id TAA79911;
Mon, 20 Sep 1999 19:26:30 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 19:26:29 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Vince Vielhaber <vev@michvhf.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Lamar Owen <lamar.owen@wgcr.org>,
Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <XFMail.990920181815.vev@michvhf.com>
Message-ID: <Pine.BSF.4.10.9909201925341.38923-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 20 Sep 1999, Vince Vielhaber wrote:
On 20-Sep-99 The Hermit Hacker wrote:
On Sat, 18 Sep 1999, Bruce Momjian wrote:
I have been thinking, the destroy should be drop, in keeping with SQL.
destroy was a QUEL'ism.{create,destroy}{user,db} should be drop'd, personally...admins should use
the SQL commands directly...I think it'd be better if they were kept. They're really convenient for
the newbie (I just introduced someone to PostgreSQL and all the way thru
were references to MySQL, including the create user, db, etc. scripts).
My personal dislike for them is that they are incomplete...CREATE USER and
CREATE DATABASE have a helluva lot of options available to it...using
createuser, you don't know/learn abotu them...
Force the admin to learn what they are doing...if they want to create
short cut scripts, let *them* do it...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 18:32:25 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA58888
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 18:32:17 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id TAA79953;
Mon, 20 Sep 1999 19:29:49 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 19:29:49 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Brook Milligan <brook@biology.nmsu.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pgaccess seems a tad confused]
In-Reply-To: <199909202206.SAA16351@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909201917340.38923-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 20 Sep 1999, Bruce Momjian wrote:
I guess. The new pgaccess release was so different than the current
one, I just cvs removed all files, and readded everything. That is how
Makefile go lost.Ewwww...so, like, we lost the 'history' of the files that only changed vs
were new? *raised eyebrow*Yes, thought the pgaccess file was kept I think. I just checked, and
somehow the pgaccess files are not in the stable tree anymore, just the
directories.I got the final version <24 hours from release. It was in my tree, but
now it isn't, and it isn't in 6.5.2 either.I asked for the author to verify my work. I am adding it to the tree
now. What do we do?
Okay, am very confused here...just did:
cvs checkout -rREL6_5_PATCHES -P pgsql/src/bin/pgaccess
it extracted 243 files...
cvs status Makefile
===================================================================
File: Makefile Status: Up-to-date
Working revision: 1.1.4.2
Repository revision: 1.1.4.2 /usr/local/cvsroot/pgsql/src/bin/pgaccess/Makefile,v
Sticky Tag: REL6_5_PATCHES (branch: 1.1.4)
Sticky Date: (none)
Sticky Options: (none)
I just performed the same on the same on the non-'-r' tree, and now see
what you mean :(
I should be able to fix this momentarily...I hope...
Its all a learning less...assuming you know what you've learnt? :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 18:37:20 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA59984
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 18:36:55 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id SAA23961;
Mon, 20 Sep 1999 18:35:08 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909202235.SAA23961@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess seems a tad confused]
In-Reply-To: <Pine.BSF.4.10.9909201917340.38923-100000@thelab.hub.org> from
The
Hermit Hacker at "Sep 20, 1999 07:29:49 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 20 Sep 1999 18:35:08 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Brook Milligan <brook@biology.nmsu.edu>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I am totally confused, but have added the missing files.
On Mon, 20 Sep 1999, Bruce Momjian wrote:
I guess. The new pgaccess release was so different than the current
one, I just cvs removed all files, and readded everything. That is how
Makefile go lost.Ewwww...so, like, we lost the 'history' of the files that only changed vs
were new? *raised eyebrow*Yes, thought the pgaccess file was kept I think. I just checked, and
somehow the pgaccess files are not in the stable tree anymore, just the
directories.I got the final version <24 hours from release. It was in my tree, but
now it isn't, and it isn't in 6.5.2 either.I asked for the author to verify my work. I am adding it to the tree
now. What do we do?Okay, am very confused here...just did:
cvs checkout -rREL6_5_PATCHES -P pgsql/src/bin/pgaccess
it extracted 243 files...
cvs status Makefile
===================================================================
File: Makefile Status: Up-to-dateWorking revision: 1.1.4.2
Repository revision: 1.1.4.2 /usr/local/cvsroot/pgsql/src/bin/pgaccess/Makefile,v
Sticky Tag: REL6_5_PATCHES (branch: 1.1.4)
Sticky Date: (none)
Sticky Options: (none)I just performed the same on the same on the non-'-r' tree, and now see
what you mean :(I should be able to fix this momentarily...I hope...
Its all a learning less...assuming you know what you've learnt? :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 18:54:33 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA62715;
Mon, 20 Sep 1999 18:53:47 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from lowen.wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id SAA12129;
Mon, 20 Sep 1999 18:53:55 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: pgsql-hackers@postgresql.org, pgsql-ports@postgresql.org,
lockhart@alumni.caltech.edu, jbjj@redhat.com, gafton@redhat.com
Subject: PostgreSQL 6.5.2 RPMS available.
Date: Mon, 20 Sep 1999 18:35:57 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99092018533204.00568@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit
RPM's for RedHat are now available at http://www.ramifordistat.net/postgres
Source RPMS are in SRPMS.beta, and i386 binaries are in RPMS.beta. I do still
consider these RPM's beta quality -- while the code seems solid and correct for
the upgrading, it hasn't been tested on enough machines to say it's past beta
quailty.
These RPM's, like their 6.5.1-0.7lo ancestors, respond correctly and sanely to
'rpm -U'. While it may seem like overkill to release 6.5.1-0.7lo Saturday, and
6.5.2-0.2lo today, it was necessary. It certainly seems like overkill to
maintain both the 6.5.1 and 6.5.2 RPM's concurrently, but it is also necessary
given the situation. Look for 6.5.1-0.8lo, that incorporates the non-6.5.2
changes of the 6.5.2-0.2lo rpms) in a few days, unless I get word from RedHat to
do otherwise.
Binary RPM's are available now for RedHat 6.0/Intel (kernel 2.2.5, glibc 2.1.1,
egcs 1.1.2). Binary RPM's will be available in a couple of hours for RedHat
5.2/Intel (kernel 2.0.36, glibc 2.0.7, gcc 2.7.2).
6.5.2-0.2lo contains Ryan Kirkpatrick's packaging of the Alpha patches
originally put together by Uncle George.
There have been a few other changes other than the uprev to 6.5.2. Bang on
this one, guys. I'll be interested in seeing Alpha results for these.
As always, send me mail about any difficulties you find. Please cc: Thomas
Lockhart <lockhart@alumni.caltech.edu> on any e-mail to me about these RPM's.
Changelog:
%changelog
* Mon Sep 20 1999 Lamar Owen <lamar.owen@wgcr.org>
- 6.5.2-0.2lo
- Upgrade to 6.5.2
- Add some versioning to the init script -- source is postgresql.init.VERSION
- Added some intelligence to init script
- Cleaned up the migration script packaging -- now in a tarball
- Consolidated some patches
- Added the JDK 1.2 JDBC jar to the existing JDK1.1 jar.
- Corrected goof in postgresql package description -- it still referred to the -data
-- subpackage.
* Sat Sep 18 1999 Lamar Owen <lamar.owen@wgcr.org>
- 0.7lo
- First stab at integrating modified versions of the Debian migration scripts.
-- Courtesy Oliver Elphick, Debian package maintainer, PostgreSQL Global
-- Development Group.
- /usr/lib/pgsql/backup/pg_dumpall_new -- a modifed pg_dumpall used in the
-- migration -- modified to work with the older executables.
- /usr/bin/postgresql_dump -- the migration script.
- Upgrade strategy:
-- 1.) %pre for main package saves old package's executables
-- 2.) the postgresql init script in -server detects PGDATA existence
-- and version, notifies user if upgrade is necessary
-- 3.) Rather than fully automating upgrade, the tools are provided:
-- a.) /usr/bin/postgresql_dump
-- b.) /usr/lib/pgsql/backup/pg_dumpall_new
-- c.) The executables backed up by %pre in /usr/lib/pgsql/backup
-- 4.) Documentation on RPM differences and upgrades in README.rpm
-- 5.) A fully automatic upgrade can be facilitated by some more code
-- in /etc/rc.d/init.d/postgresql, if desired.
- added documentation for rpm setup, and upgrade (README.rpm)
- added newer man pages from Thomas Lockhart
- Put the PL's in the right place -- /usr/lib/pgsql, not /usr/lib. My error.
- Added Requires: postgresql = %{version} for all sub packages.
- Need to reorganize sources in next release, as the current number of source
-- files is a little large.
* Tue Sep 07 1999 Cristian Gafton <gafton@redhat.com>
- upgraded pgaccess to the latest 0.98 stable version
- fix braindead pgaccess installation and add pgaccess dosucmenattaion to
the package containing pgaccess rather than main package
- add missing templates tp the /usr/lib/pgsql directory
- added back the PostgreSQL howto (I wish people will STOP removing
documentation from this package!)
- get rid of the perl handling overkill (what the hell was that needed for?)
- "chkconfig --del" should be done in the server package, not the main
package
- make server packeg own only /etc/rc.d/init.d/postgresql, not the whole
/etc/rc.d (doh!)
- don't ship OS2 executable client as documenatation...
- if we have a -tcl subpackage, make sure that other packages don't need tcl
anymore by moving tcl-dependent binaries in the -tcl package... [pltcl.so]
- if we are using /sbin/chkconfig we don't need the /etc/rc.d/rc?.d symlinks
* Sat Sep 4 1999 Jeff Johnson <jbj@redhat.com>
- use _arch not (unknown!) buildarch macro (#4913).
* Fri Aug 20 1999 Jeff Johnson <jbj@redhat.com>
- obsolete postgres-clients (not conflicts).
* Thu Aug 19 1999 Jeff Johnson <jbj@redhat.com>
- add to Red Hat 6.1.
* Wed Aug 11 1999 Lamar Owen <lamar.owen@wgcr.org>
- Release 3lo
- Picked up pgaccess README.
- Built patch set for rpm versus tarball idiosyncrasies:
-- munged some paths in the regression tests (_OBJWD_), trigger functions
-- munged USER for regression tests.
-- Added perl and python examples -- required patching the shebang to drop
-- local in /usr/local/bin
- Changed rc.d level from S99 to S75, as there are a few server daemons that
-- might actually need to load AFTER pgsql -- AOLserver is an example.
- config.guess included in server package by default -- used by regress tests.
- Preliminary test subpackage, containing entire src/test tree.
- Prebuild of binaries in the test subpackage.
- Added pgaccess-0.97 beta as /usr/bin/pgaccess97 for testing
- Removed the DATABASE-HOWTO; it was SO old, and the newer release of it
-- is a stock part of the RedHat HOWTOS package.
- Put in the RIGHT postgresql.init ('/etc/rc.d/init.d/postgresql')
- Noted that the perl client is operational.
* Fri Aug 6 1999 Lamar Owen <lamar.owen@wgcr.org>
- Release 2lo
- Added alpha patches courtesy Ryan Kirkpatrick and Uncle George
- Renamed lamar owen series of RPMS with release of #lo
- Put Ramifordistat as vendor and URL for lamar owen RPM series, until non-beta
-- release coordinated with PGDG.
* Mon Jul 19 1999 Lamar Owen <lamar.owen@wgcr.org>
- Correct some file misappropriations:
-- /usr/lib/pgsql was in wrong package
-- createlang, destroylang, and vacuumdb now in main package
-- ipcclean now in server subpackage
-- The static libraries are now in the devel subpackage
-- /usr/lib/plpgsql.so and /usr/lib/pltcl.so now in server
- Cleaned up some historical artifacts for readability -- left references
- to these artifacts in the changelog
* Sat Jun 19 1999 Thomas Lockhart <lockhart@alumni.caltech.edu>
- deprecate clients rpm, and define a server rpm for the backend
- version 6.5
- updated pgaccess to version 0.96
- build ODBC interface library
- split tcl and ODBC packages into separate binary rpms
* Sat Apr 17 1999 Jeff Johnson <jbj@redhat.com>
- exclude alpha for Red Hat 6.0.
* Sun Mar 21 1999 Cristian Gafton <gafton@redhat.com>
- auto rebuild in the new build environment (release 2)
* Wed Feb 03 1999 Cristian Gafton <gafton@redhat.com>
- version 6.4.2
- get rid of the -data package (shipping it was a BAD idea)
* Sat Oct 10 1998 Cristian Gafton <gafton@redhat.com>
- strip all binaries
- use defattr in all packages
- updated pgaccess to version 0.90
- /var/lib/pgsql/pg_pwd should not be 666
* Sun Jun 21 1998 Jeff Johnson <jbj@redhat.com>
- create /usr/lib/pgsql (like /usr/include/pgsql)
- resurrect libpq++.so*
- fix name problem in startup-script (problem #533)
* Fri Jun 19 1998 Jeff Johnson <jbj@redhat.com>
- configure had "--prefix=$RPM_BUILD_ROOT/usr"
- move all include files below /usr/include/pgsql.
- resurrect perl client file lists.
* Tue May 05 1998 Prospector System <bugs@redhat.com>
- translations modified for de, fr, tr
* Tue May 05 1998 Cristian Gafton <gafton@redhat.com>
- build on alpha
* Sat May 02 1998 Cristian Gafton <gafton@redhat.com>
- enhanced initscript
* Tue Apr 21 1998 Cristian Gafton <gafton@redhat.com>
- finally v6.3.2 is here !
* Wed Apr 15 1998 Cristian Gafton <gafton@redhat.com>
- added the include files in the devel package
* Wed Apr 01 1998 Cristian Gafton <gafton@redhat.com>
- finally managed to get a patch for 6.3.1 to make it install corectly. Boy,
what a mess ! ;-(
* Tue Mar 03 1998 Cristian Gafton <gafton@redhat.com>
- upgraded tp 6.3 release
* Sat Feb 28 1998 Cristian Gafton <gafton@redhat.com>
- upgraded to the latest snapshot
- splitted yet one more subpackage: clients
* Tue Jan 20 1998 Cristian Gafton <gafton@redhat.com>
- the installed devel-library is no longer stripped (duh!)
- added the 7 patches found on the ftp.postgresql.org site
- corrected the -rh patch to patch configure.in rather than configure; we
now use autoconf
- added a patch to fix the broken psort function
- build TCL and C++ libraries as well
- updated pgaccess to version 0.76
* Thu Oct 23 1997 Cristian Gafton <gafton@redhat.com>
- cleaned up the spec file for version 6.2.1
- splited devel subpackage
- added chkconfig support in %preun and %post
- added optional data package
* Mon Oct 13 1997 Elliot Lee <sopwith@cuc.edu> 6.2-3
- Fixed lots of bung-ups in the spec file, made it FSSTND compliant, etc.
- Removed jdbc package, jdk isn't stable yet as far as what goes where.
- Updated to v 6.2.1
* Thu Oct 9 1997 10:58:14 dan
- on pre-installation script now the `data' dir is renamed to
`data.rpmorig' (no more wild deletions!).
- added `postgresql-jdbc' sub-package.
- postgresql.sh script: defined function `add_to_path()' and
changed the location of postgresql.jar in the CLASSPATH.
* Sat Oct 4 1997 10:27:43 dan
- updated to version 6.2.
- added auto installation's scripts (pre, post, preun, postun)
-----------------------------------------------------------------------------
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Mon Sep 20 18:50:20 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA62062
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 18:49:50 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id SAA24091;
Mon, 20 Sep 1999 18:46:33 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909202246.SAA24091@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <Pine.BSF.4.10.9909201925341.38923-100000@thelab.hub.org> from
The
Hermit Hacker at "Sep 20, 1999 07:26:29 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 20 Sep 1999 18:46:33 -0400 (EDT)
CC: Vince Vielhaber <vev@michvhf.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Lamar Owen <lamar.owen@wgcr.org>, Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
My personal dislike for them is that they are incomplete...CREATE USER and
CREATE DATABASE have a helluva lot of options available to it...using
createuser, you don't know/learn abotu them...Force the admin to learn what they are doing...if they want to create
short cut scripts, let *them* do it...
But newbies can't do shortcuts. I think we need to keep it.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 18:49:20 1999
Received: from kla-tencor.com (mail01.kla-tencor.com [206.67.220.38])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA62010
for <pgsql-hackers@postgresql.org>;
Mon, 20 Sep 1999 18:49:05 -0400 (EDT)
(envelope-from yucao@falcon.kla-tencor.com)
Received: from jedi.kla-tencor.com by kla-tencor.com (8.8.5/KLA-Tencor.3.6ir)
id PAA01267; Mon, 20 Sep 1999 15:48:34 -0700 (PDT)
Received: from localhost (yucao@localhost)
by jedi.kla-tencor.com (8.9.1b+Sun/8.9.1) with SMTP id PAA22088
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 15:47:32 -0700 (PDT)
X-Authentication-Warning: jedi.kla-tencor.com: yucao owned process doing -bs
Date: Mon, 20 Sep 1999 15:47:16 -0700 (PDT)
From: Yu Cao <yucao@falcon.kla-tencor.com>
X-Sender: yucao@jedi.kla-tencor.com
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <Pine.BSF.4.10.9909201925341.38923-100000@thelab.hub.org>
Message-ID: <Pine.SOL.3.96.990920154145.22085A-100000@jedi.kla-tencor.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I think I can safely speak for a newbie and I happen to dislike
createdb etc as well. I started out with postgreSQL with the
intention of writing an application-specific CORBA front-end
to it, so I cared most about the C++ interface. The existence of
the createdb command confused me for a while, leaving me thinking
I could do INSERT and SELECT etc from libpq++, but would have
to resort to UNIX calls to do createdb.
--Yu Cao
On Mon, 20 Sep 1999, The Hermit Hacker wrote:
On Mon, 20 Sep 1999, Vince Vielhaber wrote:
On 20-Sep-99 The Hermit Hacker wrote:
On Sat, 18 Sep 1999, Bruce Momjian wrote:
I have been thinking, the destroy should be drop, in keeping with SQL.
destroy was a QUEL'ism.{create,destroy}{user,db} should be drop'd, personally...admins should use
the SQL commands directly...I think it'd be better if they were kept. They're really convenient for
the newbie (I just introduced someone to PostgreSQL and all the way thru
were references to MySQL, including the create user, db, etc. scripts).My personal dislike for them is that they are incomplete...CREATE USER and
CREATE DATABASE have a helluva lot of options available to it...using
createuser, you don't know/learn abotu them...Force the admin to learn what they are doing...if they want to create
short cut scripts, let *them* do it...
From bouncefilter Mon Sep 20 19:04:20 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA64542
for <pgsql-hackers@postgresql.org>;
Mon, 20 Sep 1999 19:04:07 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from lowen.wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id TAA12147;
Mon, 20 Sep 1999 19:00:58 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Bruce Momjian <maillist@candle.pha.pa.us>,
The Hermit Hacker <scrappy@hub.org>
Subject: Re: [HACKERS] pgaccess seems a tad confused]
Date: Mon, 20 Sep 1999 18:50:12 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Brook Milligan <brook@biology.nmsu.edu>,
pgsql-hackers@postgresql.org
References: <199909202206.SAA16351@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <99092019003505.00568@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit
On Mon, 20 Sep 1999, Bruce Momjian wrote:
I got the final version <24 hours from release. It was in my tree, but
now it isn't, and it isn't in 6.5.2 either.I asked for the author to verify my work. I am adding it to the tree
now. What do we do?
Either make a 6.5.3, inline 6.5.2 (6.5.2a, anyone??) or leave 6.5.2 as is.
None is ideal -- although a 6.5.3 is better than a badly broken 6.5.2. The
short term solution is for those using 6.5.2 to download the pgaccess-0.98
tarball from flex.ro.
I ran across the depopulated pgaccess tree this morning while starting the
build cycle for the 6.5.2 rpms -- good thing I have already dealt with that
issue with previous packages. For the RPM's, it has been practice for some time
to include the very latest pgaccess as a separate tarball, then untarring it
over top of the one in the main tarball during the package build. I was hoping
to get away from that. ;-(
-----------------------------------------------------------------------------
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Mon Sep 20 19:05:27 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA65000
for <pgsql-hackers@postgresql.org>;
Mon, 20 Sep 1999 19:05:22 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id TAA24656;
Mon, 20 Sep 1999 19:03:09 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909202303.TAA24656@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess seems a tad confused]
In-Reply-To: <99092019003505.00568@lowen.wgcr.org> from Lamar Owen at "Sep 20,
1999 06:50:12 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Mon, 20 Sep 1999 19:03:09 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
Brook Milligan <brook@biology.nmsu.edu>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Mon, 20 Sep 1999, Bruce Momjian wrote:
I got the final version <24 hours from release. It was in my tree, but
now it isn't, and it isn't in 6.5.2 either.I asked for the author to verify my work. I am adding it to the tree
now. What do we do?Either make a 6.5.3, inline 6.5.2 (6.5.2a, anyone??) or leave 6.5.2 as is.
None is ideal -- although a 6.5.3 is better than a badly broken 6.5.2. The
short term solution is for those using 6.5.2 to download the pgaccess-0.98
tarball from flex.ro.I ran across the depopulated pgaccess tree this morning while starting the
build cycle for the 6.5.2 rpms -- good thing I have already dealt with that
issue with previous packages. For the RPM's, it has been practice for some time
to include the very latest pgaccess as a separate tarball, then untarring it
over top of the one in the main tarball during the package build. I was hoping
to get away from that. ;-(
Yes, I have created a bad situation. pgaccess it very important for pgsql.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 19:16:20 1999
Received: from argh.demon.co.uk (IDENT:grim@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA66939
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 19:16:15 -0400 (EDT)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id AAA28034;
Tue, 21 Sep 1999 00:20:22 +0100
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199909202320.AAA28034@argh.demon.co.uk>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
To: yucao@falcon.kla-tencor.com (Yu Cao)
Date: Tue, 21 Sep 1999 00:20:21 +0100 (BST)
Cc: pgsql-hackers@postgreSQL.org (pgsql-hackers@postgreSQL.org)
In-Reply-To: <Pine.SOL.3.96.990920154145.22085A-100000@jedi.kla-tencor.com>
from "Yu Cao" at Sep 20, 1999 03:47:16 PM
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I think I can safely speak for a newbie and I happen to dislike
createdb etc as well. I started out with postgreSQL with the
intention of writing an application-specific CORBA front-end
to it, so I cared most about the C++ interface. The existence of
the createdb command confused me for a while, leaving me thinking
I could do INSERT and SELECT etc from libpq++, but would have
to resort to UNIX calls to do createdb.--Yu Cao
I would have to say that if you 'started out with theintention of writing
a corba front-and' then I dont think you can really speak for newbies.
When I started using postgresql I had vaguely heard of odbc and I had
a couple of example queries of SQL.
If I had had to go to template1 and create database whatever; and THEN
go use it, I would have been fairly confused.
The way I look at it, it is functionality that is THERE already. If you
remove it, you remove from the overall functionality of postgres. It doesnt
actually gain anything to remove it. Sure it looks a bit neater, but the end
user cares about being able to use it easilly, not if the scripts are
technically pleasing.
I think the problem described above comes from a lack in the documentation,
or a failure to read the relavent documentation. Having more functionality
is good. Removing it is counterproductive.
The arguement that was put forwards of 'if they want scripts they can write
them, let the admins learn and do it themselves' is a bad one IMHO. Is
it really desirable for a dozen people to be forced to write what is
effectively the same script? When the script is already there anyway?
We should be moving towards a lower learning curve to getting a basic
database up and running, not a higher one. Not all the users WANT to
have to write theirown scripts for everything. I know I certainly
dont.
Just my 2p worth
~Michael
From bouncefilter Mon Sep 20 20:19:26 1999
Received: from excelsior.rkirkpat.net (dhcp-210-85.letu.edu [204.158.210.85])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA75034;
Mon, 20 Sep 1999 20:19:05 -0400 (EDT)
(envelope-from rkirkpat@rkirkpat.net)
Received: from localhost (rkirkpat@localhost)
by excelsior.rkirkpat.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id
TAA20325; Mon, 20 Sep 1999 19:18:55 -0500
Date: Mon, 20 Sep 1999 19:18:54 -0500 (CDT)
From: Ryan Kirkpatrick <pgsql@rkirkpat.net>
X-Sender: rkirkpat@excelsior.rkirkpat.net
To: Uncle George <gatgul@voicenet.com>
cc: pgsql-hackers@postgreSQL.org, pgsql-patches@postgreSQL.org,
pgsql-ports@postgreSQL.org
Subject: Re: [PORTS] Linux/Alpha patches for Postgresql 6.5.2
In-Reply-To: <37E4BC22.31C8461B@voicenet.com>
Message-ID: <Pine.LNX.4.10.9909201916020.30766-100000@excelsior.rkirkpat.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 19 Sep 1999, Uncle George wrote:
Not its not. It is the 'cost' of the 'parsed' branch trees that are
causing the final display to be slightly different. If one were to
change the size of an 'internal' 'C struct' to be the same size of an
'i386' 'C struct' then the results are the same ( or at least make the
sizeof() values the same ) then the results would be the same.as for the differences in the 'off by a small fraction' is due to i386
having 80bit float operations, and the alpha does 64bit float
operations. ( Both under the same ieee mandate to do the same
algorithm)
gat
Thank you for those clarifications.
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
From bouncefilter Mon Sep 20 20:45:21 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA79127
for <pgsql-hackers@postgresql.org>;
Mon, 20 Sep 1999 20:44:59 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from lowen.wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id UAA12271;
Mon, 20 Sep 1999 20:44:56 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess seems a tad confused]
Date: Mon, 20 Sep 1999 20:40:31 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
Cc: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgresql.org
References: <199909202303.TAA24656@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <99092020443207.00568@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit
On Mon, 20 Sep 1999, Bruce Momjian wrote:
Lamar Owen wrote:
I ran across the depopulated pgaccess tree this morning while starting the
build cycle for the 6.5.2 rpms -- good thing I have already dealt with that
issue with previous packages. For the RPM's, it has been practice for some time
to include the very latest pgaccess as a separate tarball, then untarring it
over top of the one in the main tarball during the package build. I was hoping
to get away from that. ;-(Yes, I have created a bad situation. pgaccess it very important for pgsql.
I wouldn't have even noticed had I not remembered that pgaccess-0.98 was one of
the enhancements in 6.5.2. I was looking to rid the RPM's of the extra tarball
of pgaccess. Had I not noticed, I would have blissfully kept the pgaccess-0.98
tarball in the RPM, and not gone rabbit-hunting. As it stands, the
pgacess-0.98 tarball is kept in the 6.5.2 RPM, just not blissfully. ;-)
Don't punish yourself too hard -- an honest (if avoidable) mistake.
-----------------------------------------------------------------------------
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Mon Sep 20 21:29:35 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA85004
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 21:28:39 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA81048;
Mon, 20 Sep 1999 22:26:42 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 22:26:42 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Vince Vielhaber <vev@michvhf.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Lamar Owen <lamar.owen@wgcr.org>, Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <199909202246.SAA24091@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909202225440.38923-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 20 Sep 1999, Bruce Momjian wrote:
My personal dislike for them is that they are incomplete...CREATE USER and
CREATE DATABASE have a helluva lot of options available to it...using
createuser, you don't know/learn abotu them...Force the admin to learn what they are doing...if they want to create
short cut scripts, let *them* do it...But newbies can't do shortcuts. I think we need to keep it.
Newbies can't read man pages to type 'CREATE USER <userid>' or 'CREATE
DATABASE <database>'?
We're not asking anyone to learn rocket science here...we leave that to
Thomas :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 21:44:22 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA87211
for <pgsql-hackers@postgresql.org>;
Mon, 20 Sep 1999 21:43:59 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA81209;
Mon, 20 Sep 1999 22:44:08 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 22:44:04 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Michael Simms <grim@argh.demon.co.uk>
cc: Yu Cao <yucao@falcon.kla-tencor.com>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <199909202320.AAA28034@argh.demon.co.uk>
Message-ID: <Pine.BSF.4.10.9909202227240.38923-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 21 Sep 1999, Michael Simms wrote:
I would have to say that if you 'started out with theintention of writing
a corba front-and' then I dont think you can really speak for newbies.When I started using postgresql I had vaguely heard of odbc and I had
a couple of example queries of SQL.If I had had to go to template1 and create database whatever; and THEN
go use it, I would have been fairly confused.
Why? How did you learn about the createdb or createuser commands in the
first place?
Section 20 of the INSTALL file could read:
20. Briefly test that the backend will start and
run by running it from the command line.
a. Start the postmaster daemon running in the
background by typing
$ cd
$ nohup postmaster -i > pgserver.log 2>&1 &
b. Connect to the database by typing
$ psql template1
b. Create a database by typing
$ create database testdb;
c. Connect to the new database by typing:
template1=> \connect testdb
d. And run a sample query:
testdb=> SELECT datetime 'now';
e. Exit psql:
testdb=> \q
f. Remove the test database (unless you will
want to use it later for other tests):
testdb=> drop database testdb;
now the end user knows how to create and drop a database properly...
hell, add in a few extra steps for creating a new user and deleting
him...once ppl know the commands exist, they will use them and learn how
to better use them...
For 'newbies', they learn about createdb/createuser from the INSTALL
file...it doesn't take anything to teach them to do 'CREATE DATABASE' vs
'createdb', and it gives them the *proper* way to do it...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 21:52:27 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id VAA88326
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 21:52:25 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 12280 invoked by uid 1001); 21 Sep 1999 01:52:29 -0000
Message-ID: <XFMail.990920215229.vev@michvhf.com>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.BSF.4.10.9909202225440.38923-100000@thelab.hub.org>
Date: Mon, 20 Sep 1999 21:52:29 -0400 (EDT)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: The Hermit Hacker <scrappy@hub.org>, hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
On 21-Sep-99 The Hermit Hacker wrote:
On Mon, 20 Sep 1999, Bruce Momjian wrote:
My personal dislike for them is that they are incomplete...CREATE USER and
CREATE DATABASE have a helluva lot of options available to it...using
createuser, you don't know/learn abotu them...Force the admin to learn what they are doing...if they want to create
short cut scripts, let *them* do it...But newbies can't do shortcuts. I think we need to keep it.
Newbies can't read man pages to type 'CREATE USER <userid>' or 'CREATE
DATABASE <database>'?
You're missing one minor point. It's highly probable you never experienced
it. The first few days (maybe even couple of weeks) PostgreSQL can be
intimidating. Most packages install the same way:
./configure
make
make install
and you can do it from whatever directory you want. Right from the
beginning, the postgres installation has you working from a directory
that you may not normally keep your sources in (I keep mine in /usr/local/src
as do many others), working as a user you just created so you're in an
unfamiliar environment. Then the redirection of the make process (or the
gmake process) monitoring it with tail.... For the first time installer
it can be intimidating. Hell, Innd 1.4 was easier to install the first
time. After doing it more than once (and using Tom's tip with makefile.custom)
all of that can be gotten around. Then the regression tests. Lets face
it, it's a big package - well worth the effort to learn it, but it's still
big. So after putting the poor newbie thru all of this trauma you want to
further traumatize him/her with man pages? :)
We're not asking anyone to learn rocket science here...we leave that to
Thomas :)
Good candidate too :)
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Mon Sep 20 21:55:22 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id VAA88873
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 21:55:12 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 12296 invoked by uid 1001); 21 Sep 1999 01:55:16 -0000
Message-ID: <XFMail.990920215516.vev@michvhf.com>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.BSF.4.10.9909202227240.38923-100000@thelab.hub.org>
Date: Mon, 20 Sep 1999 21:55:16 -0400 (EDT)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
Cc: Yu Cao <yucao@falcon.kla-tencor.com>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
Michael Simms <grim@argh.demon.co.uk>
On 21-Sep-99 The Hermit Hacker wrote:
On Tue, 21 Sep 1999, Michael Simms wrote:
I would have to say that if you 'started out with theintention of writing
a corba front-and' then I dont think you can really speak for newbies.When I started using postgresql I had vaguely heard of odbc and I had
a couple of example queries of SQL.If I had had to go to template1 and create database whatever; and THEN
go use it, I would have been fairly confused.Why? How did you learn about the createdb or createuser commands in the
first place?Section 20 of the INSTALL file could read:
20. Briefly test that the backend will start and
run by running it from the command line.
a. Start the postmaster daemon running in the
background by typing
$ cd
$ nohup postmaster -i > pgserver.log 2>&1 &
b. Connect to the database by typing
$ psql template1
b. Create a database by typing
$ create database testdb;
c. Connect to the new database by typing:
template1=> \connect testdb
d. And run a sample query:
testdb=> SELECT datetime 'now';
e. Exit psql:
testdb=> \q
f. Remove the test database (unless you will
want to use it later for other tests):
testdb=> drop database testdb;
e and f mixed up?
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Mon Sep 20 21:58:22 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA89171
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 21:58:01 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id VAA27085;
Mon, 20 Sep 1999 21:55:17 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909210155.VAA27085@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <Pine.BSF.4.10.9909202225440.38923-100000@thelab.hub.org> from
The
Hermit Hacker at "Sep 20, 1999 10:26:42 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 20 Sep 1999 21:55:17 -0400 (EDT)
CC: Vince Vielhaber <vev@michvhf.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Lamar Owen <lamar.owen@wgcr.org>, Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
But newbies can't do shortcuts. I think we need to keep it.
Newbies can't read man pages to type 'CREATE USER <userid>' or 'CREATE
DATABASE <database>'?We're not asking anyone to learn rocket science here...we leave that to
Thomas :)
But we have to get the newbie started before they are going to dive in
and learn manuals.
I don't read the manuals until I decide I want to use some new piece of
software. I am reading the LyX manuals now only after using it for a
few weeks and deciding I want to move from troff to lyx.
Because it is part of getting started, it has to be easy.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 22:11:22 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA91922
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 22:11:19 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA81441;
Mon, 20 Sep 1999 23:11:02 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 23:10:58 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Vince Vielhaber <vev@michvhf.com>
cc: Yu Cao <yucao@falcon.kla-tencor.com>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
Michael Simms <grim@argh.demon.co.uk>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <XFMail.990920215516.vev@michvhf.com>
Message-ID: <Pine.BSF.4.10.9909202310440.38923-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 20 Sep 1999, Vince Vielhaber wrote:
On 21-Sep-99 The Hermit Hacker wrote:
On Tue, 21 Sep 1999, Michael Simms wrote:
I would have to say that if you 'started out with theintention of writing
a corba front-and' then I dont think you can really speak for newbies.When I started using postgresql I had vaguely heard of odbc and I had
a couple of example queries of SQL.If I had had to go to template1 and create database whatever; and THEN
go use it, I would have been fairly confused.Why? How did you learn about the createdb or createuser commands in the
first place?Section 20 of the INSTALL file could read:
20. Briefly test that the backend will start and
run by running it from the command line.
a. Start the postmaster daemon running in the
background by typing
$ cd
$ nohup postmaster -i > pgserver.log 2>&1 &
b. Connect to the database by typing
$ psql template1
b. Create a database by typing
$ create database testdb;
c. Connect to the new database by typing:
template1=> \connect testdb
d. And run a sample query:
testdb=> SELECT datetime 'now';
e. Exit psql:
testdb=> \q
f. Remove the test database (unless you will
want to use it later for other tests):
testdb=> drop database testdb;e and f mixed up?
*glare* it was a sample...:P
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 22:15:22 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA92794
for <pgsql-hackers@postgreSQL.org>;
Mon, 20 Sep 1999 22:15:21 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA81497;
Mon, 20 Sep 1999 23:13:07 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 20 Sep 1999 23:13:07 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Vince Vielhaber <vev@michvhf.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Lamar Owen <lamar.owen@wgcr.org>, Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <199909210155.VAA27085@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909202311080.38923-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 20 Sep 1999, Bruce Momjian wrote:
But newbies can't do shortcuts. I think we need to keep it.
Newbies can't read man pages to type 'CREATE USER <userid>' or 'CREATE
DATABASE <database>'?We're not asking anyone to learn rocket science here...we leave that to
Thomas :)But we have to get the newbie started before they are going to dive in
and learn manuals.
Section 20 of the INSTALL file *does that*...but get them started the
right way, using the proper commands is all I'm saying...
How else is someone going to know about {create,destroy}{user,db} in the
first place, but by reading through the INSTALL file...so change that so
that they learn to connect to the database and use proper SQL...
That is all my point is...we are already telling them how to get started,
let's change that to "how to get started the proper way"...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 20 22:48:22 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA97364
for <hackers@postgreSQL.org>; Mon, 20 Sep 1999 22:47:52 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id WAA27574;
Mon, 20 Sep 1999 22:47:38 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909210247.WAA27574@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <XFMail.990920215229.vev@michvhf.com> from Vince Vielhaber at
"Sep
20, 1999 09:52:29 pm"
To: Vince Vielhaber <vev@michvhf.com>
Date: Mon, 20 Sep 1999 22:47:38 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
You're missing one minor point. It's highly probable you never experienced
it. The first few days (maybe even couple of weeks) PostgreSQL can be
intimidating. Most packages install the same way:./configure
make
make installand you can do it from whatever directory you want. Right from the
beginning, the postgres installation has you working from a directory
that you may not normally keep your sources in (I keep mine in /usr/local/src
as do many others), working as a user you just created so you're in an
unfamiliar environment. Then the redirection of the make process (or the
gmake process) monitoring it with tail.... For the first time installer
it can be intimidating. Hell, Innd 1.4 was easier to install the first
time. After doing it more than once (and using Tom's tip with makefile.custom)
all of that can be gotten around. Then the regression tests. Lets face
it, it's a big package - well worth the effort to learn it, but it's still
big. So after putting the poor newbie thru all of this trauma you want to
further traumatize him/her with man pages? :)
I agree our INSTALL is very large. Is there some way we can simplify
the install process?
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Mon Sep 20 23:03:16 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id WAA99024
for pgsql-hackers@postgresql.org; Mon, 20 Sep 1999 22:59:35 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: les@Mars.mcs.net (Leslie Mikesell)
X-Newsgroups: comp.databases.postgresql.hackers
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
Date: 20 Sep 1999 21:59:26 -0500
Organization: Unknown
Lines: 19
Message-ID: <7s6sae$2evg$1@Mars.mcs.net>
References: <199909201327.JAA18590@candle.pha.pa.us>
To: pgsql-hackers@postgresql.org
In article <199909201327.JAA18590@candle.pha.pa.us>,
Bruce Momjian <maillist@candle.pha.pa.us> wrote:
I am told we are the same as Ingres, and slower than Oracle with no -F,
and faster than Oracle with -F.What is "-F"?
-F is postgres option for no-fsync.
Does that matter on read-only selects?
Might some future version of postgresql have an option to turn
off transaction support to match mysql speed for the situations
where that is more important than the ability to roll back?
Les Mikesell
les@mcs.com
From bouncefilter Tue Sep 21 00:27:52 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA16375
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 00:26:43 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id NAA29052
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 13:26:41 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id NAA24996 for
<pgsql-hackers@postgreSQL.org>; Tue, 21 Sep 1999 13:26:40 +0900 (JST)
Message-Id: <199909210426.NAA24996@srapc451.sra.co.jp>
From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: pgsql-hackers@postgreSQL.org
Subject: postmaster disappears
Date: Tue, 21 Sep 1999 13:26:40 +0900
Sender: t-ishii@srapc451.sra.co.jp
Hi,
I got a few reports from users that postmaster disappears for unknown
reason. Inspecting the postmaster log, I found that postmaster exited at:
if (select(nSockets, &rmask, &wmask, (fd_set *) NULL,
(struct timeval *) NULL) < 0)
{
if (errno == EINTR)
continue;
fprintf(stderr, "%s: ServerLoop: select failed: %s\n",
progname, strerror(errno));
return STATUS_ERROR; <-- here
}
In this case errno=ECHILD has been returned that makes postmaster
exiting. This could happen if SIGCHLD raised between select() call and
the next if (errno=...) statement. One of the solution would be
ignoring ECHILD as well as EINTR. Included are patches for this. If
there's no objection, I will commit them to both stable and current
tree.
*** postgresql-6.5.1/src/backend/postmaster/postmaster.c~ Thu Jul 8 02:17:48 1999
--- postgresql-6.5.1/src/backend/postmaster/postmaster.c Thu Sep 9 10:14:30 1999
***************
*** 709,719 ****
if (select(nSockets, &rmask, &wmask, (fd_set *) NULL,
(struct timeval *) NULL) < 0)
{
! if (errno == EINTR)
continue;
! fprintf(stderr, "%s: ServerLoop: select failed: %s\n",
progname, strerror(errno));
! return STATUS_ERROR;
} /*
--- 709,729 ----
if (select(nSockets, &rmask, &wmask, (fd_set *) NULL,
(struct timeval *) NULL) < 0)
{
! switch(errno) {
! case EINTR:
continue;
! break;
! case ECHILD:
! fprintf(stderr, "%s: ServerLoop: ignoring ECHILD\n",
! progname);
! continue;
! break;
! default:
! fprintf(stderr, "%s: ServerLoop: select failed: %s\n",
progname, strerror(errno));
! return STATUS_ERROR;
! break;
! }
}/*
From bouncefilter Tue Sep 21 01:15:25 1999
Received: from web124.yahoomail.com (web124.yahoomail.com [205.180.60.192])
by hub.org (8.9.3/8.9.3) with SMTP id BAA23990
for <pgsql-hackers@postgresql.org>;
Tue, 21 Sep 1999 01:14:33 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19990921051433.1400.rocketmail@web124.yahoomail.com>
Received: from [206.246.185.100] by web124.yahoomail.com;
Mon, 20 Sep 1999 22:14:33 PDT
Date: Mon, 20 Sep 1999 22:14:33 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] create table and default 'now' problem ?
To: Oleg Bartunov <oleg@sai.msu.su>
Cc: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
One way around this bug is to create a SQL function
which returns now() and use it as the default value:
1. create function mynow() returns datetime
as 'SELECT now()::datetime' LANGUAGE 'SQL';
2. create table test (a datetime default mynow(), b
int4);
Now things should work:
insert into test (b) values (1);
insert into test (b) values (2);
select * from test;
a |b
----------------------------+-
Tue Sep 21 01:05:02 1999 EDT|1
Tue Sep 21 01:05:08 1999 EDT|2
(2 rows)
Hope this helps,
Mike Mascari
(mascarim@yahoo.com)
--- Oleg Bartunov <oleg@sai.msu.su> wrote:Hi,
how I could create table with datetime field default
to 'now'::text in
a way Jan did in his shoes rule example ?If I do:
test=> create table test ( a datetime default 'now',
b int4);
CREATE
test=> insert into test (b) values (1);
INSERT 1677899 1
test=> insert into test (b) values (2);
INSERT 1677900 1
test=> select * from test;
a |b
----------------------------+-
Tue 21 Sep 01:48:27 1999 MSD|1
Tue 21 Sep 01:48:27 1999 MSD|2
(2 rows)I always get datetime of the moment I created the
table, but I'd like
to have datetime of moment I insert.Regards,
Oleg
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
From bouncefilter Tue Sep 21 02:01:25 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA30642
for <pgsql-hackers@postgresql.org>;
Tue, 21 Sep 1999 02:01:11 -0400 (EDT)
(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 FAA12324;
Tue, 21 Sep 1999 05:59:54 GMT
Sender: lockhart@hub.org
Message-ID: <37E71EDA.F19D89F6@alumni.caltech.edu>
Date: Tue, 21 Sep 1999 05:59:54 +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: The Hermit Hacker <scrappy@hub.org>
CC: Vince Vielhaber <vev@michvhf.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Lamar Owen <lamar.owen@wgcr.org>, Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <Pine.BSF.4.10.9909201925341.38923-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Force the admin to learn what they are doing...if they want to create
short cut scripts, let *them* do it...
Damn. You're going to make me read the docs?
- Thomas, who *always* uses the scripts and would miss them
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Sep 21 02:05:30 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA31131
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 02:05:08 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id DAA83465;
Tue, 21 Sep 1999 03:02:00 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 21 Sep 1999 03:01:58 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Mike Mascari <mascarim@yahoo.com>
cc: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] create table and default 'now' problem ?
In-Reply-To: <19990921051433.1400.rocketmail@web124.yahoomail.com>
Message-ID: <Pine.BSF.4.10.9909210301321.38923-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 20 Sep 1999, Mike Mascari wrote:
One way around this bug is to create a SQL function
which returns now() and use it as the default value:1. create function mynow() returns datetime
as 'SELECT now()::datetime' LANGUAGE 'SQL';2. create table test (a datetime default mynow(), b
int4);Now things should work:
insert into test (b) values (1);
insert into test (b) values (2);select * from test;
a |b
----------------------------+-
Tue Sep 21 01:05:02 1999 EDT|1
Tue Sep 21 01:05:08 1999 EDT|2
(2 rows)Hope this helps,
Why the 'create function'?
hardware=> create table test_table ( a int4, ts datetime default 'now' );
CREATE
hardware=> insert into test_table values ( 1 ) ;
INSERT 115445 1
hardware=> select * from test_table;
a|ts
-+----------------------------
1|Tue Sep 21 02:00:50 1999 EDT
(1 row)
Mike Mascari
(mascarim@yahoo.com)--- Oleg Bartunov <oleg@sai.msu.su> wrote:Hi,
how I could create table with datetime field default
to 'now'::text in
a way Jan did in his shoes rule example ?If I do:
test=> create table test ( a datetime default 'now',
b int4);
CREATE
test=> insert into test (b) values (1);
INSERT 1677899 1
test=> insert into test (b) values (2);
INSERT 1677900 1
test=> select * from test;
a |b
----------------------------+-
Tue 21 Sep 01:48:27 1999 MSD|1
Tue 21 Sep 01:48:27 1999 MSD|2
(2 rows)I always get datetime of the moment I created the
table, but I'd like
to have datetime of moment I insert.Regards,
Oleg
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Sep 21 02:05:25 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA30886
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 02:04:36 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id DAA83470;
Tue, 21 Sep 1999 03:03:58 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 21 Sep 1999 03:03:58 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Mike Mascari <mascarim@yahoo.com>
cc: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] create table and default 'now' problem ?
In-Reply-To: <19990921051433.1400.rocketmail@web124.yahoomail.com>
Message-ID: <Pine.BSF.4.10.9909210302340.38923-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Ignore last...I hadn't clued into the 'same time as table created' part of
his message...
Thomas...is that not a 'bug' with the datetime/timestamp handling of
DEFAULT? *raised eyebrow*
On Mon, 20 Sep 1999, Mike Mascari wrote:
One way around this bug is to create a SQL function
which returns now() and use it as the default value:1. create function mynow() returns datetime
as 'SELECT now()::datetime' LANGUAGE 'SQL';2. create table test (a datetime default mynow(), b
int4);Now things should work:
insert into test (b) values (1);
insert into test (b) values (2);select * from test;
a |b
----------------------------+-
Tue Sep 21 01:05:02 1999 EDT|1
Tue Sep 21 01:05:08 1999 EDT|2
(2 rows)Hope this helps,
Mike Mascari
(mascarim@yahoo.com)--- Oleg Bartunov <oleg@sai.msu.su> wrote:Hi,
how I could create table with datetime field default
to 'now'::text in
a way Jan did in his shoes rule example ?If I do:
test=> create table test ( a datetime default 'now',
b int4);
CREATE
test=> insert into test (b) values (1);
INSERT 1677899 1
test=> insert into test (b) values (2);
INSERT 1677900 1
test=> select * from test;
a |b
----------------------------+-
Tue 21 Sep 01:48:27 1999 MSD|1
Tue 21 Sep 01:48:27 1999 MSD|2
(2 rows)I always get datetime of the moment I created the
table, but I'd like
to have datetime of moment I insert.Regards,
Oleg
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Sep 21 02:17:27 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA32904
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 02:17:23 -0400 (EDT)
(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 GAA12374;
Tue, 21 Sep 1999 06:14:12 GMT
Sender: lockhart@hub.org
Message-ID: <37E72234.DDA960FE@alumni.caltech.edu>
Date: Tue, 21 Sep 1999 06:14: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: Mike Mascari <mascarim@yahoo.com>
CC: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] create table and default 'now' problem ?
References: <19990921051433.1400.rocketmail@web124.yahoomail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
how I could create table with datetime field default
to 'now'::text in a way Jan did in his shoes rule example ?
If I do:
test=> create table test ( a datetime default 'now',
b int4);
CREATE
I always get datetime of the moment I created the
table, but I'd like to have datetime of moment I insert.One way around this bug is to create a SQL function
which returns now() and use it as the default value:
Not necessary, though this does work well. A simpler way is to
actually do what Oleg asks about:
create table test ( a datetime default text 'now',...)
or
create table test ( a datetime default 'now'::text,...)
which should force the string to *stay* as a string, rather than
getting converted to a date value when the table is created. Once it
is forced to be a string, then it will be converted at insert time
instead.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Sep 21 02:15:25 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA32373
for <pgsql-hackers@postgresql.org>;
Tue, 21 Sep 1999 02:14:50 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id DAA83585;
Tue, 21 Sep 1999 03:14:41 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 21 Sep 1999 03:14:40 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Vince Vielhaber <vev@michvhf.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Lamar Owen <lamar.owen@wgcr.org>, Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <37E71EDA.F19D89F6@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.10.9909210313090.38923-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 21 Sep 1999, Thomas Lockhart wrote:
Force the admin to learn what they are doing...if they want to create
short cut scripts, let *them* do it...Damn. You're going to make me read the docs?
IMHO...yes. It would sure eliminate the "how do I change the password
for a user" if the person wanting to change that password had had to read
the docs in the first place, and witih know about the 'with password' part
of 'create user'...
...and, ummm...don't you have the docs memorized yet? :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Sep 21 09:41:36 1999
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 JAA03210
for <pgsql-hackers@postgresql.org>;
Tue, 21 Sep 1999 09:40:51 -0400 (EDT)
(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 GAA12411;
Tue, 21 Sep 1999 06:28:04 GMT
Sender: lockhart@hub.org
Message-ID: <37E72573.4EB4C364@alumni.caltech.edu>
Date: Tue, 21 Sep 1999 06:28:03 +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: The Hermit Hacker <scrappy@hub.org>
CC: Mike Mascari <mascarim@yahoo.com>, Oleg Bartunov <oleg@sai.msu.su>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] create table and default 'now' problem ?
References: <Pine.BSF.4.10.9909210301321.38923-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Why the 'create function'?
hardware=> insert into test_table values ( 1 ) ;
hardware=> select * from test_table;
1|Tue Sep 21 02:00:50 1999 EDT
Right. And if you run the insert again, you'll see the exact same time
inserted. But if you force 'now' to be a true string type (rather than
leaving it unspecified) then the evaluation will happen at insert
time.
The behavior is "correct" for most values of most types, but falls
down when a seemingly constant value, like a fixed string N-O-W,
actually is not a constant but rather something which changes value
depending on when the query runs. In the long run, we need to have a
new attribute associated with data types which tells whether constants
have that nature (most won't). In the meantime, this is a feature, and
has been since Vadim (?) implemented DEFAULT ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Sep 21 02:59:26 1999
Received: from kodu.home.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA38067
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 02:58:44 -0400 (EDT) (envelope-from hannu@tm.ee)
Received: from tm.ee (hannu@localhost [127.0.0.1])
by kodu.home.ee (8.8.7/8.8.7) with ESMTP id JAA00523;
Tue, 21 Sep 1999 09:50:59 +0300
Sender: hannu@kodu.home.ee
Message-ID: <37E72AD3.8A8CF94C@tm.ee>
Date: Tue, 21 Sep 1999 09:50:59 +0300
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.2.6 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Vince Vielhaber <vev@michvhf.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Lamar Owen <lamar.owen@wgcr.org>, Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <Pine.BSF.4.10.9909210313090.38923-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
On Tue, 21 Sep 1999, Thomas Lockhart wrote:
Force the admin to learn what they are doing...if they want to create
short cut scripts, let *them* do it...Damn. You're going to make me read the docs?
IMHO...yes. It would sure eliminate the "how do I change the password
for a user" if the person wanting to change that password had had to read
the docs in the first place, and witih know about the 'with password' part
of 'create user'...
To achieve that, you can't just instruct a newbie in INSTALL.TXT to do
$ psql template1
$> create user alex
but instead
$ psql template1
$>\h create user
or even better
RTFM
;)
------------
Hannu
From bouncefilter Tue Sep 21 04:44:27 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id EAA54496
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 04:44:13 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11TLQP-0003kLC; Tue, 21 Sep 99 10:37 MET DST
Message-Id: <m11TLQP-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: Referential Integrity In PostgreSQL
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Tue, 21 Sep 1999 10:37:21 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Hi , Jan
my name is Max .
Hi Max,
I have contributed to SPI interface ,
that with external Trigger try to make
a referential integrity.If I can Help , in something ,
I'm here .
You're welcome.
I've CC'd the hackers list because we might get some ideas
from there too (and to surface once in a while - Bruce
already missed me).
Currently I'm very busy for serious work so I don't find
enough spare time to start on such a big change to
PostgreSQL. But I'd like to give you an overview of what I
have in mind so far so you can decide if you're able to help.
Referential integrity (RI) is based on constraints defined in
the schema of a database. There are some different types of
constraints:
1. Uniqueness constraints.
2. Foreign key constraints that ensure that a key value used
in an attribute exists in another relation. One
constraint must ensure you're unable to INSERT/UPDATE to
a value that doesn't exist, another one must prevent
DELETE on a referenced key item or that it is changed
during UPDATE.
3. Cascading deletes that let rows referring to a key follow
on DELETE silently.
Even if not defined in the standard (AFAIK) there could be
others like letting references automatically follow on UPDATE
to a key value.
All constraints can be enabled and/or default to be deferred.
That means, that the RI checks aren't performed when they are
triggerd. Instead, they're checked at transaction end or if
explicitly invoked by some special statement. This is really
important because someone must be able to setup cyclic RI
checks that could never be satisfied if the checks would be
performed immediately. The major problem on this is the
amount of data affected until the checks must be performed.
The number of statements executed, that trigger such deferred
constraints, shouldn't be limited. And one single
INSERT/UPDATE/DELETE could affect thousands of rows.
Due to these problems I thought, it might not be such a good
idea to remember CTID's or the like to get back OLD/NEW rows
at the time the constraints are checked. Instead I planned to
misuse the rule system for it. Unfortunately, the rule system
has damned tricky problems itself when it comes to having-,
distinct and other clauses and extremely on aggregates and
subselects. These problems would have to get fixed first. So
it's a solution that cannot be implemented right now.
Fallback to CTID remembering though. There are problems too
:-(. Let's enhance the trigger mechanism with a deferred
feature. First this requires two additional bool attributes
in the pg_trigger relation that tell if this trigger is
deferrable and if it is deferred by default. While at it we
should add another bool that tells if the trigger is enabled
(ALTER TRIGGER {ENABLE|DISABLE} trigger).
Second we need an internal list of triggers, that are
currently DEFINED AS DEFERRED. Either because they default to
it, or the user explicitly asked to deferr it.
Third we need an internal list of triggers that must be
invoked later because at the time an event occured where they
should have been triggered, they appeared in the other list
and their execution is delayed until transaction end or
explicit execution. This list must remember the OID of the
trigger to invoke (to identify the procedure and the
arguments), the relation that caused the trigger and the
CTID's of the OLD and NEW row.
That last list could grow extremely! Think of a trigger
that's executing commands over SPI which in turn activate
deferred triggers. Since the order of trigger execution is
very important for RI, I can't see any chance to
simplify/condense this information. Thus it is 16 bytes at
least per deferred trigger call (2 OID's plus 2 CTID's). I
think one or more temp files would fit best for this.
A last tricky point is if one of a bunch of deferred triggers
is explicitly called for execution. At this time, the entries
for it in the temp file(s) must get processed and marked
executed (maybe by overwriting the triggers OID with the
invalid OID) while other trigger events still have to get
recorded.
Needless to say that reading thousands of those entries just
to find a few isn't good on performance. But better have this
special case slow that dealing with hundreds of temp files or
other overhead slowing down the usual case where ALL deferred
triggers get called at transaction end.
Trigger invocation is simple now - fetch the OLD and NEW rows
by CTID and execute the trigger as done by the trigger
manager. Oh - well - vacuum shouldn't touch relations where
deferred triggers are outstanding. Might require some
special lock entry - Vadim?
Did I miss something?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Sep 21 04:48:32 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id EAA55054
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 04:48:18 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11TLU1-0003kLC; Tue, 21 Sep 99 10:41 MET DST
Message-Id: <m11TLU1-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Status on Jan Wieck
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Tue, 21 Sep 1999 10:41:05 +0200 (MET DST)
Cc: maillist@candle.pha.pa.us, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <13978.937839513@sss.pgh.pa.us> from "Tom Lane" at Sep 20,
99 10:58:33 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Bruce Momjian <maillist@candle.pha.pa.us> writes:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Good ... I was starting to fear he'd been run over by a truck or
something :-(Does he have any idea when/if he'll return to Postgres hacking?
As soon as I see the light at the end of the tunnel (and am
sure that it's not the coming train). I think it will take
another two or three weeks.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Sep 21 05:03:27 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id FAA58020
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 05:03:24 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11TLio-0003kLC; Tue, 21 Sep 99 10:56 MET DST
Message-Id: <m11TLio-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Status on Jan Wieck
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Tue, 21 Sep 1999 10:56:22 +0200 (MET DST)
Cc: tgl@sss.pgh.pa.us, "PostgreSQL-development"@candle.pha.pa.us,
pgsql-hackers@postgreSQL.org, jwieck@debis.com
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199909201532.LAA03910@candle.pha.pa.us> from "Bruce Momjian" at
Sep 20, 99 11:32:16 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Bruce Momjian <maillist@candle.pha.pa.us> writes:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Good ... I was starting to fear he'd been run over by a truck or
something :-(Does he have any idea when/if he'll return to Postgres hacking?
That brings up another issue.
Why do people think programmers are throwing themselves in front of
trucks? Any idea? I hear it often.
Maybe because it's one of the most failsafe methods?
Additionally the risk for the truck driver isn't as high as
it would be for the driver of an A-Class (besides that an A-
Class driver would treat the whole think like an elk-test -
and we all know what the result of that is :-).
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Sep 21 05:18:33 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id FAA60402
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 05:18:28 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11TLxK-0003kwC; Tue, 21 Sep 99 11:11 MET DST
Message-Id: <m11TLxK-0003kwC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Status on Jan Wieck
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Tue, 21 Sep 1999 11:11:22 +0200 (MET DST)
Cc: vadim@krs.ru, wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199909201814.OAA07550@candle.pha.pa.us> from "Bruce Momjian" at
Sep 20, 99 02:14:51 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Depends on WHEN 6.6 is planned to go into feature-freeze.
Well, I believe that we have at least 3 months before 1st beta.
We need in DIRTY READs for RI and I'll implement them.
If you'll not be able to do RI itself then we might
change refint.c to use DIRTY READs and so avoid LOCK TABLE
on application level (i.e. restore pre-6.5 refint.c using).Yikes. Three months. That puts us at release in mid-January.
Three months - sounds fine. I just posted another few ideas
on the issue. After rereading it, I'm sure now that doing RI
with the rulesystem would open a horrible can of worms.
Especially in the case a trigger procedure is using a query
which in turn triggers a deferred rule.
Each trigger invocation (maybe for thousands of rows) will
execute it's own queries, resulting in a separate parsetree
for the deferred actions. Where to hold them? Parsetrees can
be huge!
I'm sure now that remembering the CTID's of the tuples that
must get reread to fire the trigger is the smaller problem.
I need a little break in my current project - thus I'll take
a look at it NOW!
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Sep 21 05:25:27 1999
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA61267
for <hackers@postgresql.org>; Tue, 21 Sep 1999 05:24:43 -0400 (EDT)
(envelope-from andreas.zeugswetter@telecom.at)
Received: from telecom.at (w0188000580.f000.d0188.sd.spardat.at
[172.18.65.249])
by gandalf.telecom.at (xxx/xxx) with ESMTP id LAA35244
for <hackers@postgresql.org>; Tue, 21 Sep 1999 11:24:11 +0200
Message-ID: <37E74EB9.44F9766E@telecom.at>
Date: Tue, 21 Sep 1999 11:24:09 +0200
From: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgresql.org
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Oh - well - vacuum shouldn't touch relations where
deferred triggers are outstanding. Might require some
special lock entry - Vadim?
All modified data will be in this same still open transaction.
Therefore no relevant data can be removed by vacuum anyway.
It is my understanding, that the RI check is performed on the newest
available (committed) data (+ modified data from my own tx).
E.g. a primary key that has been removed by another transaction after
my begin work will lead to an RI violation if referenced as foreign key.
Andreas
From bouncefilter Tue Sep 21 05:27:27 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id FAA61828
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 05:27:25 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 13269 invoked by uid 1001); 21 Sep 1999 09:27:25 -0000
Date: Tue, 21 Sep 1999 05:27:25 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>, hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <199909210247.WAA27574@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.05.9909210526120.13245-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 20 Sep 1999, Bruce Momjian wrote:
You're missing one minor point. It's highly probable you never experienced
it. The first few days (maybe even couple of weeks) PostgreSQL can be
intimidating. Most packages install the same way:./configure
make
make installand you can do it from whatever directory you want. Right from the
beginning, the postgres installation has you working from a directory
that you may not normally keep your sources in (I keep mine in /usr/local/src
as do many others), working as a user you just created so you're in an
unfamiliar environment. Then the redirection of the make process (or the
gmake process) monitoring it with tail.... For the first time installer
it can be intimidating. Hell, Innd 1.4 was easier to install the first
time. After doing it more than once (and using Tom's tip with makefile.custom)
all of that can be gotten around. Then the regression tests. Lets face
it, it's a big package - well worth the effort to learn it, but it's still
big. So after putting the poor newbie thru all of this trauma you want to
further traumatize him/her with man pages? :)I agree our INSTALL is very large. Is there some way we can simplify
the install process?
Yeah, but let me test it first. I have two to install this week so I
make sure.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Tue Sep 21 05:57:28 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA66073
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 05:56:58 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id SAA12212; Tue, 21 Sep 1999 18:55:25 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] couldn't rollback cache ?
Date: Tue, 21 Sep 1999 18:58:54 +0900
Message-ID: <000101bf0417$ea264a00$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <13769.937837688@sss.pgh.pa.us>
Importance: Normal
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Monday, September 20, 1999 11:28 PM
To: Hiroshi Inoue
Cc: pgsql-hackers
Subject: Re: [HACKERS] couldn't rollback cache ?"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I think it's not done correctly for tuple SI messages either.
I didn't use current cache invalidation mechanism when I made the
patch for SearchSysCache() because of the following 2 reasons.1. SI messages are eaten by CommandCounterIncrement(). So they
may vanish before transaction end/aborts.I think this is OK. The sending backend does not send the SI message
in the first place until it has committed. Other backends can read
Doesn't the sending backend send the SI message when Command-
CounterIncrement() is executed ?
AtCommit_Cache() is called not only from CommitTransaction() but
also from CommandCounterIncrement().
AtCommit_Cache() in CommandCounterIncrement() eats local
invalidation messages and register SI information (this seems too
early for other backends though it's not so harmful). Then AtAtart_
Cache() eats the SI information and invalidates related syscache
and relcache for the backend(this seems right). At this point,invali-
dation info for the backend vanishes. Isn't it right ?
the messages at CommandCounterIncrement; it doesn't matter whether the
other backends later commit or abort their own transactions. I think.
Do you have a counterexample?2. The tuples which should be invalidated in case of abort are different
from ones in case of commit.
In case of commit,deleting old tuples should be invalidated for all
backends.
In case of abort,insert(updat)ing new tuples should be invalidated
for the insert(updat)ing backend.I wonder whether it wouldn't be cleaner to identify the target tuples
by OID instead of ItemPointer. That way would work for both new and
update tuples...
This may be a better way because the cache entry which should be
invalidated are invalidated.
However,we may invalidate still valid cache entry by OID(it's not so
harmful). Even time qualification is useless in this case.
Currently heap_insert() calls RelationInvalidateHeapTuple() for a
inserting new tuple but heap_replace() doesn't call RelationInvalid-
ateHeapTuple() for a updating new tuple. I don't understand which
is right.Hmm. Invalidating the old tuple is the right thing for heap_replace in
terms of sending a message to other backends at commit; it's the old
tuple that they might have cached and need to get rid of. But for
getting rid of this backend's uncommitted new tuple in case of abort,
it's not the right thing. OTOH, your change to add a time qual check
to SearchSysCache would fix that, wouldn't it?
Probably. Because time qualification is applied for uncommitted tuples.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Tue Sep 21 07:46:29 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id HAA81888
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 07:46:26 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m11TOGd-0003kwC; Tue, 21 Sep 99 13:39 MET DST
Message-Id: <m11TOGd-0003kwC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
To: andreas.zeugswetter@telecom.at (Andreas Zeugswetter)
Date: Tue, 21 Sep 1999 13:39:27 +0200 (MET DST)
Cc: hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37E74EB9.44F9766E@telecom.at> from "Andreas Zeugswetter" at Sep
21, 99 11:24:09 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Oh - well - vacuum shouldn't touch relations where
deferred triggers are outstanding. Might require some
special lock entry - Vadim?All modified data will be in this same still open transaction.
Therefore no relevant data can be removed by vacuum anyway.
I expect this, but I really need to be sure that not even the
location of the tuple in the heap will change. I need to find
the tuples at the time the deferred triggers must be executed
via heap_fetch() by their CTID!
It is my understanding, that the RI check is performed on the newest
available (committed) data (+ modified data from my own tx).
E.g. a primary key that has been removed by another transaction after
my begin work will lead to an RI violation if referenced as foreign key.
Absolutely right. The function that will fire the deferred
triggers must switch to READ COMMITTED isolevel while doing
so.
What I'm not sure about is which snapshot to use to get the
OLD tuples (outdated in this transaction by a previous
command). Vadim?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Sep 21 08:21:29 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA89752
for <pgsql-hackers@postgresql.org>;
Tue, 21 Sep 1999 08:20:32 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA85689;
Tue, 21 Sep 1999 09:17:58 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 21 Sep 1999 09:17:57 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Jan Wieck <wieck@debis.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, maillist@candle.pha.pa.us,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Status on Jan Wieck
In-Reply-To: <m11TLU1-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.BSF.4.10.9909210917360.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 21 Sep 1999, Jan Wieck wrote:
Bruce Momjian <maillist@candle.pha.pa.us> writes:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Good ... I was starting to fear he'd been run over by a truck or
something :-(Does he have any idea when/if he'll return to Postgres hacking?
As soon as I see the light at the end of the tunnel (and am
sure that it's not the coming train). I think it will take
another two or three weeks.
Figure a Jan/Feb release for 6.6...enough time? :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Sep 21 08:27:29 1999
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA90563
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 08:26:06 -0400 (EDT) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id QAA12574;
Tue, 21 Sep 1999 16:24:31 +0400 (MSD)
Date: Tue, 21 Sep 1999 16:24:31 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] create table and default 'now' problem ?
In-Reply-To: <37E72234.DDA960FE@alumni.caltech.edu>
Message-ID: <Pine.GSO.3.96.SK.990921161931.8336C-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 21 Sep 1999, Thomas Lockhart wrote:
Date: Tue, 21 Sep 1999 06:14:12 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
To: Mike Mascari <mascarim@yahoo.com>
Cc: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] create table and default 'now' problem ?how I could create table with datetime field default
to 'now'::text in a way Jan did in his shoes rule example ?
If I do:
test=> create table test ( a datetime default 'now',
b int4);
CREATE
I always get datetime of the moment I created the
table, but I'd like to have datetime of moment I insert.One way around this bug is to create a SQL function
which returns now() and use it as the default value:Not necessary, though this does work well. A simpler way is to
actually do what Oleg asks about:create table test ( a datetime default text 'now',...)
This works ! Thanks
or
create table test ( a datetime default 'now'::text,...)
Parser complains:
ERROR: parser: parse error at or near "'"
Does this considered as a bug or feature ?
Oleg
which should force the string to *stay* as a string, rather than
getting converted to a date value when the table is created. Once it
is forced to be a string, then it will be converted at insert time
instead.- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From bouncefilter Tue Sep 21 09:43:30 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA04650
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 09:42:46 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA21271;
Tue, 21 Sep 1999 09:40:40 -0400 (EDT)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] create table and default 'now' problem ?
In-reply-to: Your message of Tue, 21 Sep 1999 16:24:31 +0400 (MSD)
<Pine.GSO.3.96.SK.990921161931.8336C-100000@ra>
Date: Tue, 21 Sep 1999 09:40:40 -0400
Message-ID: <21268.937921240@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
how I could create table with datetime field default
to 'now'::text in a way Jan did in his shoes rule example ?
A couple of comments on this thread:
1. Seems to me that the easy, reliable way is just to use the
now() function --- you don't have to make one, it's built in:
create table test ( a datetime default now(), b int);
This avoids all the issues about when constants get coerced, and
probably ought to be what we recommend to newbies. However,
this is certainly a workaround for an existing bug.
2. I believe that most of the problem with premature constant coercion
in default values is coming from the bizarre way that default values get
entered into the database. StoreAttrDefault essentially converts the
parsed default-value tree back to text, constructs a SELECT statement
using the text, parses that, and examines the resulting parsetree.
Yech. If it were done carefully it might work, but it's not; the
reverse parser does not do quoting carefully, does not do type coercion
carefully, and fails to handle large parts of the expression syntax at
all. (I've ranted about this before ... check the pghackers archives.)
I have a to-do list item to rip all that code out and do it over again
right. Might or might not get to it for 6.6 --- does someone else want
to tackle it?
3. Yes, this is a bug too:
create table test ( a datetime default 'now'::text,...)
Parser complains:
ERROR: parser: parse error at or near "'"
Does this considered as a bug or feature ?
See above --- reverse-parsing of this construct is wrong. I have
no intention of fixing the reverse parser; I want to get rid of it
entirely.
regards, tom lane
From bouncefilter Tue Sep 21 10:01:30 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA16411
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 10:00:46 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA21451;
Tue, 21 Sep 1999 09:59:59 -0400 (EDT)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster disappears
In-reply-to: Your message of Tue, 21 Sep 1999 13:26:40 +0900
<199909210426.NAA24996@srapc451.sra.co.jp>
Date: Tue, 21 Sep 1999 09:59:59 -0400
Message-ID: <21449.937922399@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
In this case errno=ECHILD has been returned that makes postmaster
exiting. This could happen if SIGCHLD raised between select() call and
the next if (errno=...) statement. One of the solution would be
ignoring ECHILD as well as EINTR. Included are patches for this.
Hmm. What you are saying, I guess, is that SIGCHLD is raised,
reaper() executes, and then when control continues in the main loop
the errno left over from reaper()'s last kernel call is what's seen,
instead of the one returned by signal().
Seems to me that the correct fix is to have reaper() save and restore
the outer value of errno, not to hack the main line to ignore the
most probable state left over from reaper(). Otherwise you still choke
if some other value gets returned from whatever call reaper() does last.
Moreover, you're not actually checking what the select() did unless
you do it that way.
Curious that this sort of problem is not seen more often --- I wonder
if most Unixes arrange to save/restore errno around a signal handler
for you?
regards, tom lane
From bouncefilter Tue Sep 21 10:02:30 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA16608
for <pgsql-hackers@postgresql.org>;
Tue, 21 Sep 1999 10:02:24 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id KAA10572;
Tue, 21 Sep 1999 10:01:40 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909211401.KAA10572@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <37E71EDA.F19D89F6@alumni.caltech.edu> from Thomas Lockhart at
"Sep 21, 1999 05:59:54 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 21 Sep 1999 10:01:40 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, Vince Vielhaber <vev@michvhf.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Lamar Owen <lamar.owen@wgcr.org>,
Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Force the admin to learn what they are doing...if they want to create
short cut scripts, let *them* do it...Damn. You're going to make me read the docs?
- Thomas, who *always* uses the scripts and would miss them
I created a script for testing called newdb which:
:
destroydb "$@"
createdb "$@"
Yes, I could do this in psql from template1, but why bother.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Tue Sep 21 10:03:30 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA16703
for <pgsql-hackers@postgresql.org>;
Tue, 21 Sep 1999 10:03:01 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id KAA10588;
Tue, 21 Sep 1999 10:02:27 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909211402.KAA10588@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <Pine.BSF.4.10.9909210313090.38923-100000@thelab.hub.org> from
The
Hermit Hacker at "Sep 21, 1999 03:14:40 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 21 Sep 1999 10:02:27 -0400 (EDT)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Vince Vielhaber <vev@michvhf.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Lamar Owen <lamar.owen@wgcr.org>, Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Tue, 21 Sep 1999, Thomas Lockhart wrote:
Force the admin to learn what they are doing...if they want to create
short cut scripts, let *them* do it...Damn. You're going to make me read the docs?
IMHO...yes. It would sure eliminate the "how do I change the password
for a user" if the person wanting to change that password had had to read
the docs in the first place, and witih know about the 'with password' part
of 'create user'......and, ummm...don't you have the docs memorized yet? :)
Can we add some output to the createdb command to remind people it can
be done inside psql?
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Tue Sep 21 10:11:31 1999
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA18247
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 10:11:12 -0400 (EDT) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id SAA14859;
Tue, 21 Sep 1999 18:09:35 +0400 (MSD)
Date: Tue, 21 Sep 1999 18:09:34 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] create table and default 'now' problem ?
In-Reply-To: <21268.937921240@sss.pgh.pa.us>
Message-ID: <Pine.GSO.3.96.SK.990921180536.8336F-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Thank you Tom for explanation. It's not very bothered me as far as I have
many workarounds suggested in mailing list. But I wondering because
'now'::text works as expected when I create view
create view www_auth as select a.account as user_name, a.password, b.nick as
group_name
from users a, resources b, privilege_user_map c
where a.auth_id = c.auth_id and b.res_id = c.res_id and
(a.account_valid_until is null or
a.account_valid_until > datetime('now'::text)) and
c.perm_id = 1;
Regards,
Oleg
On Tue, 21 Sep 1999, Tom Lane wrote:
Date: Tue, 21 Sep 1999 09:40:40 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Oleg Bartunov <oleg@sai.msu.su>
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] create table and default 'now' problem ?how I could create table with datetime field default
to 'now'::text in a way Jan did in his shoes rule example ?A couple of comments on this thread:
1. Seems to me that the easy, reliable way is just to use the
now() function --- you don't have to make one, it's built in:create table test ( a datetime default now(), b int);
This avoids all the issues about when constants get coerced, and
probably ought to be what we recommend to newbies. However,
this is certainly a workaround for an existing bug.2. I believe that most of the problem with premature constant coercion
in default values is coming from the bizarre way that default values get
entered into the database. StoreAttrDefault essentially converts the
parsed default-value tree back to text, constructs a SELECT statement
using the text, parses that, and examines the resulting parsetree.
Yech. If it were done carefully it might work, but it's not; the
reverse parser does not do quoting carefully, does not do type coercion
carefully, and fails to handle large parts of the expression syntax at
all. (I've ranted about this before ... check the pghackers archives.)I have a to-do list item to rip all that code out and do it over again
right. Might or might not get to it for 6.6 --- does someone else want
to tackle it?3. Yes, this is a bug too:
create table test ( a datetime default 'now'::text,...)
Parser complains:
ERROR: parser: parse error at or near "'"
Does this considered as a bug or feature ?See above --- reverse-parsing of this construct is wrong. I have
no intention of fixing the reverse parser; I want to get rid of it
entirely.regards, tom lane
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From bouncefilter Tue Sep 21 10:27:36 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA21015
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 10:27:25 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA21638;
Tue, 21 Sep 1999 10:25:16 -0400 (EDT)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] create table and default 'now' problem ?
In-reply-to: Your message of Tue, 21 Sep 1999 18:09:34 +0400 (MSD)
<Pine.GSO.3.96.SK.990921180536.8336F-100000@ra>
Date: Tue, 21 Sep 1999 10:25:16 -0400
Message-ID: <21636.937923916@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Oleg Bartunov <oleg@sai.msu.su> writes:
Thank you Tom for explanation. It's not very bothered me as far as I have
many workarounds suggested in mailing list. But I wondering because
'now'::text works as expected when I create view
Yes, it's just the context of a DEFAULT expression that has these
problems. (Actually, it looks like constraints --- CHECK() expressions
--- are handled in the same bogus way, but we don't seem to get as many
gripes about them...)regards, tom lane
From bouncefilter Tue Sep 21 10:34:36 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA22048
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 10:33:38 -0400 (EDT)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id WAA27122;
Tue, 21 Sep 1999 22:33:22 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E79730.CC415030@krs.ru>
Date: Tue, 21 Sep 1999 22:33:20 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>,
hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
References: <m11TOGd-0003kwC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jan Wieck wrote:
It is my understanding, that the RI check is performed on the newest
available (committed) data (+ modified data from my own tx).
E.g. a primary key that has been removed by another transaction after
my begin work will lead to an RI violation if referenced as foreign key.Absolutely right. The function that will fire the deferred
triggers must switch to READ COMMITTED isolevel while doing
^^^^^^^^^^^^^^
so.
NO!
What if one transaction deleted PK, another one inserted FK
and now both performe RI check? Both transactions _must_
use DIRTY READs to notice that RI violated by another
in-progress transaction and wait for concurrent transaction...
BTW, using triggers to check _each_ modified tuple
(i.e. run Executor for each modified tuple) is bad for
performance. We could implement direct support for
standard RI constraints.
Using rules (statement level triggers) for INSERT...SELECT,
UPDATE and DELETE queries would be nice! Actually, RI constraint
checks need in very simple queries (i.e. without distinct etc)
and the only we would have to do is
What I'm not sure about is which snapshot to use to get the
OLD tuples (outdated in this transaction by a previous
command). Vadim?
1. Add CommandId to Snapshot.
2. Use Snapshot->CommandId instead of global CurrentScanCommandId.
3. Use Snapshots with different CommandId-s to get OLD/NEW
versions.
But I agreed that the size of parsetrees may be big and for
COPY...FROM/INSERTs we should remember IDs of modified
tuples. Well. Please remember that I implement WAL right
now, already have 1000 lines of code and hope to run first
tests after writing additional ~200 lines -:)
We could read modified tuple IDs from WAL...
Vadim
From bouncefilter Tue Sep 21 10:44:36 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA23779
for <pgsql-hackers@postgresql.org>;
Tue, 21 Sep 1999 10:44:29 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA21709;
Tue, 21 Sep 1999 10:43:51 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] couldn't rollback cache ?
In-reply-to: Your message of Tue, 21 Sep 1999 18:58:54 +0900
<000101bf0417$ea264a00$2801007e@cadzone.tpf.co.jp>
Date: Tue, 21 Sep 1999 10:43:51 -0400
Message-ID: <21707.937925031@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I think this is OK. The sending backend does not send the SI message
in the first place until it has committed. Other backends can read
Doesn't the sending backend send the SI message when Command-
CounterIncrement() is executed ?
AtCommit_Cache() is called not only from CommitTransaction() but
also from CommandCounterIncrement().
Oooh, you are right. I think that is a bug. We should postpone
sending SI messages until commit. Also, if I recall correctly,
CommandCounterIncrement() still gets called after we have decided to
abort the current transaction (while we are eating commands looking for
END or ABORT). It shouldn't do anything to the pending-SI list then
either.
AtCommit_Cache() in CommandCounterIncrement() eats local
invalidation messages and register SI information (this seems too
early for other backends though it's not so harmful). Then AtAtart_
Cache() eats the SI information and invalidates related syscache
and relcache for the backend(this seems right). At this point,invali-
dation info for the backend vanishes. Isn't it right ?
I think it is OK for AtStart_Cache to read *incoming* SI messages,
if those relate to transactions that other backends have committed.
But we should sit on our own list of pending outgoing messages until
we know we are committing (or aborting).
I wonder whether it wouldn't be cleaner to identify the target tuples
by OID instead of ItemPointer. That way would work for both new and
update tuples...
This may be a better way because the cache entry which should be
invalidated are invalidated.
However,we may invalidate still valid cache entry by OID(it's not so
harmful). Even time qualification is useless in this case.
Doesn't bother me --- we'll just re-read it. We'd have to do some work
in that case anyway to verify whether we have the correct copy of the
tuple.
OTOH, your change to add a time qual check
to SearchSysCache would fix that, wouldn't it?
Probably. Because time qualification is applied for uncommitted tuples.
One thing we need to think about here: as it stands, the syscache will
only store a single copy of any particular tuple (maybe I should say
"of a particular OID"). But there might be several copies of that tuple
with different t_min/t_max in the database. With your change to check
time qual, as soon as we realize that the copy we have no longer
SatisfiesNow(), we'll go look for a new copy. And we'll go look
for a new copy after receiving a SI message indicating someone else has
committed an update. The question is, are there any *other* times where
we need to look for a new copy? I think we are OK if we change SI
message sending to only send after commit, but I'm not sure about it.
regards, tom lane
From bouncefilter Tue Sep 21 10:46:34 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA24243
for <pgsql-hackers@postgresql.org>;
Tue, 21 Sep 1999 10:46:29 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id LAA86793;
Tue, 21 Sep 1999 11:45:49 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 21 Sep 1999 11:45:49 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Vince Vielhaber <vev@michvhf.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Lamar Owen <lamar.owen@wgcr.org>, Theo Kramer <theo@flame.co.za>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <199909211402.KAA10588@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909211144590.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 21 Sep 1999, Bruce Momjian wrote:
On Tue, 21 Sep 1999, Thomas Lockhart wrote:
Force the admin to learn what they are doing...if they want to create
short cut scripts, let *them* do it...Damn. You're going to make me read the docs?
IMHO...yes. It would sure eliminate the "how do I change the password
for a user" if the person wanting to change that password had had to read
the docs in the first place, and witih know about the 'with password' part
of 'create user'......and, ummm...don't you have the docs memorized yet? :)
Can we add some output to the createdb command to remind people it can
be done inside psql?
How about something that outputs what its executing?
running 'psql -e "create database <databasename" template1' or something
like that?
Or have the createdb command run 'man createdb' *grin*
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Sep 21 10:52:33 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA25163
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 10:52:26 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id KAA11058;
Tue, 21 Sep 1999 10:52:17 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909211452.KAA11058@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2]
In-Reply-To: <Pine.BSF.4.10.9909211144590.66830-100000@thelab.hub.org> from
The
Hermit Hacker at "Sep 21, 1999 11:45:49 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 21 Sep 1999 10:52:16 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Can we add some output to the createdb command to remind people it can
be done inside psql?How about something that outputs what its executing?
running 'psql -e "create database <databasename" template1' or something
like that?Or have the createdb command run 'man createdb' *grin*
I was thinking:
See the CREATE DATABASE command for more options.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Tue Sep 21 11:02:42 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id LAA27041
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 11:02:34 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m11TRKP-0003kLC; Tue, 21 Sep 99 16:55 MET DST
Message-Id: <m11TRKP-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
To: vadim@krs.ru (Vadim Mikheev)
Date: Tue, 21 Sep 1999 16:55:33 +0200 (MET DST)
Cc: wieck@debis.com, andreas.zeugswetter@telecom.at, hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37E79730.CC415030@krs.ru> from "Vadim Mikheev" at Sep 21,
99 10:33:20 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Jan Wieck wrote:
It is my understanding, that the RI check is performed on the newest
available (committed) data (+ modified data from my own tx).
E.g. a primary key that has been removed by another transaction after
my begin work will lead to an RI violation if referenced as foreign key.Absolutely right. The function that will fire the deferred
triggers must switch to READ COMMITTED isolevel while doing^^^^^^^^^^^^^^
so.
NO!
What if one transaction deleted PK, another one inserted FK
and now both performe RI check? Both transactions _must_
use DIRTY READs to notice that RI violated by another
in-progress transaction and wait for concurrent transaction...
Oh - I see - yes.
BTW, using triggers to check _each_ modified tuple
(i.e. run Executor for each modified tuple) is bad for
performance. We could implement direct support for
standard RI constraints.
As I want to implement it, there would be not much difference
between a regular trigger invocation and a deferred one. If
that causes a performance problem, I think we should speed up
the trigger call mechanism in general instead of not using
triggers.
Using rules (statement level triggers) for INSERT...SELECT,
UPDATE and DELETE queries would be nice! Actually, RI constraint
checks need in very simple queries (i.e. without distinct etc)
and the only we would have to do isWhat I'm not sure about is which snapshot to use to get the
OLD tuples (outdated in this transaction by a previous
command). Vadim?1. Add CommandId to Snapshot.
2. Use Snapshot->CommandId instead of global CurrentScanCommandId.
3. Use Snapshots with different CommandId-s to get OLD/NEW
versions.But I agreed that the size of parsetrees may be big and for
COPY...FROM/INSERTs we should remember IDs of modified
tuples. Well. Please remember that I implement WAL right
now, already have 1000 lines of code and hope to run first
tests after writing additional ~200 lines -:)
We could read modified tuple IDs from WAL...
Not only on COPY. One regular INSERT/UPDATE/DELETE statement
can actually fire thousands of trigger calls right now. These
triggers normally use SPI to execute their own queries. If
such a trigger now uses a query that in turn causes a
deferred constraint, we might have to save thousands of
deferred querytrees - impossible mission.
That's IMHO a clear drawback against using rules for
deferrable RI.
What I'm currently doing is clearly encapsulated in some
functions in commands/trigger.c (except for some additional
attributes in pg_trigger). If it later turns out that we can
combine the information required into WAL, I think we have
time enough to do so and shouldn't really care if v6.6
doesn't have it already combined.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Sep 21 11:15:46 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA30030
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 11:15:11 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id XAA27319;
Tue, 21 Sep 1999 23:15:04 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E7A0F6.9B9E8EC0@krs.ru>
Date: Tue, 21 Sep 1999 23:15:02 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
References: <m11TLQP-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jan Wieck wrote:
Third we need an internal list of triggers that must be
invoked later because at the time an event occured where they
should have been triggered, they appeared in the other list
and their execution is delayed until transaction end or
explicit execution. This list must remember the OID of the
trigger to invoke (to identify the procedure and the
arguments), the relation that caused the trigger and the
CTID's of the OLD and NEW row.That last list could grow extremely! Think of a trigger
that's executing commands over SPI which in turn activate
deferred triggers. Since the order of trigger execution is
very important for RI, I can't see any chance to
simplify/condense this information. Thus it is 16 bytes at
least per deferred trigger call (2 OID's plus 2 CTID's). I
think one or more temp files would fit best for this.A last tricky point is if one of a bunch of deferred triggers
is explicitly called for execution. At this time, the entries
for it in the temp file(s) must get processed and marked
executed (maybe by overwriting the triggers OID with the
invalid OID) while other trigger events still have to get
recorded.
I believe that things are much simpler.
For each deferable constraint (trigger) we have to remember
the LastCommandIdProccessedByConstraint. When the mode of
a constraint changes from defered to immediate (SET CONSTRAINT MODE),
modified tuple will be fetched from WAL from down to up until
tuple modified by LastCommandIdProccessedByConstraint is fetched
and this is show stopper. Now we remember CommandId of
SET CONSTRAINT MODE as new LastCommandIdProccessedByConstraint.
When LastCommandIdProccessedByConstraint is changed by
SET CONSTRAINT MODE DEFERRED we remeber this in flag to
update LastCommandIdProccessedByConstraint later with higher
CommandId of first modification of triggered table (to reduce
amount of data to read from WAL).
?
Vadim
From bouncefilter Tue Sep 21 11:22:35 1999
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 LAA31570
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 11:22:13 -0400 (EDT)
(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 PAA15318;
Tue, 21 Sep 1999 15:21:32 GMT
Sender: lockhart@hub.org
Message-ID: <37E7A27B.6BF226AD@alumni.caltech.edu>
Date: Tue, 21 Sep 1999 15:21:31 +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: Bruce Momjian <maillist@candle.pha.pa.us>
CC: The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2]
References: <199909211452.KAA11058@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Or have the createdb command run 'man createdb' *grin*
I was thinking:
See the CREATE DATABASE command for more options.
I can't help thinking that this thread is trying to solve a problem
that isn't a problem. createdb works fine. You can do more from within
sql. So what? Someone could, if they thought it was a problem, add
more capabilities to createdb, and an admin could choose to use it or
not.
Seems to me that it works just fine for most cases right now; sure
does for me...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Sep 21 11:28:53 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA32866
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 11:27:58 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id AAA03692;
Wed, 22 Sep 1999 00:27:55 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id AAA01357;
Wed, 22 Sep 1999 00:27:55 +0900 (JST)
Message-Id: <199909211527.AAA01357@srapc451.sra.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster disappears
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Tue, 21 Sep 1999 09:59:59 -0400.
<21449.937922399@sss.pgh.pa.us>
Date: Wed, 22 Sep 1999 00:27:55 +0900
Sender: t-ishii@srapc451.sra.co.jp
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
In this case errno=ECHILD has been returned that makes postmaster
exiting. This could happen if SIGCHLD raised between select() call and
the next if (errno=...) statement. One of the solution would be
ignoring ECHILD as well as EINTR. Included are patches for this.Hmm. What you are saying, I guess, is that SIGCHLD is raised,
reaper() executes, and then when control continues in the main loop
the errno left over from reaper()'s last kernel call is what's seen,
instead of the one returned by signal().
Right.
Seems to me that the correct fix is to have reaper() save and restore
the outer value of errno, not to hack the main line to ignore the
most probable state left over from reaper(). Otherwise you still choke
if some other value gets returned from whatever call reaper() does
last.
Not sure. reaper() may be called while reaper() is executing if a new
SIGCHLD is raised. How do you handle this case?
Moreover, you're not actually checking what the select() did unless
you do it that way.
Sorry, I don't understand this. Can you explain, please?
Curious that this sort of problem is not seen more often --- I wonder
if most Unixes arrange to save/restore errno around a signal handler
for you?
Maybe because the situation I have pointed out is relatively rare.
---
Tatsuo Ishii
From bouncefilter Tue Sep 21 11:36:37 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id LAA34608
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 11:35:55 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11TRqd-0003kLC; Tue, 21 Sep 99 17:28 MET DST
Message-Id: <m11TRqd-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
To: vadim@krs.ru (Vadim Mikheev)
Date: Tue, 21 Sep 1999 17:28:51 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37E7A0F6.9B9E8EC0@krs.ru> from "Vadim Mikheev" at Sep 21,
99 11:15:02 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Vadim wrote:
I believe that things are much simpler.
For each deferable constraint (trigger) we have to remember
the LastCommandIdProccessedByConstraint. When the mode of
a constraint changes from defered to immediate (SET CONSTRAINT MODE),
modified tuple will be fetched from WAL from down to up until
tuple modified by LastCommandIdProccessedByConstraint is fetched
and this is show stopper. Now we remember CommandId of
SET CONSTRAINT MODE as new LastCommandIdProccessedByConstraint.
When LastCommandIdProccessedByConstraint is changed by
SET CONSTRAINT MODE DEFERRED we remeber this in flag to
update LastCommandIdProccessedByConstraint later with higher
CommandId of first modification of triggered table (to reduce
amount of data to read from WAL).
Hmmm,
I'm not sure what side effects it could have if the triggers
at the time of
SET CONSTRAINTS c1, c2 IMMEDIATE
arent fired in the same order they have been recorded - must
think about that for a while. In that case I must be able to
scan WAL from one command ID until another regardless of the
resultrelation. Is that possible?
Another issue is this: isn't it possible to run a database
(or maybe an entire installation) without WAL? Does it make
the code better maintainable to have WAL and RI coupled that
strong?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Sep 21 11:50:37 1999
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA38454
for <hackers@postgresql.org>; Tue, 21 Sep 1999 11:49:39 -0400 (EDT)
(envelope-from andreas.zeugswetter@telecom.at)
Received: from telecom.at (w0188000580.f000.d0188.sd.spardat.at
[172.18.65.249])
by gandalf.telecom.at (xxx/xxx) with ESMTP id RAA221682
for <hackers@postgresql.org>; Tue, 21 Sep 1999 17:49:08 +0200
Message-ID: <37E7A8F1.B0830950@telecom.at>
Date: Tue, 21 Sep 1999 17:49:05 +0200
From: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgresql.org
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Vadim wrote:
Absolutely right. The function that will fire the deferred
triggers must switch to READ COMMITTED isolevel while doing^^^^^^^^^^^^^^
so.
NO!
What if one transaction deleted PK, another one inserted FK
and now both performe RI check? Both transactions _must_
use DIRTY READs to notice that RI violated by another
in-progress transaction and wait for concurrent transaction...
I think we need some kind of lock on the PK table row.
This is because a rollback must allways work.
(If tx1 (insert PK) wants a rollback after tx2 did insert FK
this cannot throw a RI Violation)
I don't think we can read dirty.
We have to wait for PK lock, and decide after tx1 commited/rolled back.
On timeout we decide as follows:
Even if above tx1 (insert PK) is committed later,
we throw an error for tx2 (insert FK).
Also if a pk row is deleted/updated/inserted but not committed yet,
we ignore both old and new value for the FK check of tx2
after timeout and violate tx2.
A lock mode wait 0 would be convenient here.
Everything else imho leads to a violated integrity.
Andreas
From bouncefilter Tue Sep 21 12:06:35 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA42338
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 12:05:58 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id MAA13210;
Tue, 21 Sep 1999 12:05:58 -0400
Message-ID: <37E7ACDF.A5F6F9E9@wgcr.org>
Date: Tue, 21 Sep 1999 12:05:51 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Vince Vielhaber <vev@michvhf.com>
CC: The Hermit Hacker <scrappy@hub.org>, hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <XFMail.990920215229.vev@michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Vince Vielhaber wrote:
it, it's a big package - well worth the effort to learn it, but it's still
big. So after putting the poor newbie thru all of this trauma you want to
further traumatize him/her with man pages? :)
You know, in two years I gotten quite cozy with PostgreSQL -- but at the
beginning it was not so. I remember how it felt to FIRST install -- it
WAS intimidating.
Let's just take a look at HOW big postgresql has become: the tarball is
over six megabytes. It decompresses to around 23 megabytes. That is
half the size of the Linux Kernel sources, twice the size of a minimal
Windows 95 installation, and three times the size of a complete Windows
3.1 installation.
My first hard drive on my ancient TRS-80 model 4 was 10 megabytes, and
it seemed huge. The PostgreSQL source tree is two times larger than the
maximum volume size for that OS! In fact, a source tree that has
completed a make is bigger than the largest volume size for MS-DOS
versions prior to 4.0!
It has a ways to go to beat the 260+MB Oracle 8i installation package,
but it's still a big package.
It takes my Pentium 133 laptop running RedHat 6.0 a full 45 minutes to
build an RPM set -- that's a ./configure; make; make install sequence
with several other operations added on. A machine that can do over 100
MIPS takes 45 minutes. Think about it.
I have to say that I agree with Marc on this one, and, Vince, you are
the one who convinced me.
If a newbie (to PostgreSQL) can successfully install from source, then
said newbie won't have a single problem reading a man page. Even with
the RPM packaging -- if a newbie can find out that you need to su to
postgres and run psql to get at the data (or set up some other client),
then said newbie really doesn't care whether the create db is a script
executed from the unix shell or an SQL command executed from psql.
Whether it's a shell script or a psql command is irrelevant -- the
newbie is having to learn a new command either way.
IMHO
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Tue Sep 21 12:13:36 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA43735
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 12:13:29 -0400 (EDT)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id AAA27547;
Wed, 22 Sep 1999 00:13:15 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E7AE99.84225367@krs.ru>
Date: Wed, 22 Sep 1999 00:13:13 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: andreas.zeugswetter@telecom.at, hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
References: <m11TRKP-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jan Wieck wrote:
But I agreed that the size of parsetrees may be big and for
COPY...FROM/INSERTs we should remember IDs of modified
tuples. Well. Please remember that I implement WAL right
now, already have 1000 lines of code and hope to run first
tests after writing additional ~200 lines -:)
We could read modified tuple IDs from WAL...Not only on COPY. One regular INSERT/UPDATE/DELETE statement
can actually fire thousands of trigger calls right now. These
^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes, because of we have not Statement Level Triggers (SLT).
Deferred SLT would require us to remember _one_ parsertree for each
statement, just like deferred rules.
triggers normally use SPI to execute their own queries. If
such a trigger now uses a query that in turn causes a
deferred constraint, we might have to save thousands of
^^^^^^^^^^^^^^^^^^^^^
deferred querytrees - impossible mission.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Why should we save _thousands_ of querytrees in the case
of row level trigger (I assume you mean one querytree for
each modified tuple)?
As I described in prev letter - we have to remember just
LastCommandIdProccessedByConstraint to stop fetching
tuples from WAL.
BTW, this is what sql3-12aug93 says about triggers and RI:
22)If the <trigger event> specifies UPDATE, then let Ci be the i-th
<column name> in the <trigger column list>.
/* i.e UPDATE OF C1,..Cj */
T shall not be the referencing table in any <referential
constraint definition> that specifies ON UPDATE CASCADE,
ON UPDATE SET NULL, ON UPDATE SET DEFAULT, ON DELETE SET NULL,
or ON DELETE SET DEFAULT and contains a <reference column list>
that includes Ci.
Interesting?
Vadim
From bouncefilter Tue Sep 21 12:19:42 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA44819
for <hackers@postgresql.org>; Tue, 21 Sep 1999 12:19:08 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id MAA13227;
Tue, 21 Sep 1999 12:18:47 -0400
Message-ID: <37E7AFE0.F9E8EC2D@wgcr.org>
Date: Tue, 21 Sep 1999 12:18:40 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Vince Vielhaber <vev@michvhf.com>, The Hermit Hacker <scrappy@hub.org>,
hackers@postgresql.org
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <199909210247.WAA27574@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
big. So after putting the poor newbie thru all of this trauma you want to
further traumatize him/her with man pages? :)I agree our INSTALL is very large. Is there some way we can simplify
the install process?
rpm --install postgresql*.rpm (or dpkg postgresql*.deb)
;-P
(I just HAD to do that.....) And, RPM will successfully install on more
than just RedHat Linux. See www.rpm.org
Frankly, the installation (unless you are munging it into an
FHS-compliant package) is a piece of cake as it is (of course, I say
that with two years of PostgreSQL experience under my belt). It
certainly is one of the easiest to install amongst packages of equal
size.
Most people who come to know PostgreSQL either:
1.) Get it on their Linux CD;
2.) Heard about it from their sysadmin friends;
3.) Heard about it from someone who installed from a Linux CD;
4.) Heard about it from the documentation of whatever application/web
server they're using.
In my case, it was number 4, as RedHat hadn't yet shipped it when I read
about it in the AOLserver documentation.
The only true "newbies" are in groups 1 and 3, as the others have some
experience with system administration. And for those groups, it is
going in as an RPM or other package (such as Oliver's .deb).
Are there any OS's other than Linux where PostgreSQL is being shipped as
a stock part of the OS?? Given its BSD license, I would think the
*BSD's would be shipping it.
All we can really do is provide better and better documentation, which
has been getting MUCH better than the halcyon days of 6.1.1 (which was
my first version to install).
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Tue Sep 21 12:36:35 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA48650
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 12:36:00 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
KAA06668;
Tue, 21 Sep 1999 10:35:33 -0600 (MDT)
Date: Tue, 21 Sep 1999 10:35:33 -0600 (MDT)
Message-Id: <199909211635.KAA06668@biology.nmsu.edu>
X-Authentication-Warning: biology.nmsu.edu: brook set sender to
brook@biology.nmsu.edu using -f
From: Brook Milligan <brook@biology.nmsu.edu>
To: lamar.owen@wgcr.org
CC: maillist@candle.pha.pa.us, vev@michvhf.com, scrappy@hub.org,
hackers@postgreSQL.org
In-reply-to: <37E7AFE0.F9E8EC2D@wgcr.org> (message from Lamar Owen on Tue, 21
Sep 1999 12:18:40 -0400)
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <199909210247.WAA27574@candle.pha.pa.us>
<37E7AFE0.F9E8EC2D@wgcr.org>
Are there any OS's other than Linux where PostgreSQL is being shipped as
a stock part of the OS?? Given its BSD license, I would think the
*BSD's would be shipping it.
NetBSD includes postgresql as a component of the package system.
Cheers,
Brook
From bouncefilter Tue Sep 21 12:45:35 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id MAA50172
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 12:44:56 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 14352 invoked by uid 1001); 21 Sep 1999 16:44:58 -0000
Date: Tue, 21 Sep 1999 12:44:58 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Brook Milligan <brook@biology.nmsu.edu>
cc: lamar.owen@wgcr.org, maillist@candle.pha.pa.us, scrappy@hub.org,
hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <199909211635.KAA06668@biology.nmsu.edu>
Message-ID: <Pine.BSF.4.05.9909211244430.14017-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 21 Sep 1999, Brook Milligan wrote:
Are there any OS's other than Linux where PostgreSQL is being shipped as
a stock part of the OS?? Given its BSD license, I would think the
*BSD's would be shipping it.NetBSD includes postgresql as a component of the package system.
Ditto FreeBSD.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Tue Sep 21 13:15:35 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA56721
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 13:15:16 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id NAA13385;
Tue, 21 Sep 1999 13:14:57 -0400
Message-ID: <37E7BD0A.3FC94FE1@wgcr.org>
Date: Tue, 21 Sep 1999 13:14:50 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Brook Milligan <brook@biology.nmsu.edu>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <199909210247.WAA27574@candle.pha.pa.us>
<37E7AFE0.F9E8EC2D@wgcr.org>
<199909211635.KAA06668@biology.nmsu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Brook Milligan wrote:
Are there any OS's other than Linux where PostgreSQL is being shipped as
a stock part of the OS?? Given its BSD license, I would think the
*BSD's would be shipping it.NetBSD includes postgresql as a component of the package system.
Ah! Good.
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Tue Sep 21 13:19:35 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA57246
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 13:19:01 -0400 (EDT)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id BAA27772;
Wed, 22 Sep 1999 01:18:57 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E7BDFF.D6EB9124@krs.ru>
Date: Wed, 22 Sep 1999 01:18:55 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
References: <37E7A8F1.B0830950@telecom.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Andreas Zeugswetter wrote:
What if one transaction deleted PK, another one inserted FK
and now both performe RI check? Both transactions _must_
use DIRTY READs to notice that RI violated by another
in-progress transaction and wait for concurrent transaction...I think we need some kind of lock on the PK table row.
Modified tuples are locked by the fact that t_xmin/t_xmax
is/are in-progress. DIRTY READ allows to see that tuples
is being modified. I supposed to use some function to wait
concurrent transaction commit/abort.
This is because a rollback must allways work.
(If tx1 (insert PK) wants a rollback after tx2 did insert FK
this cannot throw a RI Violation)
tx2 can't commit till tx1 is in-progress, right?
More of that, if tx2 is in serializable mode and there was
no PK committed before tx2 began (i.e. visible to tx2 queries)
then this should result in tx2 abort, imho.
I don't think we can read dirty.
We have to wait for PK lock, and decide after tx1 commited/rolled back.
Yes, but select _never_ waits and READ COMMITTED never sees
uncommitted concurrent changes. That's why I propose to use
DIRTY READ (to see) and function (to wait).
If two tx-s will wait one another then one of them will be
aborted (deadlock condition) and another will continue to
perform constraint check.
On timeout we decide as follows:
Why timeout should be used?
Even if above tx1 (insert PK) is committed later,
we throw an error for tx2 (insert FK).
I'm not sure that we should abort tx2 running in READ COMMITTED
mode.
Also if a pk row is deleted/updated/inserted but not committed yet,
we ignore both old and new value for the FK check of tx2
after timeout and violate tx2.
Why should we abort tx2 if pk is deleted but uncommitted yet?
In the case of tx1 (delete pk) abort we could let tx2 inserts
fk. Why not?
A lock mode wait 0 would be convenient here.
Everything else imho leads to a violated integrity.
Vadim
From bouncefilter Tue Sep 21 14:53:42 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id OAA72516
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 14:52:56 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11TUvX-0003kLC; Tue, 21 Sep 99 20:46 MET DST
Message-Id: <m11TUvX-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: RI question
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Tue, 21 Sep 1999 20:46:06 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Uh oh,
I think deferred RI constraints must only fire the actions
that remain after all commands during the entire transaction
are condensed to the total minimum required to get that
state, because deferred RI must only check what VISIBLY
happened during the transaction.
Thinking on the tuple level, a sequence of
INSERT,UPDATE,UPDATE must fire only one INSERT trigger, but
with the values of the last UPDATE. An UPDATE,DELETE sequence
is in fact a DELETE of the original tuple and an
INSERT,UPDATE,DELETE sequence is nothing.
That means that the recording mechnism of the trigger events
must be very smart on UPDATE and DELETE events, looking at
the x_min of the old tuple if that resulted from the current
transaction. If so, follow the events backward, disable
previous ones and change the new event into what it really
has to be.
But some problems remain unsolvable by this:
- PK has an ON DELETE CASCADE for FK
- BEGIN
- DELETE PK
- INSERT same PK
- COMMIT.
This really shouldn't invoke the cascading delete, because at
COMMIT the PK still is there. Same for a constraint that
forbids deletion of a PK while referenced by FK. Therefore
the deferred event recorder must check on INSERT any previous
DELETES for the same relation if the key does match and drop
both deferred triggers if so. Therefore it needs to know
which attributes build the PK of that relation
(<relname>_pkey guaranteed?).
Well, I think that's finally the death of RI over rules. The
code managing those rules during CREATE/ALTER TABLE would
become totally unmaintainable. And (sorry Vadim) it's the
death of SLT for this too because this event tracking must be
done on the tuple level.
It complicated the trigger approach too, but IMHO not too
bad. Anyway, some co-developer(s) doing the parser- and
utility-statement stuff (SET CONSTRAINTS ... etc.) would be
great.
Volunteers?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Sep 21 15:04:36 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA74231
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 15:03:45 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA89407;
Tue, 21 Sep 1999 16:02:59 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 21 Sep 1999 16:02:55 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2]
In-Reply-To: <199909211452.KAA11058@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909211602360.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 21 Sep 1999, Bruce Momjian wrote:
Can we add some output to the createdb command to remind people it can
be done inside psql?How about something that outputs what its executing?
running 'psql -e "create database <databasename" template1' or something
like that?Or have the createdb command run 'man createdb' *grin*
I was thinking:
See the CREATE DATABASE command for more options.
In bold, flashing letters? :)
Ya, that would be perfect...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Sep 21 15:10:39 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA75314
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 15:10:38 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id DAA28172;
Wed, 22 Sep 1999 03:10:31 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E7D825.EDA139C5@krs.ru>
Date: Wed, 22 Sep 1999 03:10:29 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
References: <m11TRqd-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jan Wieck wrote:
I'm not sure what side effects it could have if the triggers
at the time ofSET CONSTRAINTS c1, c2 IMMEDIATE
arent fired in the same order they have been recorded - must
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Did you mean - in the same order as tables were modified?
think about that for a while. In that case I must be able to
scan WAL from one command ID until another regardless of the
resultrelation. Is that possible?
WAL records are in the same order as tuples (regardless of
result relation) was modified. Example: UPDATE of T1
fires (immediate) after row trigger inserting tuple
into T2. WAL records:
--> up
{old_T1_tuple version ID, new_T1_tuple version ID and values}
{new_T2_tuple ID and values}
...
T1 update record
T2 insert record
...
--> down
But records will be fetched from WAL in reverse order, from
down to up.
Does it matter?
Order of modifications made by UPDATE/DELETE is undefined.
Though, order has some sence for INSERT ... SELECT ORDER BY -:)
Nevertheless, I don't see in standard anything about order
of constraint checks.
BTW, I found what standard means by "immediate":
---
The checking of a constraint depends on its constraint mode within
the current SQL-transaction. If the constraint mode is immediate,
| then the constraint is effectively checked at the end of each
^^^^^^^^^^^^^^^^^^
| ___________________________________________________________________
| ANSI Only-SQL3
| ___________________________________________________________________
| SQL-statement S, unless S is executed because it is a <triggered
^^^^^^^^^^^^^^^
| SQL statement>, in which case, the constraint is effectively
| checked at the end of the SQL-statement that is the root cause
| of S.
---
And now about triggers (regardless of ROW or STATEMENT level!):
---
4.22.2 Execution of triggered actions
The execution of triggered actions depends on the cursor mode of
the current SQL-transaction. If the cursor mode is set to cascade
off, then the execution of the <triggered SQL statement>s is effec-
tively deferred until enacted implicitly be execution of a <commit
statement> or a <close statement>. Otherwise, the <triggered SQL
statement>s are effectively executed either before or after the
^^^^^^^^^^^^^^^^^^^
execution of each SQL-statement, as determined by the specified
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<trigger action time>.
---
Hm.
Another issue is this: isn't it possible to run a database
(or maybe an entire installation) without WAL? Does it make
Do you worry about disk space? -:)
With archive mode off only log segments (currently, 64M each)
required by active transactions (which made some changes)
will present on disk.
the code better maintainable to have WAL and RI coupled that
strong?
This doesn't add any complexity to WAL manager.
Vadim
From bouncefilter Tue Sep 21 15:15:46 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA75865
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 15:14:42 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id DAA28185;
Wed, 22 Sep 1999 03:14:38 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37E7D91E.781B5244@krs.ru>
Date: Wed, 22 Sep 1999 03:14:38 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] RI question
References: <m11TUvX-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jan Wieck wrote:
Uh oh,
Well, it's time for me to do some other work, so I'll
return to discussion later.
Good luck.
Vadim
From bouncefilter Tue Sep 21 15:21:37 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA77171
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 15:21:17 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA89548;
Tue, 21 Sep 1999 16:19:44 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 21 Sep 1999 16:19:44 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Brook Milligan <brook@biology.nmsu.edu>
cc: lamar.owen@wgcr.org, maillist@candle.pha.pa.us, vev@michvhf.com,
hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <199909211635.KAA06668@biology.nmsu.edu>
Message-ID: <Pine.BSF.4.10.9909211619200.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 21 Sep 1999, Brook Milligan wrote:
Are there any OS's other than Linux where PostgreSQL is being shipped as
a stock part of the OS?? Given its BSD license, I would think the
*BSD's would be shipping it.NetBSD includes postgresql as a component of the package system.
FreeBSD as both ports/package...but not part of standard install...we
don't really use it for anything as part of the OS...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Sep 21 15:36:41 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA80143
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 15:36:22 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id PAA14266;
Tue, 21 Sep 1999 15:26:08 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909211926.PAA14266@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <199909211635.KAA06668@biology.nmsu.edu> from Brook Milligan at
"Sep 21, 1999 10:35:33 am"
To: Brook Milligan <brook@biology.nmsu.edu>
Date: Tue, 21 Sep 1999 15:26:08 -0400 (EDT)
CC: lamar.owen@wgcr.org, vev@michvhf.com, scrappy@hub.org,
hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Are there any OS's other than Linux where PostgreSQL is being shipped as
a stock part of the OS?? Given its BSD license, I would think the
*BSD's would be shipping it.NetBSD includes postgresql as a component of the package system.
BSDI is considering it.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Tue Sep 21 15:16:37 1999
Received: from cse.uta.edu (cse.uta.edu [129.107.12.1])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA76218
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 15:15:38 -0400 (EDT)
(envelope-from dson@cse.uta.edu)
Received: from localhost by cse.uta.edu (8.9.0/8.9.0) with SMTP id OAA06544
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 14:27:25 -0500 (CDT)
Date: Tue, 21 Sep 1999 14:27:25 -0500 (CDT)
From: Dae Weon Son <dson@cse.uta.edu>
X-Sender: dson@cse
To: pgsql-hackers@postgreSQL.org
Subject: unsubscribe
Message-ID: <Pine.GSO.3.96.990921142703.5755A-100000@cse>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
unsubscribe
From bouncefilter Tue Sep 21 15:42:37 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA81177
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 15:41:59 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id PAA15682;
Tue, 21 Sep 1999 15:40:23 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909211940.PAA15682@candle.pha.pa.us>
Subject: Re: [HACKERS] Partial fix for INSERT...SELECT problems
In-Reply-To: <27787.927495974@sss.pgh.pa.us> from Tom Lane at "May 23,
1999 05:46:14 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 21 Sep 1999 15:40:23 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tom, is this fixed?
I have committed some fixes that prevent resjunk targets from being
assigned to output columns in an INSERT/SELECT. This partially fixes
the problem Michael Davis reported a few weeks ago. However, there's
still a bug with confusion about column names. Givencreate table foo (a int4, b int4);
CREATE
create table bar (c int4, d int4);
CREATEwe can do
select c, sum(d) from bar group by c;
but not
insert into foo select c, sum(d) from bar group by c;
ERROR: Illegal use of aggregates or non-group column in target listThe problem here is that the target expressions of the select have
been relabeled with foo's column names before GROUP BY is processed.
If you refer to them by the output column names then it works:insert into foo select c, sum(d) from bar group by a;
INSERT 279412 1You can think of the query as having been rewritten to
insert into foo select c AS a, sum(d) AS b from bar group by a;
in which case the behavior makes some kind of sense. However,
I think that this behavior is neither intuitive nor in conformance
with SQL92's scoping rules. As far as I can tell, the definition
of the result of "select c, sum(d) from bar group by c" is independent
of whether it is inside an INSERT or not.Fixing this appears to require a substantial rearrangement of code
inside the parser, which I'm real hesitant to do with only a week to go
till 6.5 release. I propose leaving this issue on the "to fix" list for
6.6. Comments?BTW, although Davis claimed this was broken sometime during April, 6.4.2
shows the same bugs ... I think it's been wrong for a long time.regards, tom lane
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Tue Sep 21 15:44:40 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA81510
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 15:44:32 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id PAA15704;
Tue, 21 Sep 1999 15:42:31 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909211942.PAA15704@candle.pha.pa.us>
Subject: Re: [HACKERS] strange behavior of UPDATE
In-Reply-To: <2022.927598598@sss.pgh.pa.us> from Tom Lane at "May 24,
1999 10:16:38 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 21 Sep 1999 15:42:31 -0400 (EDT)
CC: Edmund Mergl <E.Mergl@bawue.de>,
PostgreSQL Hackers Mailinglist <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tom, I assume this is done, right?
I wrote:
then a possible explanation for the problem would be that our
btree index code isn't very fast when there are large numbers of
identical keys.Ah-hah, a lucky guess! I went back and looked at the profile stats
I'd extracted from Edmund's "update" example. This Linux box has
the same semi-functional gprof as someone else was using a while
ago --- the timings are bogus, but the call counts seem right.
And what I find are entries like this:0.00 0.00 284977/284977 _bt_binsrch [3174]
[3177] 0.0 0.00 0.00 284977 _bt_firsteq [3177]
0.00 0.00 21784948/24713758 _bt_compare [3169]0.00 0.00 426/35632 _bt_split [53]
0.00 0.00 35206/35632 _bt_insertonpg [45]
[3185] 0.0 0.00 0.00 35632 _bt_findsplitloc [3185]
0.00 0.00 5093972/8907411 _bt_itemcmp [3171]In other words, _bt_firsteq is averaging almost 100 comparisons per
call, _bt_findsplitloc well over that. Both of these routines are
evidently designed on the assumption that there will be relatively
few duplicate keys --- they reduce to linear scans when there are
many duplicates._bt_firsteq shouldn't exist at all; the only routine that calls it
is _bt_binsrch, which does a fast binary search of the index page.
_bt_binsrch should be fixed so that the binary search logic does the
right thing for equal-key cases, rather than degrading to a linear
search. I am less confident that I understand _bt_findsplitloc's place
in the great scheme of things, but it could certainly be revised to use
a binary search rather than linear scan.This benchmark is clearly overemphasizing the equal-key case, but
I think it ought to be fixed independently of whether we want to
look good on a dubious benchmark ... equal keys are not uncommon in
real-world scenarios after all.Next question is do we want to risk twiddling this code so soon before
6.5, or wait till after?regards, tom lane
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Tue Sep 21 15:46:37 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA81954
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 15:45:43 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id PAA15774;
Tue, 21 Sep 1999 15:44:07 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909211944.PAA15774@candle.pha.pa.us>
Subject: Re: [HACKERS] INSERT INTO view means what exactly?
In-Reply-To: <2981.927643359@sss.pgh.pa.us> from Tom Lane at "May 25,
1999 10:42:39 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 21 Sep 1999 15:44:07 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Does anyone know a cause for this?
With current sources:
regression=> CREATE TABLE x (y text);
CREATE
regression=> CREATE VIEW z AS select * from x;
CREATE
regression=> INSERT INTO x VALUES ('foo');
INSERT 411635 1
regression=> INSERT INTO z VALUES ('bar');
INSERT 411636 1
regression=> select * from x;
y
---
foo
(1 row)regression=> select * from z;
y
---
foo
(1 row)OK, where'd tuple 411636 go? Seems to me that the insert should either
have been rejected or caused an insert into x, depending on how
transparent you think views are (I always thought they were
read-only?). Dropping the data into never-never land and giving a
misleading success response code is not my idea of proper behavior.regards, tom lane
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Tue Sep 21 15:48:38 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA82299
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 15:48:00 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id PAA15803;
Tue, 21 Sep 1999 15:46:24 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909211946.PAA15803@candle.pha.pa.us>
Subject: Re: [HACKERS] inherited GROUP BY is busted ... I need some help here
In-Reply-To: <5098.928377620@sss.pgh.pa.us> from Tom Lane at "Jun 2,
1999 10:40:20 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 21 Sep 1999 15:46:24 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tom, is this still an open item?
I've been chasing Chris Bitmead's coredump report from earlier today.
I find that it can be reproduced very easily. For example:
regression=> select f1 from int4_tbl group by f1;
< no problem >
regression=> select f1 from int4_tbl* group by f1;
< core dump >(You may get unstable behavior rather than a reliable core dump
if you are not configured --enable-cassert.)The problem seems to be in optimizer/plan/planner.c, which is
responsible for creating the Sort and Group plan nodes needed to
implement GROUP BY. It also has to mark the lower plan's targetlist
items with resdom->reskey numbers so that the executor will know which
items to use for sort keys (cf. FormSortKeys in executor/nodeSort.c).
The trouble is that that latter marking is done in planner.c's
make_subplanTargetList(), which *is never invoked* for a query that
involves inheritance. union_planner() only calls it if the given plan
involves neither UNION nor inheritance. In the UNION case, recursion
into union_planner does the right thing, but not so in the inheritance
case.I rewrote some of this code a couple months ago, but I find that 6.4.2
has similar problems, so at least I can say I didn't break it ;-).It seems clear that at least some of the processing that union_planner
does in the simple case (the "else" part of its first big if-then-else)
also needs to be done in the inheritance case (and perhaps also in
the UNION case?). But I'm not sure exactly what. There's a lot going
on in this chunk of code, and I don't understand very much of it.
I could really use some advice...regards, tom lane
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Tue Sep 21 15:55:40 1999
Received: from postal.dn.net (postal.dn.net [207.226.170.20])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA83587
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 15:54:57 -0400 (EDT)
(envelope-from frankpit@pop.dn.net)
Received: from pop.dn.net (pm-13.ppp.wdc.dn.net [207.226.188.13])
by postal.dn.net (8.9.3/postal) with ESMTP id PAA23170
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 15:54:21 -0400 (EDT)
Sender: matuser@postal.dn.net
Message-ID: <37E7E7F8.55FE1A8B@pop.dn.net>
Date: Tue, 21 Sep 1999 20:18:00 +0000
From: Bernard Frankpitt <frankpit@pop.dn.net>
Organization: AIMS
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.32 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Early evaluation of constant expresions (with PATCH)
Content-Type: multipart/mixed; boundary="------------9D0AFDFB6B8EF6EBFF89AD94"
This is a multi-part message in MIME format.
--------------9D0AFDFB6B8EF6EBFF89AD94
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi All,
Summary of the problem:
I have another patch for a problem that I have run across, I describe
the problem, the solution I propose, and I have included the patch as
an attachment.
The problem is that given two queries of the form
SELECT <target list> FROM <range table>
WHERE <var> <op> <function> (<const>);
and
SELECT <target list> FROM <range table>
WHERE <var> <op> <const>;
and a usable index on the table attribute corresponds to <var>,
PostgreSQL will process the queries in different ways. Where the
second query will use the index, the <function> in the first index
will fool the optimizer into missing the index even though it is
applicable.
Example:
------------------------------------------------------------------------
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.1 on i686-pc-linux-gnu, compiled by gcc 2.7.2.3]
type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: bernie
bernie=> \i ../pgsql6_6/test.sql
CREATE TABLE t1 (a1 int4);
CREATE
CREATE INDEX t1_idx ON t1 USING btree (a1);
CREATE
CREATE FUNCTION sqr (int4) RETURNS int4
AS 'SELECT ($1)*($1)'
LANGUAGE 'sql';
CREATE
INSERT INTO t1 VALUES (1);
INSERT 188236 1
" " " " " " " "
INSERT INTO t1 VALUES (10);
INSERT 188245 1
-- Select with predicate of the form <var> <op> <const>
SELECT * FROM t1 WHERE t1.a1=5;
a1
--
5
(1 row)
EXPLAIN SELECT * FROM t1 WHERE t1.a1=5;
NOTICE: QUERY PLAN:
Index Scan using t1_idx on t1 (cost=2.05 rows=1 width=4)
EXPLAIN
-- Select with predicate of the form <var> <op> <function> (<const>)
SELECT * FROM t1 WHERE t1.a1 = sqr(2);
a1
--
4
(1 row)
EXPLAIN SELECT * FROM t1 WHERE t1.a1 = sqr(2);
NOTICE: QUERY PLAN:
Seq Scan on t1 (cost=43.00 rows=100 width=4)
EXPLAIN
EOF
-------------------------------------------------------------------------
Cause:
The cause of the problem is in the match_clause_to_indexkey() In
optimizer/path/indxpath.c. The comment before the function says
* To match, the clause:
*
* (1a) for a restriction clause: must be in the form (indexkey
op const)
* or (const op indexkey), or
So the routine that matches a restriction clause to an index is not
smart enough to realize that a function of constant arguments is
really a constant.
Solution:
The solution that I propose is to include code in the optimizer that
picks functions with constant arguments out of a qualification
clause, and evaluates them. If sub-expression tree in a qual node
only consists of functions, operators, boolean nodes, and constants,
then it should evaluate to a constant node. It would be possible to
scan for such subtrees in the parser without evaluating them, but it
seems to me that doing the evaluation early is an optimization, and a
simplification of the planner and executor trees.
I have implemented the solution by adding a tree mutator called
eval_const_expr_mutator() to optimizer/util/clauses.c. This mutator
calls ExecEvalExpr() from executor/execQual.c to do the actual
evaluation. The ExpressionContext argument to ExecEvalExpr() is
assigned a null pointer. This hack works, because the tree that is
being evaluated contains only constant nodes, The only code called by
ExecEvalExpr() that needs the econtext is code that resolves parameter
and variable nodes. The eval_const_expr_mutator() uses the fields in
the fcache structure that ExecEvalExpr() creates to construct the
Const node that it returns.
I don't know how you all feel about mixing code from the executor and
the planner in this way, but it if you accept early evaluation of
constant functions in the planner, then there has to be some common
functionality between the two sections. I would be happy to hear
suggestions for a better way to abstract the interface to the
evaluation code so that the executor and planner see a common neutral
interface.
Finally, there is the question of where in the planner should the
early evaluation occur. It is not obvious to me where the best point
is, I chose to put it in
plan/initsplan.c:add_restrict_and_join_to_rels(). The function
add_restrict_and_join_to_rels() loops through the list of qual
clauses, and adds the join and restriction information to the
RelOptInfo nodes for the realtions that participate in the qual clauses.
The function becomes:
void
add_restrict_and_join_to_rels(Query *root, List *clauses)
{
List *clause;
foreach(clause, clauses)
{
clause = eval_const_expr_in_quals(clause)
add_restrict_and_join_to_rel(root, (Node*)
lfirst(clause));
}
}
This choice means that evaluation is performed right before the call
to make_one_rel() in planmain.c:subplanner().
Results:
With the patch the second SELECT statement in the example becomes
------------------------------------------------------------------------
bernie=> SELECT * FROM t1 WHERE t1.a1 = sqr(2);
a1
--
4
(1 row)
bernie=>
bernie=> EXPLAIN SELECT * FROM t1 WHERE t1.a1 = sqr(2);
NOTICE: QUERY PLAN:
Index Scan using t1_idx on t1 (cost=2.50 rows=10 width=4)
EXPLAIN
------------------------------------------------------------------------
That's a long explanation for a small patch, but hacking this stuff is
a little like walking on hot stones --- you want to be sure that you
are doing it right before you get burnt.
Bernie Frankpitt
-------------------------------------------------------------------------
Patch attached:
Note: I pgindent'ed both the .orig and the new files before making the
patch
--------------9D0AFDFB6B8EF6EBFF89AD94
Content-Type: application/octet-stream;
name="ConstExprPatch.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="ConstExprPatch.patch"
KioqIC4vc3JjL2JhY2tlbmQvb3B0aW1pemVyL3BsYW4vaW5pdHNwbGFuLmMub3JpZwlUdWUg
U2VwIDIxIDE2OjM4OjExIDE5OTkKLS0tIC4vc3JjL2JhY2tlbmQvb3B0aW1pemVyL3BsYW4v
aW5pdHNwbGFuLmMJVHVlIFNlcCAyMSAxNjo0NzozMSAxOTk5CioqKioqKioqKioqKioqKgoq
KiogMTM0LDE0MCAqKioqCi0tLSAxMzQsMTQzIC0tLS0KICAJTGlzdAkgICAqY2xhdXNlOwog
IAogIAlmb3JlYWNoKGNsYXVzZSwgY2xhdXNlcykKKyAJeworIAkJY2xhdXNlID0gKExpc3Qg
KikgZXZhbF9jb25zdF9leHByZXNzaW9ucygoTm9kZSAqKSBjbGF1c2UsIE5VTEwpOwogIAkJ
YWRkX3Jlc3RyaWN0X2FuZF9qb2luX3RvX3JlbChyb290LCAoTm9kZSAqKSBsZmlyc3QoY2xh
dXNlKSk7CisgCX0KICB9CiAgCiAgLyoKKioqIC4vc3JjL2JhY2tlbmQvb3B0aW1pemVyL3V0
aWwvY2xhdXNlcy5jLm9yaWcJVHVlIFNlcCAyMSAxNjozODoxMiAxOTk5Ci0tLSAuL3NyYy9i
YWNrZW5kL29wdGltaXplci91dGlsL2NsYXVzZXMuYwlUdWUgU2VwIDIxIDE2OjQ3OjMxIDE5
OTkKKioqKioqKioqKioqKioqCioqKiA3NjUsNzcwICoqKioKLS0tIDc2NSw4OTggLS0tLQog
IAlsc2Vjb25kKGNsYXVzZS0+YXJncykgPSB0ZW1wOwogIH0KICAKKyAvKgorICAgIEEgbXV0
YXRvciB0aGF0IGRlc3RydWN0aXZlbHkgbW9kaWZpZXMgdGhlIGlucHV0IHRyZWUgYnkgZXZh
bHVhdGluZworICAgIGZ1bmN0aW9uIGFuZCBvcGVyYXRvciBleHByZXNzaW9ucyB3aXRoIGNv
bnN0YW50IGFyZ3VtZW50cy4gIEFsbAorICAgIG90aGVyIG5vZGVzIGFyZSBwYXNzZWQgZGly
ZWNseSB0byB0aGUgb3V0cHV0IHdpdGhvdXQgZXZhbHVhdGlvbi4KKyAgICBUaGUgZnVuY3Rp
b24gb25seSB0cmF2ZXJzZXMgYSBjb25uZWN0ZWQgdHJlZSBvZiBleHByZXNzaW9uIG5vZGVz
CisgICAgdGhhdCBhcmUgbGlzdHMsIG9wZXJhdG9ycyBvciBmdW5jdGlvbnMuCisgKi8KKyAK
KyBOb2RlICoKKyBldmFsX2NvbnN0X2V4cHJlc3Npb25zKE5vZGUgKm5vZGUsIHZvaWQgKmNv
bnRleHQpCisgeworIAlpZiAobm9kZSA9PSBOVUxMKQorIAkJcmV0dXJuIE5VTEw7CisgCisg
CS8qCisgCSAqIFdlIG9ubHkgZGVzY2VuZCBFeHByIG5vZGVzIHRoYXQgYXJlIG5vdCBTVUJf
UExBTlMsIGFuZCBMaXN0IG5vZGVzLgorIAkgKiBBbGwgb3RoZXIgbm9kZXMgYXJlIHBhc3Nl
ZCBzdHJhaWdodCB0byB0aGUgb3V0cHV0IHRyZWUuCisgCSAqLworIAlzd2l0Y2ggKG5vZGVU
YWcobm9kZSkpCisgCXsKKyAJCWNhc2UgVF9MaXN0OgorIAkJCXJldHVybiAoTm9kZSAqKSBl
eHByZXNzaW9uX3RyZWVfbXV0YXRvcihub2RlLCBldmFsX2NvbnN0X2V4cHJlc3Npb25zLAor
IAkJCQkJCQkJCQkJCQljb250ZXh0KTsKKyAKKyAJCWNhc2UgVF9Db25zdDoKKyAJCQlyZXR1
cm4gbm9kZTsKKyAKKyAJCWNhc2UgVF9FeHByOgorIAkJCXsKKyAJCQkJRXhwcgkgICAqZXhw
ciA9IChFeHByICopIG5vZGU7CisgCQkJCWJvb2wJCWFyZ3NfYXJlX2NvbnN0ID0gVFJVRTsK
KyAJCQkJYm9vbAkJY29uc3RfaXNfbnVsbCA9IEZBTFNFOworIAkJCQlib29sCQlpc0RvbmUg
PSBGQUxTRTsKKyAJCQkJRGF0dW0JCWNvbnN0X3ZhbDsKKyAJCQkJQ29uc3QJICAgKmNvbnN0
YW50OworIAorIAkJCQlzd2l0Y2ggKGV4cHItPm9wVHlwZSkKKyAJCQkJeworIAkJCQkJY2Fz
ZSBTVUJQTEFOX0VYUFI6CS8qIFBhc3Mgc3VicGxhbiBub2RlcyB0aHJvdWdoLiAqLworIAkJ
CQkJCWlmIChjb250ZXh0KQorIAkJCQkJCQkqKChib29sICopIGNvbnRleHQpID0gRkFMU0U7
CisgCQkJCQkJcmV0dXJuIG5vZGU7CisgCQkJCQlkZWZhdWx0OgkvKiBEZXNjZW5kIG9uIGFs
bCBvdGhlciBleHByZXNzaW9uIG5vZGVzLiAqLworIAkJCQkJCW5vZGUgPSBleHByZXNzaW9u
X3RyZWVfbXV0YXRvcihub2RlLCBldmFsX2NvbnN0X2V4cHJlc3Npb25zLAorIAkJCQkJCQkJ
CQkJCQkgICAmYXJnc19hcmVfY29uc3QpOworIAkJCQl9CisgCisgCQkJCWlmIChhcmdzX2Fy
ZV9jb25zdCA9PSBGQUxTRSkKKyAJCQkJeworIAkJCQkJaWYgKGNvbnRleHQpCisgCQkJCQkJ
KigoYm9vbCAqKSBjb250ZXh0KSA9IGZhbHNlOworIAkJCQkJcmV0dXJuIG5vZGU7CisgCQkJ
CX0KKyAKKyAJCQkJLyogVGhlIG5vZGUgaXMgYSBjb25zdGFudCBleHByZXNzaW9uICovCisg
CisgCQkJCS8qCisgCQkJCSAqIENoZWNrIHRoYXQgd2UgaGF2ZSBhIHJlZmVyZW5jZSB0byB0
aGUgb2JqZWN0IGZvciB0aGUKKyAJCQkJICogZXhwcmVzc2lvbgorIAkJCQkgKi8KKyAJCQkJ
aWYgKGV4cHItPm9wVHlwZSA9PSBPUF9FWFBSKQorIAkJCQl7CQkJCS8qIENoZWNrIHRoYXQg
dGhlIG9wZXJhdG9yIGZ1bmN0aW9uIGlzCisgCQkJCQkJCQkgKiB2YWxpZCAqLworIAkJCQkJ
T3BlcgkgICAqb3ByID0gKE9wZXIgKikgZXhwci0+b3BlcjsKKyAKKyAJCQkJCWlmICghT2lk
SXNWYWxpZChvcHItPm9waWQpKQorIAkJCQkJeworIAkJCQkJCW9wci0+b3BpZCA9IGdldF9v
cGNvZGUob3ByLT5vcG5vKTsKKyAKKyAJCQkJCQlpZiAoIU9pZElzVmFsaWQob3ByLT5vcGlk
KSkKKyAJCQkJCQkJZWxvZyhFUlJPUiwKKyAJCQkJCQkJCSAiZXZhbF9jb25zX2V4cmVzc2lv
bnM6ICVzICV1IiwKKyAJCQkJCQkJCSAiQ2FjaGUgbG9va3VwIGZhaWxlZCBmb3Igb3BlcmF0
b3IiLCBvcHItPm9wbm8pOworIAkJCQkJfQorIAkJCQl9CisgCisgCQkJCS8qIEV2YWx1YXRl
IHRoZSBleHByZXNzaW9uICovCisgCisgCQkJCS8qCisgCQkJCSAqIE5vdGUgaXQgaXMgTy5L
LiB0byBzZXQgdGhlIGVjb250ZXh0IGFyZ3VtZW50IHRvIG51bGwsCisgCQkJCSAqIGJlY2F1
c2Ugbm9uZSBvZiB0aGUgcm91dGluZXMgY2FsbGVkIGJ5IHRoZSBuZXh0CisgCQkJCSAqIHN0
YXRlbWVudCB1c2UgZWNvbnRleHQgd2hlbiB0aGUgYXJndW1lbnRzIHRvIHRoZQorIAkJCQkg
KiBleHByZXNzaW9uIGFyZSBhbGwgY29uc3RhbnRzLgorIAkJCQkgKi8KKyAKKyAJCQkJY29u
c3RfdmFsID0gRXhlY0V2YWxFeHByKG5vZGUsIE5VTEwsICZjb25zdF9pc19udWxsLCAmaXNE
b25lKTsKKyAJCQkJQXNzZXJ0KGlzRG9uZSk7CisgCisgCQkJCXN3aXRjaCAoZXhwci0+b3BU
eXBlKQorIAkJCQl7CisgCQkJCQljYXNlIEZVTkNfRVhQUjoKKyAJCQkJCQl7CisgCQkJCQkJ
CUZ1bmMJICAgKmZ1bmMgPSAoRnVuYyAqKSBleHByLT5vcGVyOworIAorIAkJCQkJCQljb25z
dGFudCA9IG1ha2VDb25zdChmdW5jLT5mdW5jdHlwZSwgZnVuYy0+ZnVuY3NpemUsCisgCQkJ
CQkJCQkJCQkJIGNvbnN0X3ZhbCwgY29uc3RfaXNfbnVsbCwKKyAJCQkJCQkJCQkJCSBmdW5j
LT5mdW5jX2ZjYWNoZS0+dHlwYnl2YWwsCisgCQkJCQkJCQkJCQkJIEZBTFNFLCBGQUxTRSk7
CisgCQkJCQkJCWJyZWFrOworIAkJCQkJCX0KKyAJCQkJCWNhc2UgT1BfRVhQUjoKKyAJCQkJ
CQl7CisgCQkJCQkJCU9wZXIJICAgKm9wZXIgPSAoT3BlciAqKSBleHByLT5vcGVyOworIAor
IAkJCQkJCQljb25zdGFudCA9IG1ha2VDb25zdChvcGVyLT5vcHJlc3VsdHR5cGUsIG9wZXIt
Pm9wc2l6ZSwKKyAJCQkJCQkJCQkJCQkgY29uc3RfdmFsLCBjb25zdF9pc19udWxsLAorIAkJ
CQkJCQkJCQkJICAgb3Blci0+b3BfZmNhY2hlLT50eXBieXZhbCwKKyAJCQkJCQkJCQkJCQkg
RkFMU0UsIEZBTFNFKTsKKyAJCQkJCQkJYnJlYWs7CisgCQkJCQkJfQorIAkJCQkJZGVmYXVs
dDoJLyogTXVzdCBiZSBhIEJvb2xlYW4gZXhwcmVzc2lvbi4gKi8KKyAJCQkJCQljb25zdGFu
dCA9IG1ha2VDb25zdChleHByLT50eXBlT2lkLCBzaXplb2YoRGF0dW0pLAorIAkJCQkJCQkJ
CQkJIGNvbnN0X3ZhbCwgY29uc3RfaXNfbnVsbCwKKyAJCQkJCQkJCQkJCSBUUlVFLCBGQUxT
RSwgRkFMU0UpOworIAorIAkJCQl9CisgCisgCQkJCXJldHVybiAoTm9kZSAqKSBjb25zdGFu
dDsKKyAJCQl9CQkJCQkvKiBFbmQgb2YgY2FzZSBUX0V4cHI6ICovCisgCisgCQlkZWZhdWx0
OgkJCQkvKiBBbGwgb3RoZXIgbm9kZXMgZHJvcCB0aHJvdWdoLiAqLworIAl9CisgCisgCS8q
IEZvdW5kIGEgbm9kZSB0aGF0IGNhbid0IGJlIGluIGEgY29uc3RhbnQgZXhwcmVzc2lvbiB0
cmVlICovCisgCWlmIChjb250ZXh0KQorIAkJKigoYm9vbCAqKSBjb250ZXh0KSA9IEZBTFNF
OworIAlyZXR1cm4gbm9kZTsKKyB9CiAgCiAgLyoKICAgKiBTdGFuZGFyZCBleHByZXNzaW9u
LXRyZWUgd2Fsa2luZyBzdXBwb3J0CioqKiAuL3NyYy9pbmNsdWRlL29wdGltaXplci9jbGF1
c2VzLmgub3JpZwlUdWUgU2VwIDIxIDE2OjM4OjEyIDE5OTkKLS0tIC4vc3JjL2luY2x1ZGUv
b3B0aW1pemVyL2NsYXVzZXMuaAlUdWUgU2VwIDIxIDE2OjQ3OjMyIDE5OTkKKioqKioqKioq
KioqKioqCioqKiA1Miw1NyAqKioqCi0tLSA1Miw1OSAtLS0tCiAgCQkJICBBdHRyTnVtYmVy
ICphdHRubzEsIGludCAqcmVsaWQyLCBBdHRyTnVtYmVyICphdHRubzIpOwogIGV4dGVybiB2
b2lkIENvbW11dGVDbGF1c2UoRXhwciAqY2xhdXNlKTsKICAKKyBleHRlcm4gTm9kZSAqZXZh
bF9jb25zdF9leHByZXNzaW9ucyhOb2RlICpub2RlLCB2b2lkICpjb250ZXh0KTsKKyAKICBl
eHRlcm4gYm9vbCBleHByZXNzaW9uX3RyZWVfd2Fsa2VyKE5vZGUgKm5vZGUsIGJvb2wgKCp3
YWxrZXIpICgpLAogIAkJCQkJCQkJCQkJICAgdm9pZCAqY29udGV4dCk7CiAgZXh0ZXJuIE5v
ZGUgKmV4cHJlc3Npb25fdHJlZV9tdXRhdG9yKE5vZGUgKm5vZGUsIE5vZGUgKigqbXV0YXRv
cikgKCksCg==
--------------9D0AFDFB6B8EF6EBFF89AD94--
From bouncefilter Tue Sep 21 16:27:39 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id QAA90826
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 16:26:52 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11TWNx-0003kLC; Tue, 21 Sep 99 22:19 MET DST
Message-Id: <m11TWNx-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] INSERT INTO view means what exactly?
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Tue, 21 Sep 1999 22:19:33 +0200 (MET DST)
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199909211944.PAA15774@candle.pha.pa.us> from "Bruce Momjian" at
Sep 21, 99 03:44:07 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Bruce Momjian wrote:
Does anyone know a cause for this?
This is one of the frequently asked RULE-/VIEW-questions. I
think I've answered it at least a half dozen times up to now
and if I recall right, explained it it detail in the
documentation of the rule system too. Seems I failed to make
it funny enough to let people read until the end ;-)
Well, the cause is that there is a rewrite rule for SELECT,
but none for INSERT. Thus, the INSERT goes through and get's
executed as if "z" where a table, what it in fact is, because
there are all catalog entries plus a relation-file for
tuples. So why should the executor throw them away?
At the time of the INSERT, the relations file "z" lost it's
zero-size, and as soon as you drop the _RETz rule, you can
SELECT the "bar" (and order a beer).
One possible solution would be to let the rewriter check on
INSERT/UPDATE/DELETE if a SELECT rule exists but none for the
requested event and complain about it. But I thought the
rewriter is already complicated enough, so I've let it out.
Another solution would be, to set the ACL by default to
owner=r and force people to change ACL's when they setup
rules to make views updateable. Maybe the better solution.
Jan
With current sources:
regression=> CREATE TABLE x (y text);
CREATE
regression=> CREATE VIEW z AS select * from x;
CREATE
regression=> INSERT INTO x VALUES ('foo');
INSERT 411635 1
regression=> INSERT INTO z VALUES ('bar');
INSERT 411636 1
regression=> select * from x;
y
---
foo
(1 row)regression=> select * from z;
y
---
foo
(1 row)OK, where'd tuple 411636 go? Seems to me that the insert should either
have been rejected or caused an insert into x, depending on how
transparent you think views are (I always thought they were
read-only?). Dropping the data into never-never land and giving a
misleading success response code is not my idea of proper behavior.
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Sep 21 17:01:38 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA00864
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 17:00:46 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA17419;
Tue, 21 Sep 1999 17:00:13 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909212100.RAA17419@candle.pha.pa.us>
Subject: Re: [GENERAL] Update of bitmask type
In-Reply-To: <3767C4DA.2DBB1C2D@albourne.com> from Adriaan Joubert at "Jun 16,
1999 06:38:02 pm"
To: Adriaan Joubert <a.joubert@albourne.com>
Date: Tue, 21 Sep 1999 17:00:13 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Can I get comments on this? Is a bit type something we want installed
by default, or in contrib? Seems to me it should be in the main tree.
Hi,
here is a new version of the bitmask type. It supports hash-indices as
well now, and fixes a bug in the definition of the <> operator.I would appreciate it if somebody more knowledgable than myself would
look over the index definitions. They seem to work and are used by
postgres, so I guess they can't be all wrong. The hashing function is
the same as that for char's and comes straight out of the postgres
source code.BTW, chapter 36 of the documentation could do with some additions, but I
don't feel knowledgable enough to attempt it. E.g. it shows how to put
an entry for the hashing into pg_amop, but never explains how to define
the entry in pg_amproc and doesn't tell you that you need to define a
separate hashing function. It took me a while of looking through the
other definitions and digging through the source code to come up with a
best guess.Perhaps this could go into the contrib area if it passes muster, as it
is an example of a user-defined type with indices.Cheers,
Adriaan
[application/x-gzip is not supported, skipping...]
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Tue Sep 21 17:14:40 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id RAA02940
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 17:13:41 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11TX7c-0003kvC; Tue, 21 Sep 99 23:06 MET DST
Message-Id: <m11TX7c-0003kvC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
To: vadim@krs.ru (Vadim Mikheev)
Date: Tue, 21 Sep 1999 23:06:44 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37E7D825.EDA139C5@krs.ru> from "Vadim Mikheev" at Sep 22,
99 03:10:29 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Vadim wrote:
But records will be fetched from WAL in reverse order, from
down to up.Does it matter?
Might require to teach the WAL-manager to do it top-down too.
And even then it might be better on performance to scan my
constraint-log for events to the same tuple. It has records
of a fixed, very small size and fetching tuples by CTID from
the heap (direct block access) is required anyway because for
delayed trigger invocation I neen OLD values too - and that's
not in WAL if I read it right.
But as I said I'd like to leave that coupling for later.
BTW, I found what standard means by "immediate":
---
The checking of a constraint depends on its constraint mode within
the current SQL-transaction. If the constraint mode is immediate,
| then the constraint is effectively checked at the end of each
^^^^^^^^^^^^^^^^^^
| ___________________________________________________________________
| ANSI Only-SQL3
| ___________________________________________________________________
| SQL-statement S, unless S is executed because it is a <triggered
^^^^^^^^^^^^^^^
| SQL statement>, in which case, the constraint is effectively
| checked at the end of the SQL-statement that is the root cause
| of S.
---
Ah - so ALL constraint-triggers must be AFTER <event> and
deferred at least until the end of the USER-query.
And now about triggers (regardless of ROW or STATEMENT level!):
---
4.22.2 Execution of triggered actionsThe execution of triggered actions depends on the cursor mode of
the current SQL-transaction. If the cursor mode is set to cascade
off, then the execution of the <triggered SQL statement>s is effec-
tively deferred until enacted implicitly be execution of a <commit
statement> or a <close statement>. Otherwise, the <triggered SQL
statement>s are effectively executed either before or after the
^^^^^^^^^^^^^^^^^^^
execution of each SQL-statement, as determined by the specified
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<trigger action time>.
---
We do not have FOR UPDATE cursors. So (even if to be kept in
mind) there is no CURSOR mode to care for right now.
Changing BEFORE triggers to behave exactly like that would
require to do the execution of the plan twice, one time to
fire triggers, another time to perform the action itself. I
don't think that the perfomance cost is worth this little
amount of accuracy. Such a little difference should be
mentioned in the product notes and period.
AFTER triggers could simply be treated half like IMMEDIATE
constraints - deferred until the end of a single statement
(not user-query). So there are four times where the deferred
trigger queue is run (maybe partially). At the end of a
statement, end of a user-query, at a syncpoint (not sure if
we have them up to now) and end of transaction.
Things are getting much clearer - Tnx.
Do you worry about disk space? -:)
With archive mode off only log segments (currently, 64M each)
required by active transactions (which made some changes)
will present on disk.
Never - my motto is "don't force it - use a bigger hammer".
But the above seems to be exactly like the Oracle behaviour
where online-redolog's aren't affected by archive mode.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Sep 21 17:40:38 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA07925;
Tue, 21 Sep 1999 17:40:06 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA21058;
Tue, 21 Sep 1999 17:39:54 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909212139.RAA21058@candle.pha.pa.us>
Subject: Re: [HACKERS] Problems with src/pl/tcl/mkMakefile.tcldefs.sh.in in
6.5
In-Reply-To: <199907100542.AAA12893@postal.thewrittenword.com> from
"pgsql-hackers@thewrittenword.com" at "Jul 10, 1999 00:42:46 am"
To: pgsql-hackers@thewrittenword.com
Date: Tue, 21 Sep 1999 17:39:54 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org, pgsql-admin@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I believe this is fixed.
For Digital UNIX 4.0D, shared libraries are created by:
$ ld -shared -expect_unresolved "*" -o foo.so [objects]This presents a problem for mkMakefile.tcldefs.sh.in. In tclConfig.sh:
TCL_SHLIB_LD='ld -shared -expect_unresolved "*"'In mkMakefile.tcldefs.sh.in:
cat @TCL_CONFIG_SH@ |
egrep '^TCL_|^TK_' |
while read inp
do
eval eval echo $inp
done >Makefile.tcldefsBecause of this, we wind up with the following in Makefile.tcldefs to
created shared libraries on Digital UNIX because of the eval:
TCL_SHLIB_LD=ld -shared -expect_unresolved *The "*" needs to be quoted to avoid shell expansion. How about the
following:
cat @TCL_CONFIG_SH@ |
egrep '^TCL_|^TK_' |
sed -e "s/^\([^=]*\)='\(.*\)'$/\1=\2/"--
albert chin (china@thewrittenword.com)
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Tue Sep 21 17:45:41 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA08531
for <docs@postgresql.org>; Tue, 21 Sep 1999 17:44:45 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:1676 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.rtzl/114931>;
Tue, 21 Sep 1999 23:44:33 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11TXjz-0000lK-00; Tue, 21 Sep 1999 23:46:23 +0200
Date: Tue, 21 Sep 1999 23:46:19 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Vince Vielhaber <vev@michvhf.com>, The Hermit Hacker <scrappy@hub.org>,
docs@postgreSQL.org
Subject: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)
In-Reply-To: <199909210247.WAA27574@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.9909212031480.1899-200000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-651635041-937944888=:1899"
Content-ID: <Pine.LNX.4.10.9909212346110.1899@peter-e.yi.org>
Sender: Peter Eisentraut <peter@peter-e.yi.org>
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--8323328-651635041-937944888=:1899
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.10.9909212346111.1899@peter-e.yi.org>
On Sep 20, Bruce Momjian mentioned:
I agree our INSTALL is very large. Is there some way we can simplify
the install process?
On the one hand a database server is probably not your everyday
./configure && make && make install program you get from freshmeat and you
do want to put some time into a proper installation. On the other hand the
INSTALL file is really way too long and makes for unpleasant reading.
Here are a couple of ideas.
* Chapter 2 "Ports" should be moved to the README file (has nothing to do
with the actual installation).
* Move the gory details of item 5 (flex) to a separate file (README.flex).
* Move the locale stuff into a separate file.
* Same with Kerberos
* Move the release notes at the end to CHANGELOG.
That should make the file somewhat smaller, then also it is really to
verbose at times and is formatted really oddly, at least on my system.
Okay, now I really went out of my way and redid the whole thing. You'll
find the result attached. This is merely an idea of what I would consider
simpler. I removed some inconsistencies, things that were unnecessary, too
complicated, etc. Okay, I removed a lot of stuff, but most of the stuff
people can really figure out themselves if they need them in the first
place. And I shrunk the thing to 25%.
Perhaps there should be a separate Install FAQ of the sort "My shell said
'export: Command not found.'" or "What's a shared library?" to move the
really annoying stuff out of people's ways.
Comments?
--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e
--8323328-651635041-937944888=:1899
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; NAME="INSTALL.new"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9909212214481.1899@peter-e.yi.org>
Content-Description: New INSTALL file?
Content-Disposition: ATTACHMENT; FILENAME="INSTALL.new"
UG9zdGdyZVNRTCBJbnN0YWxsYXRpb24gR3VpZGUNCmJ5IFRoZSBQb3N0Z3Jl
U1FMIERldmVsb3BtZW50IFRlYW0NCg0KUG9zdGdyZVNRTCBpcyCpIDE5OTgt
OSBieSB0aGUgUG9zdGdyZXMgR2xvYmFsIERldmVsb3BtZW50IEdyb3VwLg0K
DQpQbGVhc2UgY29uc3VsdCB0aGUgZmlsZSBSRUFETUUgZmlyc3QhDQoNClRo
aXMgaW5zdGFsbGF0aW9uIHByb2NlZHVyZSBtYWtlcyBzb21lIGFzc3VtcHRp
b25zIGFib3V0IHRoZSBkZXNpcmVkDQpjb25maWd1cmF0aW9uIGFuZCBydW50
aW1lIGVudmlyb25tZW50IGZvciB5b3VyIHN5c3RlbS4gVGhpcyBtYXkgYmUN
CmFkZXF1YXRlIGZvciBtYW55IGluc3RhbGxhdGlvbnMsIGFuZCBpcyBhbG1v
c3QgY2VydGFpbmx5IGFkZXF1YXRlIGZvciBhDQpmaXJzdCBpbnN0YWxsYXRp
b24uIEJ1dCB5b3UgbWF5IHdhbnQgdG8gZG8gYW4gaW5pdGlhbCBpbnN0YWxs
YXRpb24gdXAgdG8NCnRoZSBwb2ludCBvZiB1bnBhY2tpbmcgdGhlIHNvdXJj
ZSB0cmVlIGFuZCBpbnN0YWxsaW5nIGRvY3VtZW50YXRpb24sIGFuZA0KdGhl
biBwcmludCBvciBicm93c2UgdGhlIEFkbWluaXN0cmF0b3IncyBHdWlkZS4N
Cg0KQmVmb3JlIGluc3RhbGxpbmcgUG9zdGdyZXMsIHlvdSBtYXkgd2lzaCB0
byB2aXNpdCB3d3cucG9zdGdyZXNxbC5vcmcNCihodHRwOi8vd3d3LnBvc3Rn
cmVzcWwub3JnKSBmb3IgdXAgdG8gZGF0ZSBpbmZvcm1hdGlvbiwgcGF0Y2hl
cywgZXRjLg0KDQpUaGVzZSBpbnN0YWxsYXRpb24gaW5zdHJ1Y3Rpb25zIGFz
c3VtZToNCm8gIFlvdSBhbHJlYWR5IGhhdmUgZG93bmxvYWRlZCB0aGUgc291
cmNlcy4gKElmIG5vdCwgc2VlIHdlYiBzaXRlLikNCm8gIENvbW1hbmRzIGFy
ZSBVbml4LWNvbXBhdGlibGUuIFNlZSBub3RlIGJlbG93LiANCm8gIERlZmF1
bHRzIGFyZSB1c2VkIGV4Y2VwdCB3aGVyZSBub3RlZC4gDQpvICBVc2VyICdw
b3N0Z3JlcycgaXMgdGhlIFBvc3RncmVzIHN1cGVydXNlci4gDQpvICBUaGUg
c291cmNlIHBhdGggaXMgL3Vzci9zcmMvcGdzcWwgKG90aGVyIHBhdGhzIGFy
ZSBwb3NzaWJsZSkuIA0KbyAgVGhlIHJ1bnRpbWUgcGF0aCBpcyAvdXNyL2xv
Y2FsL3Bnc3FsIChvdGhlciBwYXRocyBhcmUgcG9zc2libGUpLiANCiAgICAg
ICAgDQpDb21tYW5kcyB3ZXJlIHRlc3RlZCBvbiBSZWRIYXQgTGludXggdmVy
c2lvbiA1LjIuIEV4Y2VwdCB3aGVyZSBub3RlZCwgdGhleQ0Kd2lsbCBwcm9i
YWJseSB3b3JrIG9uIG1vc3Qgc3lzdGVtcy4gQ29tbWFuZHMgbGlrZSBwcyBh
bmQgdGFyIG1heSB2YXJ5DQp3aWxkbHkgYmV0d2VlbiBwbGF0Zm9ybXMgb24g
d2hhdCBvcHRpb25zIHlvdSBzaG91bGQgdXNlLiBVc2UgY29tbW9uIHNlbnNl
DQpiZWZvcmUgdHlwaW5nIGluIHRoZXNlIGNvbW1hbmRzLg0KDQpPdXIgTWFr
ZWZpbGVzIHJlcXVpcmUgR05VIG1ha2UuIFRoZXkgd2lsbCBub3Qgd29yayB3
aXRoIG5vbi1HTlUgbWFrZQ0KcHJvZ3JhbXMuIElmIHlvdSBkbyBub3QgaGF2
ZSBHTlUgbWFrZSAoY2hlY2sgbWFrZSAtLXZlcnNpb24pLCBnZXQgaXQgZnJv
bQ0Kd3d3LmdudS5vcmcuDQoNCg0KUmVxdWlyZW1lbnRzIHRvIFJ1biBQb3N0
Z3Jlcw0KDQpJbiBnZW5lcmFsLCBtb3N0IFVuaXgtY29tcGF0aWJsZSBwbGF0
Zm9ybXMgd2l0aCBtb2Rlcm4gbGlicmFyaWVzIHNob3VsZCBiZQ0KYWJsZSB0
byBydW4gUG9zdGdyZXMuICBBbHRob3VnaCB0aGUgbWluaW11bSByZXF1aXJl
ZCBtZW1vcnkgZm9yIHJ1bm5pbmcNClBvc3RncmVzIGlzIGFzIGxpdHRsZSBh
cyA4TUIsIHRoZXJlIGFyZSBub3RpY2FibGUgaW1wcm92ZW1lbnRzIGluIHJ1
bnRpbWVzDQpmb3IgdGhlIHJlZ3Jlc3Npb24gdGVzdHMgd2hlbiBleHBhbmRp
bmcgbWVtb3J5IHVwIHRvIDk2TUIgb24gYSByZWxhdGl2ZWx5DQpmYXN0IGR1
YWwtcHJvY2Vzc29yIHN5c3RlbSBydW5uaW5nIFgtV2luZG93cy4gVGhlIHJ1
bGUgaXMgeW91IGNhbiBuZXZlcg0KaGF2ZSB0b28gbXVjaCBtZW1vcnkuDQoN
CkNoZWNrIHRoYXQgeW91IGhhdmUgc3VmZmljaWVudCBkaXNrIHNwYWNlLiBZ
b3Ugd2lsbCBuZWVkIGFib3V0IDMwIE1ieXRlcw0KZm9yIC91c3Ivc3JjL3Bn
c3FsLCBhYm91dCA1IE1ieXRlcyBmb3IgL3Vzci9sb2NhbC9wZ3NxbCAoZXhj
bHVkaW5nIHlvdXINCmRhdGFiYXNlKSAgYW5kIDEgTWJ5dGUgZm9yIGFuIGVt
cHR5IGRhdGFiYXNlLiBUaGUgZGF0YWJhc2Ugd2lsbA0KdGVtcG9yYXJpbHkg
Z3JvdyB0byBhYm91dCAyMCBNYnl0ZXMgZHVyaW5nIHRoZSByZWdyZXNzaW9u
IHRlc3RzLiBZb3Ugd2lsbA0KYWxzbyBuZWVkIGFib3V0IDMgTWJ5dGVzIGZv
ciB0aGUgZGlzdHJpYnV0aW9uIHRhciBmaWxlLg0KDQpXZSB0aGVyZWZvcmUg
cmVjb21tZW5kIHRoYXQgZHVyaW5nIGluc3RhbGxhdGlvbiBhbmQgdGVzdGlu
ZyB5b3UgaGF2ZSB3ZWxsDQpvdmVyIDIwIE1ieXRlcyBmcmVlIHVuZGVyIC91
c3IvbG9jYWwgYW5kIGFub3RoZXIgMjUgTWJ5dGVzIGZyZWUgb24gdGhlDQpk
aXNrIHBhcnRpdGlvbiBjb250YWluaW5nIHlvdXIgZGF0YWJhc2UuIE9uY2Ug
eW91IGRlbGV0ZSB0aGUgc291cmNlIGZpbGVzLA0KdGFyIGZpbGUgYW5kIHJl
Z3Jlc3Npb24gZGF0YWJhc2UsIHlvdSB3aWxsIG5lZWQgMiBNYnl0ZXMgZm9y
DQovdXNyL2xvY2FsL3Bnc3FsLCAxIE1ieXRlIGZvciB0aGUgZW1wdHkgZGF0
YWJhc2UsIHBsdXMgYWJvdXQgZml2ZSB0aW1lcw0KdGhlIHNwYWNlIHlvdSB3
b3VsZCByZXF1aXJlIHRvIHN0b3JlIHlvdXIgZGF0YWJhc2UgZGF0YSBpbiBh
IGZsYXQgZmlsZS4NCg0KVG8gY2hlY2sgZm9yIGRpc2sgc3BhY2UsIHVzZSAN
CiQgZGYgLWsNCiAgICAgICAgICAgDQoNCkluc3RhbGxhdGlvbiBQcm9jZWR1
cmUNCg0KMS4gUmVhZCBhbnkgbGFzdCBtaW51dGUgaW5mb3JtYXRpb24gYW5k
IHBsYXRmb3JtIHNwZWNpZmljIHBvcnRpbmcgbm90ZXMuDQpUaGVyZSBhcmUg
c29tZSBwbGF0Zm9ybSBzcGVjaWZpYyBub3RlcyBhdCB0aGUgZW5kIG9mIHRo
aXMgZmlsZSBmb3INClVsdHJpeDQueCwgTGludXgsIEJTRC9PUyBhbmQgTmVY
VC4gVGhlcmUgYXJlIG90aGVyIGZpbGVzIGluIGRpcmVjdG9yeQ0KL3Vzci9z
cmMvcGdzcWwvZG9jLCBpbmNsdWRpbmcgZmlsZXMgRkFRLUlyaXggYW5kIEZB
US1MaW51eC4NCg0KDQoyLiBTb21lIHBsYXRmb3JtcyB1c2UgZmxleC4gSWYg
eW91ciBzeXN0ZW0gdXNlcyBmbGV4IHRoZW4gbWFrZSBzdXJlIHlvdQ0KaGF2
ZSBhIGdvb2QgdmVyc2lvbi4gVG8gY2hlY2ssIHR5cGUNCiQgZmxleCAtLXZl
cnNpb24NCklmIHRoZSBmbGV4IGNvbW1hbmQgaXMgbm90IGZvdW5kIHRoZW4g
eW91IHByb2JhYmx5IGRvIG5vdCBuZWVkIGl0LiBJZiB0aGUNCnZlcnNpb24g
aXMgMi41LjIgb3IgMi41LjQgb3IgZ3JlYXRlciB0aGVuIHlvdSBhcmUgb2th
eS4gSWYgaXQgaXMgMi41LjMgb3INCmJlZm9yZSAyLjUuMiB0aGVuIHlvdSB3
aWxsIGhhdmUgdG8gdXBncmFkZSBmbGV4LiBQbGVhc2UgcmVhZCB0aGUgZmls
ZQ0KUkVBRE1FLmZsZXggZm9yIGRldGFpbHMuDQoNCioqKiBJZiB5b3UgYXJl
IG5vdCB1cGdyYWRpbmcgYW4gZXhpc3Rpbmcgc3lzdGVtIHRoZW4gc2tpcCB0
byBzdGVwIDYuICoqKg0KDQoNCjMuIElmIHlvdSBhcmUgdXBncmFkaW5nIGFu
IGV4aXN0aW5nIHN5c3RlbSB0aGVuIGJhY2sgdXAgeW91ciBkYXRhYmFzZS4g
Rm9yDQphbHBoYS0gYW5kIGJldGEtbGV2ZWwgcmVsZWFzZXMsIHRoZSBkYXRh
YmFzZSBmb3JtYXQgaXMgbGlhYmxlIHRvIGNoYW5nZSwNCm9mdGVuIGV2ZXJ5
IGZldyB3ZWVrcywgd2l0aCBubyBub3RpY2UgYmVzaWRlcyBhIHF1aWNrIGNv
bW1lbnQgaW4gdGhlDQpIQUNLRVJTIG1haWxpbmcgbGlzdC4gRnVsbCByZWxl
YXNlcyBhbHdheXMgcmVxdWlyZSBhIGR1bXAvcmVsb2FkIGZyb20NCnByZXZp
b3VzIHJlbGVhc2VzLiBJdCBpcyB0aGVyZWZvcmUgYSBiYWQgaWRlYSB0byBz
a2lwIHRoaXMgc3RlcC4NCg0KVGlwOiBEbyBub3QgdXNlIHRoZSBwZ19kdW1w
YWxsIHNjcmlwdCBmcm9tIHY2LjAgb3IgZXZlcnl0aGluZyB3aWxsIGJlDQpv
d25lZCBieSB0aGUgUG9zdGdyZXMgc3VwZXIgdXNlci4NCg0KVG8gZHVtcCB5
b3VyIGZhaXJseSByZWNlbnQgcG9zdC12Ni4wIGRhdGFiYXNlIGluc3RhbGxh
dGlvbiwgdHlwZSANCiQgcGdfZHVtcGFsbCA+IGRiLm91dA0KDQooVG8gdXNl
IHRoZSBsYXRlc3QgcGdfZHVtcGFsbCBzY3JpcHQgb24geW91ciBleGlzdGlu
ZyBvbGRlciBkYXRhYmFzZSBiZWZvcmUNCiB1cGdyYWRpbmcgUG9zdGdyZXMs
IHB1bGwgdGhlIG1vc3QgcmVjZW50IHZlcnNpb24gb2YgcGdfZHVtcGFsbCBm
cm9tIHRoZSBuZXcNCiBkaXN0cmlidXRpb246IA0KJCBndW56aXAgLWMgcG9z
dGdyZXNxbC12Ni41LnRhci5neiB8IHRhciB4dmYgLSBzcmMvYmluL3BnX2R1
bXAvcGdfZHVtcGFsbA0KJCBjaG1vZCBhK3ggc3JjL2Jpbi9wZ19kdW1wL3Bn
X2R1bXBhbGwNCiQgc3JjL2Jpbi9wZ19kdW1wL3BnX2R1bXBhbGwgPiBkYi5v
dXQNCiQgcm0gLXJmIHNyYw0KKQ0KDQpJZiB5b3Ugd2lzaCB0byBwcmVzZXJ2
ZSBvYmplY3QgaWQncyAob2lkcyksIHRoZW4gdXNlIHRoZSAtbyBvcHRpb24g
d2hlbg0KcnVubmluZyBwZ19kdW1wYWxsLiAgSG93ZXZlciwgdW5sZXNzIHlv
dSBoYXZlIGEgc3BlY2lhbCByZWFzb24gZm9yIGRvaW5nDQp0aGlzIChzdWNo
IGFzIHVzaW5nIE9JRHMgYXMga2V5cyBpbiB0YWJsZXMpLCBkb24ndCBkbyBp
dC4NCg0KQ0FVVElPTjogWW91IG11c3QgbWFrZSBzdXJlIHRoYXQgeW91ciBk
YXRhYmFzZSBpcyBub3QgdXBkYXRlZCBpbiB0aGUNCm1pZGRsZSBvZiB5b3Vy
IGJhY2t1cC4gSWYgbmVjZXNzYXJ5LCBicmluZyBkb3duIHBvc3RtYXN0ZXIs
IGVkaXQgdGhlDQpwZXJtaXNzaW9ucyBpbiBmaWxlIC91c3IvbG9jYWwvcGdz
cWwvZGF0YS9wZ19oYmEuY29uZiB0byBhbGxvdyBvbmx5IHlvdQ0Kb24sIHRo
ZW4gYnJpbmcgcG9zdG1hc3RlciBiYWNrIHVwLg0KDQoNCjQuIEtpbGwgdGhl
IHBvc3RtYXN0ZXIuIFlvdSBtaWdodCBmaW5kIHRoYXQNCiQga2lsbGFsbCBw
b3N0bWFzdGVyDQp3aWxsIGRvIHRoZSBqb2IuIE90aGVyd2lzZSB0eXBlDQok
IHBzIC1heCB8IGdyZXAgcG9zdG1hc3Rlcg0KYW5kIHlvdSBtaWdodCBnZXQg
YW4gb3V0cHV0IGxpa2UgdGhpczoNCiAyNTY1ICAgNSBTICAgIDA6MDAgZ3Jl
cCBwb3N0bWFzdGVyDQogIDI4NSAgPyAgU1cgICAwOjAwIChwb3N0bWFzdGVy
KQ0KVGhlbiB0eXBlDQokIGtpbGwgMjg1DQooc3Vic3RpdHV0ZSB5b3VyIG51
bWJlciBoZXJlKS4NCg0KT24gc3lzdGVtcyB3aGljaCBoYXZlIFBvc3RncmVz
IHN0YXJ0ZWQgYXQgYm9vdCB0aW1lLCB0aGVyZSBpcyBwcm9iYWJseSBhDQpz
dGFydHVwIGZpbGUgd2hpY2ggd2lsbCBhY2NvbXBsaXNoIHRoZSBzYW1lIHRo
aW5nLiBGb3IgZXhhbXBsZSwgb24gbXkNCkxpbnV4IHN5c3RlbSBJIGNhbiB0
eXBlDQokIC9ldGMvcmMuZC9pbml0LmQvcG9zdGdyZXMuaW5pdCBzdG9wDQp0
byBoYWx0IFBvc3RncmVzLg0KDQoNCjUuIE1vdmUgdGhlIG9sZCBkaXJlY3Rv
cmllcyBvdXQgb2YgdGhlIHdheS4gSWYgeW91IGFyZSBzaG9ydCBvZiBkaXNr
IHNwYWNlDQp0aGVuIHlvdSBtYXkgaGF2ZSB0byBiYWNrIHVwIGFuZCBkZWxl
dGUgdGhlIGRpcmVjdG9yaWVzIGluc3RlYWQuIElmIHlvdSBkbw0KdGhpcywg
c2F2ZSB0aGUgb2xkIGRhdGFiYXNlIGluIHRoZSAvdXNyL2xvY2FsL3Bnc3Fs
L2RhdGEgZGlyZWN0b3J5IHRyZWUgb3INCnRoZSBkYXRhYmFzZSBkdW1wIHlv
dSBtYWRlLCByZXNwZWN0aXZlbHkuIEF0IGEgbWluaW11bSwgc2F2ZSBmaWxl
DQovdXNyL2xvY2FsL3Bnc3FsL2RhdGEvcGdfaGJhLmNvbmYuDQoNClR5cGUg
dGhlIGZvbGxvd2luZzogDQokIHN1IC0NCiQgY2QgL3Vzci9zcmMNCiQgbXYg
cGdzcWwgcGdzcWxfNl8wDQokIGNkIC91c3IvbG9jYWwNCiQgbXYgcGdzcWwg
cGdzcWxfNl8wDQokIGV4aXQNCg0KSWYgeW91IGFyZSBub3QgdXNpbmcgL3Vz
ci9sb2NhbC9wZ3NxbC9kYXRhIGFzIHlvdXIgZGF0YSBkaXJlY3RvcnkgKGNo
ZWNrDQp0byBzZWUgaWYgZW52aXJvbm1lbnQgdmFyaWFibGUgUEdEQVRBIGlz
IHNldCB0byBzb21ldGhpbmcgZWxzZSkgdGhlbiB5b3UNCndpbGwgYWxzbyB3
YW50IHRvIG1vdmUgdGhpcyBkaXJlY3RvcnkgaW4gdGhlIHNhbWUgbWFubmVy
Lg0KDQoqKiogQ29udGludWUgaGVyZSBpZiB5b3UgYXJlIGluc3RhbGxpbmcg
YSBuZXcgc3lzdGVtLiAqKioNCg0KDQo2LiBNYWtlIGEgZGlyZWN0b3J5IGZv
ciB0aGUgc291cmNlIGNvZGUgYW5kIHVucGFjayB0aGUgc291cmNlIHRhcmJh
bGwgdGhlcmU6DQokIGd1bnppcCAtYyB+L3Bvc3RncmVzcWwtdjYuNS50YXIu
Z3ogfCB0YXIgeHZmIC0NCiQgbXYgcG9zdGdyZXNxbC02LjUgL3Vzci9zcmMv
cGdzcWwNCg0KDQo3LiBDb25maWd1cmUgdGhlIHNvdXJjZSBjb2RlIGZvciB5
b3VyIHN5c3RlbS4gSXQgaXMgdGhpcyBzdGVwIGF0IHdoaWNoIHlvdQ0KY2Fu
IHNwZWNpZnkgeW91ciBhY3R1YWwgaW5zdGFsbGF0aW9uIHBhdGggZm9yIHRo
ZSBidWlsZCBwcm9jZXNzIChzZWUgdGhlDQotLXByZWZpeCBvcHRpb24gYmVs
b3cpLiBUeXBlDQokIGNkIC91c3Ivc3JjL3Bnc3FsL3NyYw0KJCAuL2NvbmZp
Z3VyZSBbIG9wdGlvbnMgXQ0KDQpUaGUgY29uZmlndXJlIHNjcmlwdCBzZWxl
Y3RzIGEgc3lzdGVtLXNwZWNpZmljICJ0ZW1wbGF0ZSIgZmlsZSBmcm9tIHRo
ZQ0KZmlsZXMgcHJvdmlkZWQgaW4gdGhlIHRlbXBsYXRlIHN1YmRpcmVjdG9y
eS4gSWYgaXQgY2Fubm90IGd1ZXNzIHdoaWNoIG9uZQ0KdG8gdXNlIGZvciB5
b3VyIHN5c3RlbSwgaXQgd2lsbCBzYXkgc28gYW5kIGV4aXQuIEluIHRoYXQg
Y2FzZSB5b3UnbGwgbmVlZA0KdG8gZmlndXJlIG91dCB3aGljaCBvbmUgdG8g
dXNlIGFuZCBydW4gY29uZmlndXJlIGFnYWluLCB0aGlzIHRpbWUgZ2l2aW5n
DQp0aGUgLS13aXRoLXRlbXBsYXRlPVRFTVBMQVRFIG9wdGlvbiB0byBtYWtl
IHRoZSByaWdodCBmaWxlIGJlIGNob3Nlbi4NCg0KUGxlYXNlIFJlcG9ydCBQ
cm9ibGVtczogSWYgeW91ciBzeXN0ZW0gaXMgbm90IGF1dG9tYXRpY2FsbHkg
cmVjb2duaXplZCBieQ0KY29uZmlndXJlIGFuZCB5b3UgaGF2ZSB0byBkbyB0
aGlzLCBwbGVhc2Ugc2VuZCBlbWFpbCB0bw0Kc2NyYXBweUBwb3N0Z3Jlc3Fs
Lm9yZyB3aXRoIHRoZSBvdXRwdXQgb2YgdGhlIHByb2dyYW0gLi9jb25maWcu
Z3Vlc3MuDQpJbmRpY2F0ZSB3aGF0IHRoZSB0ZW1wbGF0ZSBmaWxlIHNob3Vs
ZCBiZS4NCg0KQ2hvb3NlIGNvbmZpZ3VyYXRpb24gb3B0aW9ucy4gQ2hlY2sg
Q29uZmlndXJhdGlvbiBPcHRpb25zIGZvciBkZXRhaWxzLg0KSG93ZXZlciwg
Zm9yIGEgZmlyc3QgaW5zdGFsbGF0aW9uIHdpdGggbm8gZXh0cmEgb3B0aW9u
cyBsaWtlIG11bHRpLWJ5dGUNCmNoYXJhY3RlciBzdXBwb3J0IG9yIGxvY2Fs
ZSBjb2xsYXRpb24gc3VwcG9ydCBpdCBtYXkgYmUgYWRlcXVhdGUgdG8ganVz
dA0KY2hvc2UgdGhlIGluc3RhbGxhdGlvbiBhcmVhcyBhbmQgcnVuIGNvbmZp
Z3VyZSB3aXRob3V0IGV4dHJhIG9wdGlvbnMNCnNwZWNpZmllZC4gVGhlIGNv
bmZpZ3VyZSBzY3JpcHQgYWNjZXB0cyBtYW55IGFkZGl0aW9uYWwgb3B0aW9u
cyB0aGF0IHlvdQ0KY2FuIHVzZSBpZiB5b3UgZG9uJ3QgbGlrZSB0aGUgZGVm
YXVsdCBjb25maWd1cmF0aW9uLiBUbyBzZWUgdGhlbSBhbGwsIHR5cGUNCiQg
Li9jb25maWd1cmUgLS1oZWxwDQoNClNvbWUgb2YgdGhlIG1vcmUgY29tbW9u
bHkgdXNlZCBvbmVzIGFyZTogDQoNCgktLXByZWZpeD1CQVNFRElSDQpTZWxl
Y3RzIGEgZGlmZmVyZW50IGJhc2UgZGlyZWN0b3J5IGZvciB0aGUgaW5zdGFs
bGF0aW9uIG9mIHRoZSBQb3N0Z3Jlcw0KY29uZmlndXJhdGlvbi4gVGhlIGRl
ZmF1bHQgaXMgL3Vzci9sb2NhbC9wZ3NxbC4NCg0KCS0td2l0aC10ZW1wbGF0
ZT1URU1QTEFURQ0KVXNlIHRlbXBsYXRlIGZpbGUgVEVNUExBVEUgLSB0aGUg
dGVtcGxhdGUgZmlsZXMgYXJlIGFzc3VtZWQgdG8gYmUgaW4gdGhlDQpkaXJl
Y3Rvcnkgc3JjL3RlbXBsYXRlLCBzbyBsb29rIHRoZXJlIGZvciBwcm9wZXIg
dmFsdWVzLg0KDQoJLS13aXRoLXRjbA0KQnVpbGQgaW50ZXJmYWNlIGxpYnJh
cmllcyBhbmQgcHJvZ3JhbXMgcmVxdWlyaW5nIFRjbC9UaywgaW5jbHVkaW5n
DQpsaWJwZ3RjbCwgcGd0Y2xzaCwgYW5kIHBndGtzaC4NCg0KCS0td2l0aC1w
ZXJsDQpCdWlsZCB0aGUgUGVybCBpbnRlcmZhY2UgbGlicmFyeS4NCg0KCS0t
d2l0aC1vZGJjDQpCdWlsZCB0aGUgT0RCQyBkcml2ZXIgcGFja2FnZS4NCg0K
CS0tZW5hYmxlLWxvY2FsZQ0KRW5hYmxlcyBsb2NhbGUgc3VwcG9ydC4gU2Vl
IHRoZSBmaWxlIFJFQURNRS5sb2NhbGUgZm9yIGRldGFpbHMuDQoNCg0KOC4g
Q29tcGlsZSB0aGUgcHJvZ3JhbS4gVHlwZQ0KJCBjZCBzcmMNCiQgbWFrZSBh
bGwNClRoZSBsYXN0IGxpbmUgZGlzcGxheWVkIHdpbGwgaG9wZWZ1bGx5IGJl
ICJBbGwgb2YgUG9zdGdyZVNRTCBpcw0Kc3VjY2Vzc2Z1bGx5IG1hZGUuIFJl
YWR5IHRvIGluc3RhbGwuIg0KDQpJZiB0aGUgY29tcGlsZXIgZmFpbHMgd2l0
aCBhIG1lc3NhZ2Ugc3RhdGluZyB0aGF0IHRoZSBmbGV4IGNvbW1hbmQgY2Fu
bm90DQpiZSBmb3VuZCB0aGVuIGluc3RhbGwgZmxleCBhcyBkZXNjcmliZWQg
ZWFybGllci4gTmV4dCwgY2hhbmdlIGRpcmVjdG9yeQ0KYmFjayB0byB0aGlz
IGRpcmVjdG9yeSwgdHlwZQ0KJCBtYWtlIGNsZWFuDQp0aGVuIHJlY29tcGls
ZSBhZ2Fpbi4NCg0KQ29tcGlsZXIgb3B0aW9ucywgc3VjaCBhcyBvcHRpbWl6
YXRpb24gYW5kIGRlYnVnZ2luZywgbWF5IGJlIHNwZWNpZmllZCBvbg0KdGhl
IGNvbW1hbmQgbGluZSB1c2luZyB0aGUgQ09QVCB2YXJpYWJsZS4gRm9yIGV4
YW1wbGUsIHR5cGluZw0KJCBtYWtlIENPUFQ9Ii1nIiBhbGwNCndvdWxkIGlu
dm9rZSB5b3VyIGNvbXBpbGVyJ3MgLWcgb3B0aW9uIGluIGFsbCBzdGVwcyBv
ZiB0aGUgYnVpbGQuIFNlZQ0Kc3JjL01ha2VmaWxlLmdsb2JhbC5pbiBmb3Ig
ZnVydGhlciBkZXRhaWxzLg0KDQoNCjkuIEluc3RhbGwgdGhlIHByb2dyYW0u
IFR5cGUgDQokIG1ha2UgaW5zdGFsbA0KVGhlIGxhc3QgbGluZSBkaXNwbGF5
ZWQgd2lsbCBiZSANCm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNy
L3NyYy9wZ3NxbC9zcmMvbWFuJw0KDQoNCjEwLiBJZiBuZWNlc3NhcnksIHRl
bGwgeW91ciBzeXN0ZW0gaG93IHRvIGZpbmQgdGhlIG5ldyBzaGFyZWQgbGli
cmFyaWVzLg0KWW91IGNhbiBkbyBvbmUgb2YgdGhlIGZvbGxvd2luZywgcHJl
ZmVyYWJseSB0aGUgZmlyc3Q6DQphLiBBcyByb290LCBlZGl0IGZpbGUgL2V0
Yy9sZC5zby5jb25mLiBBZGQgYSBsaW5lIA0KL3Vzci9sb2NhbC9wZ3NxbC9s
aWINCnRvIHRoZSBmaWxlLiBUaGVuIHJ1biBjb21tYW5kIC9zYmluL2xkY29u
ZmlnLg0KYi4gSW4gYSBiYXNoIHNoZWxsLCB0eXBlIA0KJCBleHBvcnQgTERf
TElCUkFSWV9QQVRIPS91c3IvbG9jYWwvcGdzcWwvbGliDQpjLiBJbiBhIGNz
aCBzaGVsbCwgdHlwZSANCiQgc2V0ZW52IExEX0xJQlJBUllfUEFUSCAvdXNy
L2xvY2FsL3Bnc3FsL2xpYg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBhYm92
ZSBjb21tYW5kcyBtYXkgdmFyeSB3aWxkbHkgZm9yIGRpZmZlcmVudA0Kb3Bl
cmF0aW5nIHN5c3RlbXMuIENoZWNrIHRoZSBwbGF0Zm9ybSBzcGVjaWZpYyBu
b3Rlcywgc3VjaCBhcyB0aG9zZSBmb3INClVsdHJpeDQueCBvciBhbmQgZm9y
IG5vbi1FTEYgTGludXguIElmLCB3aGVuIHlvdSBjcmVhdGUgdGhlIGRhdGFi
YXNlLCB5b3UNCmdldCB0aGUgbWVzc2FnZQ0KcGdfaWQ6IGNhbid0IGxvYWQg
bGlicmFyeSAnbGlicHEuc28nDQp0aGVuIHRoZSBhYm92ZSBzdGVwIHdhcyBu
ZWNlc3NhcnkuIFNpbXBseSBkbyB0aGlzIHN0ZXAsIHRoZW4gdHJ5IHRvIGNy
ZWF0ZQ0KdGhlIGRhdGFiYXNlIGFnYWluLg0KDQoNCjExLiBJZiB5b3UgdXNl
ZCB0aGUgLS13aXRoLXBlcmwgb3B0aW9uIHRvIGNvbmZpZ3VyZSBhbmQgeW91
IHdlcmUgYW4NCnVucHJpdmlsZWdlZCB1c2VyIGR1cmluZyB0aGUgaW5zdGFs
bGF0aW9uIHByb2Nlc3MsIHRoZW4gdGhlIFBlcmwgbW9kdWxlDQp3b24ndCBo
YXZlIGJlZW4gaW5zdGFsbGVkLCBmb3IgbGFjayBvZiB3cml0ZSBwcml2aWxl
Z2VzIG9uIHRoZSBQZXJsDQpsaWJyYXJ5IGRpcmVjdG9yaWVzLiBZb3UgY2Fu
IGNvbXBsZXRlIGl0cyBpbnN0YWxsYXRpb24sIGVpdGhlciBub3cgb3INCmxh
dGVyLCBieSBkb2luZw0KJCBzdSAtDQokIGNkIC91c3Ivc3JjL3Bnc3FsL3Ny
Yy9pbnRlcmZhY2VzL3Blcmw1DQokIG1ha2UgaW5zdGFsbA0KICAgICAgICAg
ICAgICANCg0KMTIuIFByZXBhcmUgdGhlIFBvc3RncmVzIHN1cGVydXNlciBh
Y2NvdW50LiBPZnRlbiB0aGUgdXNlcm5hbWUgInBvc3RncmVzIiBpcw0KdXNl
ZCBmb3IgdGhpcyBidXQgYW55IHVucHJpdmlsZWdlZCB1c2VyIHdpbGwgc3Vm
ZmljZS4gSXQgbXVzdCAqbm90KiBiZSByb290IG9yDQphbnkgc2ltaWxhcmx5
IHByaXZpbGVnZWQgdXNlciAoYmluLCBrbWVtLCAuLi4pIGZvciB0aGF0IHdv
dWxkIGJlIGEgc2VjdXJpdHkNCnJpc2suDQokIHVzZXJhZGQgcG9zdGdyZXMN
CihUaGUgYWJvdmUgY29tbWFuZCBtYXkgZGlmZmVyIGZyb20gc3lzdGVtIHRv
IHN5c3RlbS4pDQpNYWtlIHRoZSBwb3N0Z3JlcyBpbnN0YWxsYXRpb24gb3du
ZXIgYnkgdGhlIFBvc3RncmVzIHN1cGVydXNlcjoNCiQgY2hvd24gLVIgcG9z
dGdyZXMgL3Vzci9sb2NhbC9wb3N0Z3Jlcw0KDQpBZGQgdGhlIGZvbGxvd2lu
ZyBsaW5lcyB0byB5b3VyIH4vLmJhc2hfcHJvZmlsZSBvciBlcXVpdmFsZW50
Og0KUEFUSD0kUEFUSDovdXNyL2xvY2FsL3Bnc3FsL2Jpbg0KTUFOUEFUSD0k
TUFOUEFUSDovdXNyL2xvY2FsL3Bnc3FsL21hbg0KUEdMSUI9L3Vzci9sb2Nh
bC9wZ3NxbC9saWINClBHREFUQT0vdXNyL2xvY2FsL3Bnc3FsL2RhdGENCmV4
cG9ydCBQQVRIIE1BTlBBVEggUEdMSUIgUEdEQVRBDQoNCkFueSBvcmRpbmFy
eSB1c2VyIHRoYXQgd2lzaGVzIHRvIHVzZSB0aGUgZGF0YWJhc2UgbXVzdCBk
byB0aGUgc2FtZS4NCiAgICAgICAgICAgICAgIA0KU2V2ZXJhbCByZWdyZXNz
aW9uIHRlc3RzIGNvdWxkIGZhaWwgaWYgdGhlIHVzZXIncyBsb2NhbGUgY29s
bGF0aW9uIHNjaGVtZQ0KaXMgZGlmZmVyZW50IGZyb20gdGhhdCBvZiBzdGFu
ZGFyZCBDIGxvY2FsZS4gIElmIHlvdSBjb25maWd1cmUgYW5kIGNvbXBpbGUN
ClBvc3RncmVzIHdpdGggdGhlIC0tZW5hYmxlLWxvY2FsZSBvcHRpb24gdGhl
biBzZXQgbG9jYWxlIGVudmlyb25tZW50IHRvIEMNCihvciB1bnNldCBhbGwg
TENfKiB2YXJpYWJsZXMpIGJ5IHB1dHRpbmcgdGhlc2UgYWRkaXRpb25hbCBs
aW5lcyB0byB5b3VyDQpsb2dpbiBlbnZpcm9ubWVudCBiZWZvcmUgc3RhcnRp
bmcgdGhlIGRhdGFiYXNlIHNlcnZlcjoNCg0KTENfQ09MTEFURT1DDQpMQ19D
VFlQRT1DDQpMQ19DT0xMQVRFPUMNCmV4cG9ydCBMQ19DT0xMQVRFIExDX0NU
WVBFIExDX0NPTExBVEUNCiAgICAgICAgICAgICAgICAgICAgIA0KTG9nIGlu
dG8geW91ciBwb3N0Z3JlcyBzdXBlcnVzZXIgYWNjb3VudDoNCiQgc3UgLSBw
b3N0Z3Jlcw0KICAgICAgICAgICAgICAgICAgICAgDQoNCjEzLiBDcmVhdGUg
dGhlIGRhdGFiYXNlIGluc3RhbGxhdGlvbiBmcm9tIHlvdXIgUG9zdGdyZXMg
c3VwZXJ1c2VyIGFjY291bnQNCih0eXBpY2FsbHkgYWNjb3VudCBwb3N0Z3Jl
cykuIERvIG5vdCBkbyB0aGUgZm9sbG93aW5nIGFzIHJvb3QhIFRoaXMgd291
bGQNCmJlIGEgbWFqb3Igc2VjdXJpdHkgaG9sZS4gVHlwZQ0KJCBpbml0ZGIN
Cg0KDQoxNC4gQnJpZWZseSB0ZXN0IHRoYXQgdGhlIGJhY2tlbmQgd2lsbCBz
dGFydCBhbmQgcnVuIGJ5IHJ1bm5pbmcgaXQgZnJvbSB0aGUNCmNvbW1hbmQg
bGluZS4gU3RhcnQgdGhlIHBvc3RtYXN0ZXIgZGFlbW9uIHJ1bm5pbmcgaW4g
dGhlIGJhY2tncm91bmQgYnkgdHlwaW5nIA0KJCBwb3N0bWFzdGVyIC1pDQpD
b25uZWN0IHRvIHRoZSBhbHdheXMgZXhpc3RpbmcgdGVtcGxhdGUgZGF0YWJh
c2U6DQokIHBzcWwgdGVtcGxhdGUxDQpBbmQgcnVuIGEgc2FtcGxlIHF1ZXJ5
OiANCnBvc3RncmVzPT4gU0VMRUNUIGRhdGV0aW1lICdub3cnOw0KRXhpdA0K
cG9zdGdyZXM9PiBccQ0KDQoNCjE1LiBSdW4gcG9zdG1hc3RlciBpbiB0aGUg
YmFja2dyb3VuZCBmcm9tIHlvdXIgUG9zdGdyZXMgc3VwZXJ1c2VyIGFjY291
bnQNCih0eXBpY2FsbHkgYWNjb3VudCBwb3N0Z3JlcykuIERvIG5vdCBydW4g
cG9zdG1hc3RlciBmcm9tIHRoZSByb290IGFjY291bnQhDQoNClVzdWFsbHks
IHlvdSB3aWxsIHdhbnQgdG8gbW9kaWZ5IHlvdXIgY29tcHV0ZXIgc28gdGhh
dCBpdCB3aWxsDQphdXRvbWF0aWNhbGx5IHN0YXJ0IHBvc3RtYXN0ZXIgd2hl
bmV2ZXIgaXQgYm9vdHMuIEl0IGlzIG5vdCByZXF1aXJlZDsgdGhlDQpQb3N0
Z3JlcyBzZXJ2ZXIgY2FuIGJlIHJ1biBzdWNjZXNzZnVsbHkgZnJvbSBub24t
cHJpdmlsZWdlZCBhY2NvdW50cw0Kd2l0aG91dCByb290IGludGVydmVudGlv
bi4gSGVyZSBhcmUgc29tZSBzdWdnZXN0aW9ucyBvbiBob3cgdG8gZG8gdGhp
cywNCmNvbnRyaWJ1dGVkIGJ5IHZhcmlvdXMgdXNlcnMuDQoNCldoYXRldmVy
IHlvdSBkbywgcG9zdG1hc3RlciBtdXN0IGJlIHJ1biBieSB0aGUgUG9zdGdy
ZXMgc3VwZXJ1c2VyIGFuZCBub3QNCmJ5IHJvb3QuICBUaGlzIGlzIHdoeSBh
bGwgb2YgdGhlIGV4YW1wbGVzIGJlbG93IHN0YXJ0IGJ5IHN3aXRjaGluZyB1
c2VyDQooc3UpIHRvIHBvc3RncmVzLiBUaGVzZSBjb21tYW5kcyBhbHNvIHRh
a2UgaW50byBhY2NvdW50IHRoZSBmYWN0IHRoYXQNCmVudmlyb25tZW50IHZh
cmlhYmxlcyBsaWtlIFBBVEggYW5kIFBHREFUQSBtYXkgbm90IGJlIHNldCBw
cm9wZXJseS4gVGhlDQpleGFtcGxlcyBhcmUgYXMgZm9sbG93cy4gVXNlIHRo
ZW0gd2l0aCBleHRyZW1lIGNhdXRpb24uDQoNCm8gIElmIHlvdSBhcmUgaW5z
dGFsbGluZyBmcm9tIGEgbm9uLXByaXZpbGVnZWQgYWNjb3VudCBhbmQgaGF2
ZSBubyByb290IGFjY2VzcywNCiAgIHRoZW4gc3RhcnQgdGhlIHBvc3RtYXN0
ZXIgYW5kIHNlbmQgaXQgdG8gdGhlIGJhY2tncm91bmQ6IA0KICAgJCBjZA0K
ICAgJCBub2h1cCBwb3N0bWFzdGVyID4gcmVncmVzcy5sb2cgMj4mMSAmDQpv
ICBFZGl0IGZpbGUgcmMubG9jYWwgb24gTmV0QlNEIG9yIGZpbGUgcmMyLmQg
b24gU1BBUkMgU29sYXJpcyAyLjUuMSB0bw0KICAgY29udGFpbiB0aGUgZm9s
bG93aW5nIHNpbmdsZSBsaW5lOiANCiAgIHN1IHBvc3RncmVzIC1jICIvdXNy
L2xvY2FsL3Bnc3FsL2Jpbi9wb3N0bWFzdGVyIC1TIC1EIC91c3IvbG9jYWwv
cGdzcWwvZGF0YSINCm8gIEluIEZyZWVCU0QgMi4yLVJFTEVBU0UgZWRpdCAv
dXNyL2xvY2FsL2V0Yy9yYy5kL3Bnc3FsLnNoIHRvIGNvbnRhaW4gdGhlIA0K
ICAgZm9sbG93aW5nIGxpbmVzIGFuZCBtYWtlIGl0IGNobW9kIDc1NSBhbmQg
Y2hvd24gcm9vdDpiaW4uIA0KICAgIyEvYmluL3NoDQogICBbIC14IC91c3Iv
bG9jYWwvcGdzcWwvYmluL3Bvc3RtYXN0ZXIgXSAmJiB7DQogICBzdSAtbCBw
Z3NxbCAtYyAnZXhlYyAvdXNyL2xvY2FsL3Bnc3FsL2Jpbi9wb3N0bWFzdGVy
DQogICAgICAgLUQvdXNyL2xvY2FsL3Bnc3FsL2RhdGEgLVMgLW8gLUYgPiAv
dXNyL2xvY2FsL3Bnc3FsL2VycmxvZycgJg0KICAgZWNobyAtbiAnIHBnc3Fs
Jw0KICAgfQ0KbyAgSW4gUmVkSGF0IExpbnV4IGFkZCBhIGZpbGUgL2V0Yy9y
Yy5kL2luaXQuZC9wb3N0Z3Jlcy5pbml0IHdoaWNoIGlzIGJhc2VkIG9uIA0K
ICAgdGhlIGV4YW1wbGUgaW4gY29udHJpYi9saW51eC8uIFRoZW4gdHlwZQ0K
ICAgJCBjaGtjb25maWcgLS1hZGQgcG9zdGdyZXMNCg0KDQoxNi4gUnVuIHRo
ZSByZWdyZXNzaW9uIHRlc3RzLiBUaGUgZmlsZQ0KL3Vzci9zcmMvcGdzcWwv
c3JjL3Rlc3QvcmVncmVzcy9SRUFETUUgaGFzIGRldGFpbGVkIGluc3RydWN0
aW9ucyBmb3INCnJ1bm5pbmcgYW5kIGludGVycHJldGluZyB0aGUgcmVncmVz
c2lvbiB0ZXN0cy4gV2hpbGUgaXQgaXMgbm90IG1hbmRhdG9yeSB0byBydW4N
CnRoZSByZWdyZXNzaW9uIHRlc3QsIGl0IGlzIHByb2JhYmx5IGdvb2QgdG8g
a25vdyB3aGV0aGVyIG9yIG5vdCB5b3VyIGRhdGFiYXNlDQpzZXJ2ZXIgZnVu
Y3Rpb25zIGxpa2UgdGhlIGRldmVsb3BlcnMgaGFkIGl0IGluIG1pbmQgYmVm
b3JlIHJ1bm5pbmcgYW55dGhpbmcNCmltcG9ydGFudCBvbiBpdC4NCg0KDQox
Ny4gSWYgeW91IGhhdmVuJ3QgYWxyZWFkeSBkb25lIHNvLCB0aGlzIHdvdWxk
IGJlIGEgZ29vZCB0aW1lIHRvIG1vZGlmeQ0KeW91ciBjb21wdXRlciB0byBk
byByZWd1bGFyIG1haW50YWluZW5jZS4gVGhlIGZvbGxvd2luZyBzaG91bGQg
YmUgZG9uZSBhdA0KcmVndWxhciBpbnRlcnZhbHM6DQoNCk1pbmltYWwgQmFj
a3VwIFByb2NlZHVyZQ0KMS4gUnVuIHRoZSBTUUwgY29tbWFuZCBWQUNVVU0u
IFRoaXMgd2lsbCBjbGVhbiB1cCB5b3VyIGRhdGFiYXNlLg0KMi4gQmFjayB1
cCB5b3VyIHN5c3RlbS4gKFlvdSBzaG91bGQgcHJvYmFibHkga2VlcCB0aGUg
bGFzdCBmZXcgYmFja3VwcyBvbg0KaGFuZC4pIFByZWZlcmFibHksIG5vIG9u
ZSBlbHNlIHNob3VsZCBiZSB1c2luZyB0aGUgc3lzdGVtIGF0IHRoZSB0aW1l
Lg0KDQoNCjE4LiBJZiB5b3UgYXJlIHVwZ3JhZGluZyBhbiBleGlzdGluZyBz
eXN0ZW0gdGhlbiByZWluc3RhbGwgeW91ciBvbGQNCmRhdGFiYXNlLiBUeXBl
DQokIHBzcWwgLWUgdGVtcGxhdGUxIDwgZGIub3V0DQoNCklmIHlvdXIgcHJl
LXY2LjIgZGF0YWJhc2UgdXNlcyBlaXRoZXIgcGF0aCBvciBwb2x5Z29uIGdl
b21ldHJpYyBkYXRhDQp0eXBlcywgdGhlbiB5b3Ugd2lsbCBuZWVkIHRvIHVw
Z3JhZGUgYW55IGNvbHVtbnMgY29udGFpbmluZyB0aG9zZSB0eXBlcy4NClRv
IGRvIHNvLCB0eXBlIChmcm9tIHdpdGhpbiBwc3FsKQ0KPT4gVVBEQVRFIEZp
cnN0VGFibGUgU0VUIFBhdGhDb2wgPSBVcGdyYWRlUGF0aChQYXRoQ29sKTsN
Cj0+IFVQREFURSBTZWNvbmRUYWJsZSBTRVQgUGF0aENvbCA9IFVwZ3JhZGVQ
YXRoKFBhdGhDb2wpOw0KICAgIC4uLg0KPT4gVkFDVVVNOw0KDQpVcGdyYWRl
UGF0aCgpIGNoZWNrcyB0byBzZWUgdGhhdCBhIHBhdGggdmFsdWUgaXMgY29u
c2lzdGFudCB3aXRoIHRoZSBvbGQNCnN5bnRheCwgYW5kIHdpbGwgbm90IHVw
ZGF0ZSBhIGNvbHVtbiB3aGljaCBmYWlscyB0aGF0IGV4YW1pbmF0aW9uLiAg
DQpVcGdyYWRlUG9seSgpIGNhbm5vdCB2ZXJpZnkgdGhhdCBhIHBvbHlnb24g
aXMgaW4gZmFjdCBmcm9tIGFuIG9sZCBzeW50YXgsDQpidXQgUmV2ZXJ0UG9s
eSgpIGlzIHByb3ZpZGVkIHRvIHJldmVyc2UgdGhlIGVmZmVjdHMgb2YgYSBt
aXMtYXBwbGllZA0KdXBncmFkZS4NCg0KDQoxOS4gQ2xlYW4gdXAgYWZ0ZXIg
eW91cnNlbGYuIFR5cGUgDQokIHJtIC1yZiAvdXNyL3NyYy9wZ3NxbF82XzUN
CiQgcm0gLXJmIC91c3IvbG9jYWwvcGdzcWxfNl81DQojIEFsc28gZGVsZXRl
IG9sZCBkYXRhYmFzZSBkaXJlY3RvcnkgdHJlZSBpZiBpdCBpcyBub3QgaW4N
CiMgIC91c3IvbG9jYWwvcGdzcWxfNl81L2RhdGENCiQgcm0gfi9wb3N0Z3Jl
c3FsLXY2LjUudGFyLmd6DQoNCg0KMjAuIE5vdyBjcmVhdGUsIGFjY2VzcyBh
bmQgbWFuaXB1bGF0ZSBkYXRhYmFzZXMgYXMgZGVzaXJlZC4gV3JpdGUgY2xp
ZW50DQpwcm9ncmFtcyB0byBhY2Nlc3MgdGhlIGRhdGFiYXNlIHNlcnZlci4g
SW4gb3RoZXIgd29yZHMsIGVuam95IQ0KDQpRdWVzdGlvbnM/IEJ1Z3M/IEZl
ZWRiYWNrPyBGaXJzdCwgcmVhZCB0aGUgZmlsZXMgaW4gZGlyZWN0b3J5DQov
dXNyL3NyYy9wZ3NxbC9kb2MvLiBUaGUgRkFRIGluIHRoaXMgZGlyZWN0b3J5
IG1heSBiZSBwYXJ0aWN1bGFybHkgdXNlZnVsLg0KSWYgUG9zdGdyZXMgZmFp
bGVkIHRvIGNvbXBpbGUgb24geW91ciBjb21wdXRlciB0aGVuIGZpbGwgb3V0
IHRoZSBmb3JtIGluDQpmaWxlIC91c3Ivc3JjL3Bnc3FsL2RvYy9idWcudGVt
cGxhdGUgYW5kIG1haWwgaXQgdG8gdGhlIGxvY2F0aW9uIGluZGljYXRlZA0K
YXQgdGhlIHRvcCBvZiB0aGUgZm9ybS4gQ2hlY2sgb24gdGhlIHdlYiBzaXRl
IGF0IGh0dHA6Ly93d3cucG9zdGdyZXNxbC5vcmcNCkZvciBtb3JlIGluZm9y
bWF0aW9uIG9uIHRoZSB2YXJpb3VzIHN1cHBvcnQgbWFpbGluZyBsaXN0cy4N
Cg0KDQoNCkFwcGVuZGl4IEk6IFBsYXlpbmcgd2l0aCBQb3N0Z3Jlcw0KDQpB
ZnRlciBQb3N0Z3JlcyBpcyBpbnN0YWxsZWQsIGEgZGF0YWJhc2Ugc3lzdGVt
IGlzIGNyZWF0ZWQsIGEgcG9zdG1hc3Rlcg0KZGFlbW9uIGlzIHJ1bm5pbmcs
IGFuZCB0aGUgcmVncmVzc2lvbiB0ZXN0cyBoYXZlIHBhc3NlZCwgeW91J2xs
IHdhbnQgdG8NCnNlZSBQb3N0Z3JlcyBkbyBzb21ldGhpbmcuIFRoYXQncyBl
YXN5LiBJbnZva2UgdGhlIGludGVyYWN0aXZlIGludGVyZmFjZQ0KdG8gUG9z
dGdyZXMsIHBzcWw6DQoNCiQgcHNxbCB0ZW1wbGF0ZTENCg0KKHBzcWwgaGFz
IHRvIG9wZW4gYSBwYXJ0aWN1bGFyIGRhdGFiYXNlLCBidXQgYXQgdGhpcyBw
b2ludCB0aGUgb25seSBvbmUNCnRoYXQgZXhpc3RzIGlzIHRoZSB0ZW1wbGF0
ZTEgZGF0YWJhc2UsIHdoaWNoIGFsd2F5cyBleGlzdHMuIFdlIHdpbGwNCmNv
bm5lY3QgdG8gaXQgb25seSBsb25nIGVub3VnaCB0byBjcmVhdGUgYW5vdGhl
ciBvbmUgYW5kIHN3aXRjaCB0byBpdC4pDQoNClRoZSByZXNwb25zZSBmcm9t
IHBzcWwgaXM6IA0KDQpXZWxjb21lIHRvIHRoZSBQT1NUR1JFU1FMIGludGVy
YWN0aXZlIHNxbCBtb25pdG9yOg0KICBQbGVhc2UgcmVhZCB0aGUgZmlsZSBD
T1BZUklHSFQgZm9yIGNvcHlyaWdodCB0ZXJtcyBvZiBQT1NUR1JFU1FMDQpb
UG9zdGdyZVNRTCA2LjUuMCBvbiBpNTg2LXBjLWxpbnV4LWdudSwgY29tcGls
ZWQgYnkgZWdjcyBdDQoNCiAgIHR5cGUgXD8gZm9yIGhlbHAgb24gc2xhc2gg
Y29tbWFuZHMNCiAgIHR5cGUgXHEgdG8gcXVpdA0KICAgdHlwZSBcZyBvciB0
ZXJtaW5hdGUgd2l0aCBzZW1pY29sb24gdG8gZXhlY3V0ZSBxdWVyeQ0KIFlv
dSBhcmUgY3VycmVudGx5IGNvbm5lY3RlZCB0byB0aGUgZGF0YWJhc2U6IHRl
bXBsYXRlMQ0KDQp0ZW1wbGF0ZTE9Pg0KIA0KQ3JlYXRlIHRoZSBkYXRhYmFz
ZSBmb286IA0KDQp0ZW1wbGF0ZTE9PiBjcmVhdGUgZGF0YWJhc2UgZm9vOw0K
Q1JFQVRFREINCg0KKEdldCBpbiB0aGUgaGFiaXQgb2YgaW5jbHVkaW5nIHRo
b3NlIFNRTCBzZW1pY29sb25zLiAgUHNxbCB3b24ndCBleGVjdXRlDQphbnl0
aGluZyB1bnRpbCBpdCBzZWVzIHRoZSBzZW1pY29sb24gb3IgYSAiXGciIGFu
ZCB0aGUgc2VtaWNvbG9uIGlzDQpyZXF1aXJlZCB0byBkZWxpbWl0IG11bHRp
cGxlIHN0YXRlbWVudHMuKQ0KDQpOb3cgY29ubmVjdCB0byB0aGUgbmV3IGRh
dGFiYXNlOiANCg0KdGVtcGxhdGUxPT4gXGMgZm9vDQpjb25uZWN0aW5nIHRv
IG5ldyBkYXRhYmFzZTogZm9vDQoNCigic2xhc2giIGNvbW1hbmRzIGFyZW4n
dCBTUUwsIHNvIG5vIHNlbWljb2xvbi4gVXNlIFw/ICB0byBzZWUgYWxsIHRo
ZQ0Kc2xhc2ggY29tbWFuZHMuKQ0KDQpBbmQgY3JlYXRlIGEgdGFibGU6IA0K
DQpmb289PiBjcmVhdGUgdGFibGUgYmFyIChpIGludDQsIGMgY2hhcigxNikp
Ow0KQ1JFQVRFDQoNClRoZW4gaW5zcGVjdCB0aGUgbmV3IHRhYmxlOiANCg0K
Zm9vPT4gXGQgYmFyDQpUYWJsZSAgICA9IGJhcg0KKy0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSstLS0tLS0tKw0KfCAgICAgICAgICAgICAgRmllbGQgICAg
ICAgICAgICAgICB8ICAgICAgICAgICAgICBUeXBlICAgICAgICAgICAgICAg
IHwgTGVuZ3RofA0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t
Kw0KfCBpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IGludDQg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIDQgfA0KfCBjICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IGNoYXIoKSAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwgICAgMTYgfA0KKy0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSstLS0tLS0tKw0KDQpBbmQgc28gb24uIFlvdSBnZXQgdGhl
IGlkZWEuDQo=
--8323328-651635041-937944888=:1899--
From bouncefilter Tue Sep 21 17:59:38 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id RAA11423
for <docs@postgreSQL.org>; Tue, 21 Sep 1999 17:59:04 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 15173 invoked by uid 1001); 21 Sep 1999 21:59:07 -0000
Message-ID: <XFMail.990921175907.vev@michvhf.com>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.LNX.4.10.9909212031480.1899-200000@peter-e.yi.org>
Date: Tue, 21 Sep 1999 17:59:07 -0400 (EDT)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: Peter Eisentraut <peter_e@gmx.net>
Subject: RE: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)
Cc: The Hermit Hacker <scrappy@hub.org>, docs@postgreSQL.org,
Bruce Momjian <maillist@candle.pha.pa.us>
On 21-Sep-99 Peter Eisentraut wrote:
On Sep 20, Bruce Momjian mentioned:
I agree our INSTALL is very large. Is there some way we can simplify
the install process?On the one hand a database server is probably not your everyday
./configure && make && make install program you get from freshmeat and you
do want to put some time into a proper installation.
I disagree. When you remove the 'change to this user, install from this
directory' stuff and get down to the actual install, it is just as simple
as ./configure && make && make install. That's how I've done it the last
few times. And each time I've enabled different features.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Tue Sep 21 19:02:42 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id TAA21963;
Tue, 21 Sep 1999 19:02:30 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-admin@postgreSQL.org
id m11TYox-0003kLC; Wed, 22 Sep 99 00:55 MET DST
Message-Id: <m11TYox-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Problems with src/pl/tcl/mkMakefile.tcldefs.sh.in in
6.5
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Wed, 22 Sep 1999 00:55:35 +0200 (MET DST)
Cc: pgsql-hackers@thewrittenword.com, pgsql-hackers@postgreSQL.org,
pgsql-admin@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199909212139.RAA21058@candle.pha.pa.us> from "Bruce Momjian" at
Sep 21, 99 05:39:54 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Bruce Momjian wrote:
I believe this is fixed.
Again one of the frequently appearing items. So I would call
it more "hacked quiet - for now" instead of "fixed".
The script is only called if PostgreSQL is configured
--with_tcl. In that case, missing the Tcl(/Tk) includes
and/or libs would cause errors and a compilation abort. Can't
we assume that if the user configured with Tcl, she would at
least have a working tclsh(1)? I think we can. I don't know
of any "normal" Tcl-installation where the libs are present
but no working tclsh(1).
Since Tcl itself has much better capabilities than a sh(1) or
sed(1), it might be reasonable to source in the tclConfig.sh
into mkMakefile.tclsh.sh and pipe a "set" trough a tcl script
that does the real conversion into proper Makefile escaping.
An advantage would be that the Tcl script could check if the
version of the systems default tclsh(1) is the same as the
one in the choosen tclConfig.sh file and notice the user if
not. Using different Tcl versions in the libs and includes
than in the tclsh(1) executable could cause horrible
problems. I'm unhappy with the current libpgtcl for a long
time, but the changes I have in mind would make it
incompatible with pre-8.0 Tcl. So the changes will cause a
bunch of #if...#else...#endif that MUST match the later used
tclsh(1) at compile time or the dynamic loader of Tcl would
fail.
Jan
BTW: Is it only me or do others too wonder why their private
wish-list is sometimes longer than our official TODO?
For Digital UNIX 4.0D, shared libraries are created by:
$ ld -shared -expect_unresolved "*" -o foo.so [objects]This presents a problem for mkMakefile.tcldefs.sh.in. In tclConfig.sh:
TCL_SHLIB_LD='ld -shared -expect_unresolved "*"'In mkMakefile.tcldefs.sh.in:
cat @TCL_CONFIG_SH@ |
egrep '^TCL_|^TK_' |
while read inp
do
eval eval echo $inp
done >Makefile.tcldefsBecause of this, we wind up with the following in Makefile.tcldefs to
created shared libraries on Digital UNIX because of the eval:
TCL_SHLIB_LD=ld -shared -expect_unresolved *The "*" needs to be quoted to avoid shell expansion. How about the
following:
cat @TCL_CONFIG_SH@ |
egrep '^TCL_|^TK_' |
sed -e "s/^\([^=]*\)='\(.*\)'$/\1=\2/"--
albert chin (china@thewrittenword.com)
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Tue Sep 21 23:18:34 1999
Received: from postal.dn.net (postal.dn.net [207.226.170.20])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA61504
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 23:17:40 -0400 (EDT)
(envelope-from frankpit@pop.dn.net)
From: frankpit@pop.dn.net
Received: from pop.dn.net (pm-72.ppp.wdc.dn.net [207.226.188.72])
by postal.dn.net (8.9.3/postal) with ESMTP id XAA05258;
Tue, 21 Sep 1999 23:17:06 -0400 (EDT)
Sender: bernie@postal.dn.net
Message-ID: <37E80F8D.2E6D6736@pop.dn.net>
Date: Tue, 21 Sep 1999 19:06:53 -0400
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.34 i686)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Early evaluation of constant expresions (with PATCH)
References: <24796.937964075@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Bernard Frankpitt <frankpit@pop.dn.net> writes:
The solution that I propose is to include code in the optimizer that
picks functions with constant arguments out of a qualification
clause, and evaluates them.This is something I had on my own to-do list, and I'm glad to see
someone beat me to it. But you've only done half the job: you
should also be folding operators with constant arguments.Also, you need to be wary of functions like now() and random().
There probably isn't any other way to handle these than to add a
column to pg_proc flagging functions that can't be constant-folded.
I actually do the operators as well, and also boolean operators (which
are handled by special Expr nodes).
I puzzled over case of now() for a while but I don't think that it
raises a problem.
For queries like
SELECT * FROM t WHERE t.a < now();
Early evaluation seems quite reasonable. Now means a fixed time close to
the time the backend received the query. It seems to me that all the
now() calls in a query should return values pretty close to each other.
A query like
SELECT * FROM t1 t2 WHERE t1.a < now() AND t2.a < now();
will have two values of now that are very close, since the evaluations
both happen in the planner. People who expect the two now() calls to
give exactly the same value in this case are expecting too much, queries
like this should be rewritten
SELECT * FROM t1 t2 WHERE t1.a < now() AND t1.a = t2.a;
In fact istm that the correct way to handle now() would be to have a
value that is constant over a transation, and comensurate with the
numbering of tids.
I don't think that random() is a problem at all. It gets called once
each time it is written in the query string. That is certainly a
reasonable interpretation of its meaning.
is, I chose to put it in
plan/initsplan.c:add_restrict_and_join_to_rels().I believe it would be best to do it considerably earlier, specifically,
before cnfify(). It might even be worth running the code twice,
once before and once after cnfify.Also, probably we should apply it to the targetlist as well as the qual.
Yes, close to cnfify might be a better place. I only did it for the
quals because I don't think I understand the other parts of the plan
trees well enough. The function is quite easy to use though, it acts as
a filter on connected subtrees that consist of List nodes and all Expr
nodes other than
SUBPLAN_EXPR nodes. Because of the recursive way that qual plans are
built, subplans are still optimized.
Another factor about positioning of the filter that I was uncertain
about was time expense. Is the time taken by multiple tree walks in the
planner
very significant in the overall scheme of things?
Bernie
From bouncefilter Tue Sep 21 19:12:50 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id TAA23669;
Tue, 21 Sep 1999 19:12:09 -0400 (EDT) (envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: Bill Geddes <geddes@col.hp.com>
X-Newsgroups: comp.databases.postgresql.announce,
comp.databases.postgresql.bugs, comp.databases.postgresql.docs,
comp.databases.postgresql.hackers,
comp.databases.postgresql.interfaces,
comp.databases.postgresql.patches,
comp.databases.postgresql.ports, comp.databases
Subject: Re: Installing PostgreSQL
Date: 21 Sep 1999 23:11:59 GMT
Organization: Debian GNU/Linux site
Lines: 23
Message-ID: <7s93bv$1vp$1@nonews.col.hp.com>
References: <fvvF3.295$I6.8383@typ12.nn.bcandid.com>
User-Agent: tin/pre-1.4-19990805 ("Preacher Man") (UNIX) (Linux/2.2.10 (i586))
To:
pgsql-hackers@postgresql.org.pgsql-announce@postgresql.org.pgsql-bugs@postgresql.org.pgsql-docs@postgresql.org.pgsql-interfaces@postgresql.org.pgsql-patches@postgresql.org.pgsql-ports@postgresql.org
David Godin <godind@remove_this.voxco.com> wrote:
Hi all,
This is the output of initdb after a clean install of all the 6.5.1-2 RPMs
I downloaded from ftp.postgreSQL.org. To install them I did an "rpm -ivh post*".
.
.
.
It's obvious i'm doing something wrong! Can someone help me?
David Godin
godind@REMOVE_THIS.voxco.com
I have installed postgres on a few Debian systems - and have been
able to test the postgresql database just fine right out of the
box. Perhaps you could take the debian package, run it through
alien and install it instead of your rpm package. Some extra work,
but...
--
Bill Geddes
geddes@col.hp.com
From bouncefilter Tue Sep 21 19:39:39 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA28058;
Tue, 21 Sep 1999 19:38:57 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id TAA22045;
Tue, 21 Sep 1999 19:38:42 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909212338.TAA22045@candle.pha.pa.us>
Subject: Re: [HACKERS] Problems with src/pl/tcl/mkMakefile.tcldefs.sh.in in
6.5
In-Reply-To: <m11TYox-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Sep 22, 1999 00:55:35 am"
To: Jan Wieck <wieck@debis.com>
Date: Tue, 21 Sep 1999 19:38:42 -0400 (EDT)
CC: pgsql-hackers@thewrittenword.com, pgsql-hackers@postgreSQL.org,
pgsql-admin@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Jan
BTW: Is it only me or do others too wonder why their private
wish-list is sometimes longer than our official TODO?
That's bad. Our official TODO is very large.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Tue Sep 21 21:08:40 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA39842
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 21:08:19 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA24666;
Tue, 21 Sep 1999 21:07:43 -0400 (EDT)
To: t-ishii@sra.co.jp
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster disappears
In-reply-to: Your message of Wed, 22 Sep 1999 00:27:55 +0900
<199909211527.AAA01357@srapc451.sra.co.jp>
Date: Tue, 21 Sep 1999 21:07:43 -0400
Message-ID: <24664.937962463@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
Seems to me that the correct fix is to have reaper() save and restore
the outer value of errno, not to hack the main line to ignore the
most probable state left over from reaper(). Otherwise you still choke
if some other value gets returned from whatever call reaper() does
last.
Not sure. reaper() may be called while reaper() is executing if a new
SIGCHLD is raised. How do you handle this case?
No, because the signal is disabled when the trap is taken, and then not
re-enabled until reaper() does pqsignal() just before exiting. We don't
really care if a new signal recursively interrupts reaper() at that
point, but bad things would happen if there were a recursive interrupt
earlier while we were diddling the list of children. (Cf. comments in
the existing code where SIGCHLD is disabled while we add a child...)
In any case, it's not a problem: if each level of reaper does
reaper()
{
int save_errno = errno;
...
errno = save_errno; /* restore errno of interrupted code */
}
then a recursive interrupt might be saving/restoring the errno value
that existed in the next outer interrupt, rather than the value that
is truly at the outer level, but that's what stacks are for ;-)
Moreover, you're not actually checking what the select() did unless
you do it that way.
Sorry, I don't understand this. Can you explain, please?
If you don't have the signal routine save/restore errno, then (when this
problem occurs) you are not seeing the errno returned by the select(),
but one left over from reaper()'s activity. If the select() failed, you
won't know it.
Curious that this sort of problem is not seen more often --- I wonder
if most Unixes arrange to save/restore errno around a signal handler
for you?
Maybe because the situation I have pointed out is relatively rare.
Well, the window for trouble is awfully tiny in this particular code of
ours, but it might be larger in other programs. Yet I don't think I've
ever heard a programming recommendation to save/restore errno in signal
handlers...
regards, tom lane
From bouncefilter Tue Sep 21 21:12:40 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA40432
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 21:11:53 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA24685;
Tue, 21 Sep 1999 21:11:05 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Partial fix for INSERT...SELECT problems
In-reply-to: Your message of Tue, 21 Sep 1999 15:40:23 -0400 (EDT)
<199909211940.PAA15682@candle.pha.pa.us>
Date: Tue, 21 Sep 1999 21:11:04 -0400
Message-ID: <24683.937962664@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
Tom, is this fixed?
Yes, for 6.6.
I have committed some fixes that prevent resjunk targets from being
assigned to output columns in an INSERT/SELECT. This partially fixes
the problem Michael Davis reported a few weeks ago. However, there's
still a bug with confusion about column names. Givencreate table foo (a int4, b int4);
CREATE
create table bar (c int4, d int4);
CREATEwe can do
select c, sum(d) from bar group by c;
but not
insert into foo select c, sum(d) from bar group by c;
ERROR: Illegal use of aggregates or non-group column in target listThe problem here is that the target expressions of the select have
been relabeled with foo's column names before GROUP BY is processed.
If you refer to them by the output column names then it works:insert into foo select c, sum(d) from bar group by a;
INSERT 279412 1You can think of the query as having been rewritten to
insert into foo select c AS a, sum(d) AS b from bar group by a;
in which case the behavior makes some kind of sense. However,
I think that this behavior is neither intuitive nor in conformance
with SQL92's scoping rules. As far as I can tell, the definition
of the result of "select c, sum(d) from bar group by c" is independent
of whether it is inside an INSERT or not.Fixing this appears to require a substantial rearrangement of code
inside the parser, which I'm real hesitant to do with only a week to go
till 6.5 release. I propose leaving this issue on the "to fix" list for
6.6. Comments?BTW, although Davis claimed this was broken sometime during April, 6.4.2
shows the same bugs ... I think it's been wrong for a long time.
From bouncefilter Tue Sep 21 21:17:44 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA41228
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 21:17:34 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA24702;
Tue, 21 Sep 1999 21:16:43 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Edmund Mergl <E.Mergl@bawue.de>,
PostgreSQL Hackers Mailinglist <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] strange behavior of UPDATE
In-reply-to: Your message of Tue, 21 Sep 1999 15:42:31 -0400 (EDT)
<199909211942.PAA15704@candle.pha.pa.us>
Date: Tue, 21 Sep 1999 21:16:43 -0400
Message-ID: <24700.937963003@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
Tom, I assume this is done, right?
Only partly. I changed _bt_binsrch to use a pure binary search,
but didn't yet get around to fixing _bt_findsplitloc (it's more
complicated :-().
Vadim seemed to think that a better solution would be to fix the
comparison rules so that no two entries are ever considered to have
equal keys anyway. So I put my change on the back burner ... but if
his change doesn't happen, mine ought to get done.
I wrote:
then a possible explanation for the problem would be that our
btree index code isn't very fast when there are large numbers of
identical keys.Ah-hah, a lucky guess! I went back and looked at the profile stats
I'd extracted from Edmund's "update" example. This Linux box has
the same semi-functional gprof as someone else was using a while
ago --- the timings are bogus, but the call counts seem right.
And what I find are entries like this:0.00 0.00 284977/284977 _bt_binsrch [3174]
[3177] 0.0 0.00 0.00 284977 _bt_firsteq [3177]
0.00 0.00 21784948/24713758 _bt_compare [3169]0.00 0.00 426/35632 _bt_split [53]
0.00 0.00 35206/35632 _bt_insertonpg [45]
[3185] 0.0 0.00 0.00 35632 _bt_findsplitloc [3185]
0.00 0.00 5093972/8907411 _bt_itemcmp [3171]In other words, _bt_firsteq is averaging almost 100 comparisons per
call, _bt_findsplitloc well over that. Both of these routines are
evidently designed on the assumption that there will be relatively
few duplicate keys --- they reduce to linear scans when there are
many duplicates._bt_firsteq shouldn't exist at all; the only routine that calls it
is _bt_binsrch, which does a fast binary search of the index page.
_bt_binsrch should be fixed so that the binary search logic does the
right thing for equal-key cases, rather than degrading to a linear
search. I am less confident that I understand _bt_findsplitloc's place
in the great scheme of things, but it could certainly be revised to use
a binary search rather than linear scan.This benchmark is clearly overemphasizing the equal-key case, but
I think it ought to be fixed independently of whether we want to
look good on a dubious benchmark ... equal keys are not uncommon in
real-world scenarios after all.Next question is do we want to risk twiddling this code so soon before
6.5, or wait till after?
From bouncefilter Tue Sep 21 21:20:47 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA41858
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 21:20:13 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA24723;
Tue, 21 Sep 1999 21:19:31 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] inherited GROUP BY is busted ... I need some help here
In-reply-to: Your message of Tue, 21 Sep 1999 15:46:24 -0400 (EDT)
<199909211946.PAA15803@candle.pha.pa.us>
Date: Tue, 21 Sep 1999 21:19:30 -0400
Message-ID: <24721.937963170@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
Tom, is this still an open item?
That particular coredump seems to be fixed. There might be some other
problems lurking with inherited queries, but this thread can be
written off I think...
I've been chasing Chris Bitmead's coredump report from earlier today.
I find that it can be reproduced very easily. For example:
regression=> select f1 from int4_tbl group by f1;
< no problem >
regression=> select f1 from int4_tbl* group by f1;
< core dump >(You may get unstable behavior rather than a reliable core dump
if you are not configured --enable-cassert.)
regards, tom lane
From bouncefilter Tue Sep 21 21:29:45 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA43131;
Tue, 21 Sep 1999 21:28:59 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA24760;
Tue, 21 Sep 1999 21:27:35 -0400 (EDT)
To: wieck@debis.com (Jan Wieck)
cc: maillist@candle.pha.pa.us (Bruce Momjian),
pgsql-hackers@thewrittenword.com, pgsql-hackers@postgreSQL.org,
pgsql-admin@postgreSQL.org
Subject: Re: [HACKERS] Problems with src/pl/tcl/mkMakefile.tcldefs.sh.in in
6.5
In-reply-to: Your message of Wed, 22 Sep 1999 00:55:35 +0200 (MET DST)
<m11TYox-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Tue, 21 Sep 1999 21:27:34 -0400
Message-ID: <24758.937963654@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
wieck@debis.com (Jan Wieck) writes:
Bruce Momjian wrote:
I believe this is fixed.
Again one of the frequently appearing items. So I would call
it more "hacked quiet - for now" instead of "fixed".
No, it's really fixed, or anyway Albert's complaint is fixed
(there was at least one other related complaint recently, too).
The problem was not whether we could find tclConfig.sh, it was
whether we were coping correctly with shell metacharacters in
the variable values. We were not, but I fixed that with a redesign
of the way the script read the file...
regards, tom lane
From bouncefilter Tue Sep 21 21:35:41 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA44498
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 21:35:07 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA24798;
Tue, 21 Sep 1999 21:34:35 -0400 (EDT)
To: Bernard Frankpitt <frankpit@pop.dn.net>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Early evaluation of constant expresions (with PATCH)
In-reply-to: Your message of Tue, 21 Sep 1999 20:18:00 +0000
<37E7E7F8.55FE1A8B@pop.dn.net>
Date: Tue, 21 Sep 1999 21:34:35 -0400
Message-ID: <24796.937964075@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bernard Frankpitt <frankpit@pop.dn.net> writes:
The solution that I propose is to include code in the optimizer that
picks functions with constant arguments out of a qualification
clause, and evaluates them.
This is something I had on my own to-do list, and I'm glad to see
someone beat me to it. But you've only done half the job: you
should also be folding operators with constant arguments.
Also, you need to be wary of functions like now() and random().
There probably isn't any other way to handle these than to add a
column to pg_proc flagging functions that can't be constant-folded.
Finally, there is the question of where in the planner should the
early evaluation occur. It is not obvious to me where the best point
is, I chose to put it in
plan/initsplan.c:add_restrict_and_join_to_rels().
I believe it would be best to do it considerably earlier, specifically,
before cnfify(). It might even be worth running the code twice,
once before and once after cnfify.
Also, probably we should apply it to the targetlist as well as the qual.
regards, tom lane
From bouncefilter Tue Sep 21 22:33:33 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA53281
for <pgsql-hackers@postgreSQL.org>;
Tue, 21 Sep 1999 22:32:39 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id WAA23935;
Tue, 21 Sep 1999 22:17:29 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909220217.WAA23935@candle.pha.pa.us>
Subject: Re: [HACKERS] Early evaluation of constant expresions (with PATCH)
In-Reply-To: <24796.937964075@sss.pgh.pa.us> from Tom Lane at "Sep 21,
1999 09:34:35 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 21 Sep 1999 22:17:29 -0400 (EDT)
CC: Bernard Frankpitt <frankpit@pop.dn.net>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bernard Frankpitt <frankpit@pop.dn.net> writes:
The solution that I propose is to include code in the optimizer that
picks functions with constant arguments out of a qualification
clause, and evaluates them.This is something I had on my own to-do list, and I'm glad to see
someone beat me to it. But you've only done half the job: you
should also be folding operators with constant arguments.Also, you need to be wary of functions like now() and random().
There probably isn't any other way to handle these than to add a
column to pg_proc flagging functions that can't be constant-folded.
Already there, pg_proc.proiscachable.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Wed Sep 22 00:49:28 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA79220
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 00:49:12 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id NAA07911;
Wed, 22 Sep 1999 13:49:10 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id NAA26668;
Wed, 22 Sep 1999 13:49:10 +0900 (JST)
Message-Id: <199909220449.NAA26668@srapc451.sra.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster disappears
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Tue, 21 Sep 1999 21:07:43 -0400.
<24664.937962463@sss.pgh.pa.us>
Date: Wed, 22 Sep 1999 13:49:09 +0900
Sender: t-ishii@srapc451.sra.co.jp
Not sure. reaper() may be called while reaper() is executing if a new
SIGCHLD is raised. How do you handle this case?No, because the signal is disabled when the trap is taken, and then not
re-enabled until reaper() does pqsignal() just before exiting. We don't
You are correct. I had wrong impression about signal handling.
Moreover, you're not actually checking what the select() did unless
you do it that way.Sorry, I don't understand this. Can you explain, please?
If you don't have the signal routine save/restore errno, then (when this
problem occurs) you are not seeing the errno returned by the select(),
but one left over from reaper()'s activity. If the select() failed, you
won't know it.
Oh, I see your point.
Curious that this sort of problem is not seen more often --- I wonder
if most Unixes arrange to save/restore errno around a signal handler
for you?Maybe because the situation I have pointed out is relatively rare.
Well, the window for trouble is awfully tiny in this particular code of
ours, but it might be larger in other programs.
Though it seems rare, we certainly have had this kind of reports from
users for a while. Since disappearing postmaster is a really bad
thing, I love to see solutions for this.
Yet I don't think I've
ever heard a programming recommendation to save/restore errno in signal
handlers...
Agreed. I don't like this way.
I asked a Unix guru, and got a suggestion that we do not need to call
wait() (and CleanupProc()) inside the signal handler. Instead we could
have a null signal hander (it just calls pqsignal()) for SIGCHLD. If
select() returns EINTR then we just call wait() and
CleanupProc(). Moreover this would eliminate sigprocmask() or
sigblock() calls currently done to avoid race conditions before going
into the critical region. Of course we have to call wait() and
CleanupProc() before select() to make sure that we have no waiting
children.
Another way would be blocking SIGCHILD before calling select(). In
this case appropriate time out setting for select() is necessary,
though.
--
Tatsuo Ishii
From bouncefilter Wed Sep 22 01:48:28 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA86797
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 01:47:45 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id CAA95210;
Wed, 22 Sep 1999 02:46:47 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 22 Sep 1999 02:46:46 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Adriaan Joubert <a.joubert@albourne.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
In-Reply-To: <199909212100.RAA17419@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909220246160.38923-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 21 Sep 1999, Bruce Momjian wrote:
Can I get comments on this? Is a bit type something we want installed
by default, or in contrib? Seems to me it should be in the main tree.
first...what is a bitmask type? :)
Hi,
here is a new version of the bitmask type. It supports hash-indices as
well now, and fixes a bug in the definition of the <> operator.I would appreciate it if somebody more knowledgable than myself would
look over the index definitions. They seem to work and are used by
postgres, so I guess they can't be all wrong. The hashing function is
the same as that for char's and comes straight out of the postgres
source code.BTW, chapter 36 of the documentation could do with some additions, but I
don't feel knowledgable enough to attempt it. E.g. it shows how to put
an entry for the hashing into pg_amop, but never explains how to define
the entry in pg_amproc and doesn't tell you that you need to define a
separate hashing function. It took me a while of looking through the
other definitions and digging through the source code to come up with a
best guess.Perhaps this could go into the contrib area if it passes muster, as it
is an example of a user-defined type with indices.Cheers,
Adriaan
[application/x-gzip is not supported, skipping...]
-- Bruce Momjian | http://www.op.net/~candle maillist@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 19026************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Sep 22 02:21:35 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA91368
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 02:20:53 -0400 (EDT)
(envelope-from a.joubert@albourne.com)
Received: from isadora.cy.albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.6X) with ESMTP
id JAA15901; Wed, 22 Sep 1999 09:23:23 +0300 (EET DST)
Received: from albourne.com (localhost [127.0.0.1])
by isadora.cy.albourne.com (8.9.3/8.9.3/Albourne/CYC/1.4) with ESMTP id
JAA29769; Wed, 22 Sep 1999 09:20:50 +0300 (EET DST)
Sender: a.joubert@albourne.com
Message-ID: <37E87542.2F8ADA4A@albourne.com>
Date: Wed, 22 Sep 1999 09:20:50 +0300
From: Adriaan Joubert <a.joubert@albourne.com>
Organization: APL Financial Services (Overseas) Ltd
X-Mailer: Mozilla 4.61 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <Pine.BSF.4.10.9909220246160.38923-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
On Tue, 21 Sep 1999, Bruce Momjian wrote:
Can I get comments on this? Is a bit type something we want installed
by default, or in contrib? Seems to me it should be in the main tree.first...what is a bitmask type? :)
In this case just a single byte in which you can store states quite
easily. It supports the C-style bit operations & (and) ,| (or, couldn't
get it defined as a single bar though, because the parser didn't like
it) ,^ (xor),! (not). For some applications it is just easier to check
whether certain bits are set/not set.
If somebody tells me what needs doing, I could try to get it all into a
more usable format. And I have no clue what SQL3 says about bit-types
(varying bits or something or other?) At the moment it is just a single
byte, and perhaps it needs extension to 2 byte, 4-byte types.
Adriaan
From bouncefilter Wed Sep 22 03:26:33 1999
Received: from bajor.mug.org (wormhole.mug.org [207.158.132.1])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA04432
for <pgsql-hackers@postgresql.org>;
Wed, 22 Sep 1999 03:26:06 -0400 (EDT)
(envelope-from bga@bajor.mug.org)
Received: from bajor.mug.org (localhost [127.0.0.1]) by bajor.mug.org
(8.8.7/UW7.0.1) with ESMTP id DAA21884;
Wed, 22 Sep 1999 03:29:49 -0400 (EDT)
Message-Id: <199909220729.DAA21884@bajor.mug.org>
X-Mailer: exmh version 2.0.2 2/24/98
From: "Billy G. Allie" <Bill.Allie@mug.org>
Reply-To: "Billy G. Allie" <Bill.Allie@mug.org>
To: wieck@debis.com (Jan Wieck)
Cc: tgl@sss.pgh.pa.us (Tom Lane), maillist@candle.pha.pa.us,
pgsql-hackers@postgresql.org, bga@mug.org
Subject: Re: [HACKERS] Status on Jan Wieck
In-Reply-To: Your message of "Tue, 21 Sep 1999 10:41:05 +0200."
<m11TLU1-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-651971908P";
micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Wed, 22 Sep 1999 03:29:48 -0400
Sender: bga@mug.org
--==_Exmh_-651971908P
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jan Wieck wrote:
Bruce Momjian <maillist@candle.pha.pa.us> writes:
I know people were wondering about Jan, so I just talked to him via
e-mail, and he has been busy on a big project.Good ... I was starting to fear he'd been run over by a truck or
something :-(Does he have any idea when/if he'll return to Postgres hacking?
As soon as I see the light at the end of the tunnel (and am
sure that it's not the coming train). I think it will take
another two or three weeks.
Didn't you hear Jan? Due to budget constraints, the light at the end of the tunnel has been turned off :-)
--
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/ |LLIE | (313) 582-1540 |
--==_Exmh_-651971908P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: 6+qmH4AsyW9Ww+rdN79O3cVUVR1Wp7Cr
iQA/AwUBN+iFbKFebSRz8o+3EQKlawCfS+8kYMV1IBxItnTGu+Y5XTVoaoEAn0W+
TxPgoxcpiwr26GFfJJETZTJW
=KKqA
-----END PGP SIGNATURE-----
--==_Exmh_-651971908P--
From bouncefilter Wed Sep 22 06:05:37 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id GAA27677
for pgsql-hackers@postgresql.org; Wed, 22 Sep 1999 06:05:32 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
Message-ID: <37E8A1BE.DA1E8627@crn.pl>
From: Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?= <grzegorz_przezdziecki@crn.pl>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
X-Newsgroups: comp.databases.postgresql.hackers
Subject: Problem with new function
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
Date: Wed, 22 Sep 1999 09:36:45 GMT
X-Complaints-To: abuse@tpsa.pl
X-Trace: news.tpnet.pl 937993005 195.116.206.135 (Wed,
22 Sep 1999 11:36:45 MET DST)
Organization: TPNET - http://www.tpnet.pl
Lines: 22
To: pgsql-hackers@postgresql.org
I tray create new function bye read from file.
When I read this file I have errors
pgReadData()- backend closed the channel unexpectedly
in may log file :
Fatal 1 : btree: cannot split if start (2) >= maxoff (2)
or somethings like this:
fatal 1: my bits moved right off the end of the world!
PostgreSQL 6.5.1 on i686-pc-linux-gnu, compiled by gcc 2.7.2.31
on Debian Slink
Need help
Best regards
From bouncefilter Wed Sep 22 06:10:31 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA28059
for <pgsql-hackers@postgresql.org>;
Wed, 22 Sep 1999 06:10:01 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id TAA12801; Wed, 22 Sep 1999 19:08:28 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] couldn't rollback cache ?
Date: Wed, 22 Sep 1999 19:12:00 +0900
Message-ID: <000f01bf04e2$e9112c40$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <21707.937925031@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I think this is OK. The sending backend does not send the SI message
in the first place until it has committed. Other backends can readDoesn't the sending backend send the SI message when Command-
CounterIncrement() is executed ?
AtCommit_Cache() is called not only from CommitTransaction() but
also from CommandCounterIncrement().Oooh, you are right. I think that is a bug. We should postpone
sending SI messages until commit. Also, if I recall correctly,
CommandCounterIncrement() still gets called after we have decided to
abort the current transaction (while we are eating commands looking for
END or ABORT). It shouldn't do anything to the pending-SI list then
either.AtCommit_Cache() in CommandCounterIncrement() eats local
invalidation messages and register SI information (this seems too
early for other backends though it's not so harmful). Then AtAtart_
Cache() eats the SI information and invalidates related syscache
and relcache for the backend(this seems right). At this point,invali-
dation info for the backend vanishes. Isn't it right ?I think it is OK for AtStart_Cache to read *incoming* SI messages,
if those relate to transactions that other backends have committed.
But we should sit on our own list of pending outgoing messages until
we know we are committing (or aborting).
What about delet(updat)ing backend itself ?
Shouldn't the backend invalidate delet(updat)ing old tuples ?
I wonder whether it wouldn't be cleaner to identify the target tuples
by OID instead of ItemPointer. That way would work for both new and
update tuples...
[snip]
One thing we need to think about here: as it stands, the syscache will
only store a single copy of any particular tuple (maybe I should say
"of a particular OID"). But there might be several copies of that tuple
with different t_min/t_max in the database. With your change to check
time qual, as soon as we realize that the copy we have no longer
SatisfiesNow(), we'll go look for a new copy. And we'll go look
for a new copy after receiving a SI message indicating someone else has
committed an update. The question is, are there any *other* times where
we need to look for a new copy? I think we are OK if we change SI
message sending to only send after commit, but I'm not sure about it.
What kind of tuples are read into system catalog cache ?
And what should we do to invalidate the tuples just in time ?
As far as I see,
1. HEAP_XMIN_INVALID
i.e the tuple wasn't inserted
No backend regards this tuple as valid.
2. HEAP_XMIN_??????? && HEAP_XMAX_INVALID
i.e the tuple is being inserted now.
Only inserting backend regards this tuple as valid.
Time qualification check which my patch does would
work in this case.
Otherwise SI message should be sent to the backend
when insertion is rollbacked.
3. HEAP_XMIN_??????? && HEAP_XMAX_???????
i.e the tuple is being deleted after insertion in a transaction
now.
No backend regards this tuple as valid.
4. HEAP_XMIN_COMMITTED && HEAP_XMAX_INVALID
i.e the tuple is inserted,not deleted and not being deleted.
HeapTupleSatisifies..() doesn't take effect.
SI message should be sent to all backends immediately
after the tuple was deleted.
SI message should be sent to a backend immediately after
the backend marked the tuple as being deleted.
5. HEAP_XMIN_COMMITTED && HEAP_XMAX_???????
i.e the tuple is being deleted now.
Deleting backend doesn't regard this tuple as valid.
If SI messages are postponed to send for other backends
until commit,the tuple is invalidated correctly.
Otherwise a check as my patch does would be necessary.
6. HEAP_XMAX_COMMITTED
i.e the tuple is deleted
SnapshotNow never regard this tuple as valid.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Sep 22 09:38:39 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA59789
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 09:38:33 -0400 (EDT)
(envelope-from a.joubert@albourne.com)
Received: from isadora.cy.albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.6X) with ESMTP
id QAA16390 for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 16:41:04 +0300 (EET DST)
Received: from albourne.com (localhost [127.0.0.1])
by isadora.cy.albourne.com (8.9.3/8.9.3/Albourne/CYC/1.4) with ESMTP id
QAA30071 for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 16:38:31 +0300 (EET DST)
Sender: a.joubert@albourne.com
Message-ID: <37E8DBD7.4E79A61E@albourne.com>
Date: Wed, 22 Sep 1999 16:38:31 +0300
From: Adriaan Joubert <a.joubert@albourne.com>
Organization: APL Financial Services (Overseas) Ltd
X-Mailer: Mozilla 4.61 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Operator definitions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've got a big problem: I had an operator defined as follows:
CREATE OPERATOR ^ (
leftarg = bit1,
rightarg = bit1,
procedure = bit1xor
);
and this was fine until 6.5.1, but in 6.5.2 I get
ERROR: parser: parse error at or near "^"
I've got the same problem with
CREATE OPERATOR | (
leftarg = bit1,
rightarg = bit1,
procedure = bit1or,
commutator = |
);
but at least that didn't work under 6.5.1 either. Can anybody give me a
hint how to fix this? I know nothing about the parser, or lex or yacc so
I don't even know where to start. I need to fix this rather urgently ,
as I have tons of plpgsql functions that make use of the ^ operator. At
the moment I get a power for all of these which leads to pretty
disastrous consequences :-(.
If anybody can give me any hint at all, I'll have a go at fixing it.
Much appreciated!
Adriaan
From bouncefilter Wed Sep 22 10:27:37 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA68170
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 10:26:46 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA29797;
Wed, 22 Sep 1999 10:26:13 -0400 (EDT)
To: frankpit@pop.dn.net
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Early evaluation of constant expresions (with PATCH)
In-reply-to: Your message of Tue, 21 Sep 1999 19:06:53 -0400
<37E80F8D.2E6D6736@pop.dn.net>
Date: Wed, 22 Sep 1999 10:26:13 -0400
Message-ID: <29795.938010373@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
frankpit@pop.dn.net writes:
Tom Lane wrote:
This is something I had on my own to-do list, and I'm glad to see
someone beat me to it. But you've only done half the job: you
should also be folding operators with constant arguments.
I actually do the operators as well, and also boolean operators (which
are handled by special Expr nodes).
(Hangs head...) Yup. That's what I get for opining after a fast
late-night scan of a patch. Relying on ExecEvalExpr is a good hack ---
the patch is much smaller than I would've guessed. (Actually, now
that I look at it, it looks like the functions rather than the
operators are missing the necessary preinitialization. Perhaps at
the place where you chose to put this in, setFcache has already
been done?)
There are additional smarts that could/should be put in, though.
In particular, I think we should be smarter about AND and OR clauses.
If *any* of the inputs to an AND are a constant FALSE, you can collapse
the node and not bother computing the other subexpressions; likewise
a constant TRUE input to an OR allows short-circuiting. (I have seen
queries, primarily machine-generated ones, where this would be an
enormous win.) Contrariwise, constant TRUE/FALSE inputs can simply be
dropped, and the AND or OR operator eliminated if only one nonconstant
input remains. This is the reason why I think there is an interaction
with cnfify(): it rearranges the AND/OR structure of the tree and might
expose --- or hide --- opportunities of this kind. (BTW, it might be a
good idea to do the first pass of cnfify, namely AND/OR flattening,
before trying to apply this simplification.)
Also, most operators and functions can be collapsed to NULL if any of
their inputs are NULL, although I don't think we can risk making that
optimization without adding a flag to pg_proc that tells us if it is OK.
Also, you need to be wary of functions like now() and random().
There probably isn't any other way to handle these than to add a
column to pg_proc flagging functions that can't be constant-folded.
I puzzled over case of now() for a while but I don't think that it
raises a problem.
No, you can't just define the problem away by saying that whatever
behavior is convenient to implement is acceptable. It's true that
now() is not really a problem, because it's defined to yield the
start time of the current transaction, and therefore is effectively
a constant *within any one transaction*. But random() *is* a problem,
and user-defined functions could be a problem. SQL functions probably
shouldn't be folded either (not quite sure of that).
Bruce points out in another reply that the proiscachable field of
pg_proc is intended for exactly this purpose. It hasn't been kept
up carefully because no extant code uses it, and in fact hardly any
of the standard entries in pg_proc are marked iscachable, which is
obviously silly. But we could certainly go through pg_proc and set
the flag on everything except the danger items.
Another factor about positioning of the filter that I was uncertain
about was time expense. Is the time taken by multiple tree walks in
the planner very significant in the overall scheme of things?
I don't think you need to worry about anything that has cost linear in
the size of the expression tree. Up till a couple weeks ago we had some
code in cnfify() that used space and time exponential in the size of the
tree :-( ... now it's down to O(N^2) which is still a bottleneck for
complex query expressions, but O(N) is not to be worried about. Like
I said, I wouldn't object to running this code twice on a qual.
There are some upstream places where it would be nice too --- for
example, coercion of DEFAULT expressions would be best handled by
sticking a type-conversion function atop the given parsetree and then
seeing if this code would simplify it. We'll definitely need to make
use of proiscachable to make that safe, however.
regards, tom lane
From bouncefilter Wed Sep 22 10:39:38 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA69750
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 10:38:54 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA29879;
Wed, 22 Sep 1999 10:38:20 -0400 (EDT)
To: t-ishii@sra.co.jp
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster disappears
In-reply-to: Your message of Wed, 22 Sep 1999 13:49:09 +0900
<199909220449.NAA26668@srapc451.sra.co.jp>
Date: Wed, 22 Sep 1999 10:38:20 -0400
Message-ID: <29875.938011100@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
Yet I don't think I've ever heard a programming recommendation to
save/restore errno in signal handlers...
Agreed. I don't like this way.
Hmm, I don't like your patch and you don't like mine. Time to redesign
rather than patch ;-)
I asked a Unix guru, and got a suggestion that we do not need to call
wait() (and CleanupProc()) inside the signal handler. Instead we could
have a null signal hander (it just calls pqsignal()) for SIGCHLD. If
select() returns EINTR then we just call wait() and
CleanupProc(). Moreover this would eliminate sigprocmask() or
sigblock() calls currently done to avoid race conditions before going
into the critical region. Of course we have to call wait() and
CleanupProc() before select() to make sure that we have no waiting
children.
This looks like it could be a really clean solution. In fact, there'd
be no need to check for EINTR from select(); we could just fall through,
knowing that the reaping will be done as soon as we loop around to the
top of the loop. The code becomes just
for (;;) {
reap;
select;
handle any input found by select;
}
Do we even need a signal handler at all for ECHILD? I suppose the
select might not get interrupted (at least on some platforms) if there
isn't one.
Actually I guess there still is a race condition: there is a window
between the last wait() of the reap loop and the select() wherein an
ECHILD won't be serviced right away, because we hit the select() before
noticing it. We could maybe use a timeout on the select to fix that.
Don't really like it though, since the timeout couldn't be very long,
but we don't want the postmaster wasting cycles when there's nothing
to do. Is there another way around this?
regards, tom lane
From bouncefilter Wed Sep 22 11:00:44 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA72926
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 11:00:27 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA00126;
Wed, 22 Sep 1999 10:59:14 -0400 (EDT)
To: InfraRED <infrared@a-b.hu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [GENERAL] when are indexes used?
In-reply-to: Your message of Tue, 21 Sep 1999 18:18:22 +0200 (CEST)
<37E500CA.3FF5DB37@a-b.hu>
Date: Wed, 22 Sep 1999 10:59:14 -0400
Message-ID: <123.938012354@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
InfraRED <infrared@a-b.hu> writes:
I noticed that indexes are not used sometimes when they could speed up
queries:
explain select * from auth where uid=30;
Index Scan using auth_uid_key on auth (cost=2.05 rows=1 width=40)
explain select * from auth where uid<30;
Seq Scan on auth (cost=2.06 rows=11 width=40)
explain select * from auth order by uid;
Sort (cost=2.06 rows=32 width=40)
-> Seq Scan on auth (cost=2.06 rows=32 width=40)
With only 32 rows in the table, I suspect the machine is making the
right choices here. (If you actually have more than 32 rows then you
need to vacuum to update the stats...) Index scans are not some sort of
free magic solution; they cost a lot more per row scanned than
sequential scans. They aren't necessarily cheaper than a sequential
scan plus in-memory sort, either.
The system uses an index scan when it's possible and apparently cheaper
than a sequential scan. There are some problems with its estimation
of the relative costs, which I'm hoping to fix for 6.6. However, the
problems seem to be that it's *under* estimating the cost of indexscans,
not overestimating them.
persistent views: like select into, but the view gets updated every time
the table(s) it was created from change. (gives no further functionality
over views, but when used wisely, can speed up things)
Think you can do this already with rules and/or triggers. It takes some
thought though. Maybe some documentation with a worked-out example
would be a good idea.
inmemory tables: table data should not be saved to disk (maybe except
for swapping), because contains rapidly changing data, which would
expire before restarting the backend
You can get pretty close to this already with fsync off: if you're
touching the table constantly then all its pages will remain in buffer
cache. A typical Unix system won't bother to write out modified
pages oftener than once every 30 sec, which is hardly worth worrying
about.
regards, tom lane
From bouncefilter Wed Sep 22 11:20:38 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA76050
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 11:20:14 -0400 (EDT)
(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 PAA17562;
Wed, 22 Sep 1999 15:19:22 GMT
Sender: lockhart@hub.org
Message-ID: <37E8F37A.69D915A1@alumni.caltech.edu>
Date: Wed, 22 Sep 1999 15:19:22 +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: frankpit@pop.dn.net
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Early evaluation of constant expresions (with PATCH)
References: <24796.937964075@sss.pgh.pa.us> <37E80F8D.2E6D6736@pop.dn.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
You da man Bernard! I've been wanting to do this for a while also, but
hadn't taken the time to puzzle through it.
In fact istm that the correct way to handle now() would be to have a
value that is constant over a transation, and comensurate with the
numbering of tids.
That is the current behavior of now(); Postgres has a time function
which returns the time of the current transaction and now() (and every
other form of date/time 'now') uses that.
When doing this pre-evaluation in the parse tree, is it possible that
the transaction time is not yet set? So perhaps 'now' and now() would
have problems here. Remember that "datetime 'now'" also resembles a
constant but has the same behavior as "now()", so can't really be
considered a true constant either.
I don't think that random() is a problem at all. It gets called once
each time it is written in the query string. That is certainly a
reasonable interpretation of its meaning.
If we use the "is cachable" flag for procedures (*and* for constants
on types!) then it would be possible to have random() behave as
expected- returning unique values for every invocation and unique
values into each field of a single-line query/insert.
I hope we haven't put you off here, and I'd suggest that we
incorporate your patches as they stand now, then work on the next step
later (assuming that it isn't something you have time or interest
for). But if you can see doing this next step already, we'd love to
have it included in the first patch. What do you think?
Thanks for the work. This is a neat area to get improvements for...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Sep 22 11:33:44 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA78347
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 11:33:27 -0400 (EDT)
(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 PAA17574;
Wed, 22 Sep 1999 15:32:02 GMT
Sender: lockhart@hub.org
Message-ID: <37E8F672.9B98E9BF@alumni.caltech.edu>
Date: Wed, 22 Sep 1999 15:32:02 +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: Adriaan Joubert <a.joubert@albourne.com>
CC: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <Pine.BSF.4.10.9909220246160.38923-100000@thelab.hub.org>
<37E87542.2F8ADA4A@albourne.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Can I get comments on this? Is a bit type something we want installed
by default, or in contrib? Seems to me it should be in the main tree.In this case just a single byte in which you can store states quite
easily. It supports the C-style bit operations & (and) ,| (or, couldn't
get it defined as a single bar though, because the parser didn't like
it) ,^ (xor),! (not). For some applications it is just easier to check
whether certain bits are set/not set.
As long as it is limited to a single byte, perhaps it should prove
itself in contrib. However, SQL92 has bit types, and it would be nice
to get full support for them (and beyond, as this already is doing :)
If somebody tells me what needs doing, I could try to get it all into a
more usable format. And I have no clue what SQL3 says about bit-types
(varying bits or something or other?) At the moment it is just a single
byte, and perhaps it needs extension to 2 byte, 4-byte types.
I don't have time right now to type up a short summary, but can do
that later if you like. But the data entry for an SQL92 bit type looks
like
B'10111'
X'17'
The underlying data type is BIT(n), a fixed-length type where n is the
exact number of bits. BIT VARYING (n) allows a variable number of bits
(duh!) up to n bits. We can support these SQL92 constructs in the
parser, folding them into an internal type as we do for character
strings currently.
It could be implemented just like the character types, having a header
on the internal representation which holds the length. It can't re-use
the character type support functions as-is, since they currently
consider a zero byte in the string as end-of-string.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Sep 22 11:11:38 1999
Received: from postal.dn.net (postal.dn.net [207.226.170.20])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA74443
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 11:11:28 -0400 (EDT)
(envelope-from frankpit@pop.dn.net)
Received: from pop.dn.net (pm-58.ppp.wdc.dn.net [207.226.188.58])
by postal.dn.net (8.9.3/postal) with ESMTP id LAA16536;
Wed, 22 Sep 1999 11:10:55 -0400 (EDT)
Sender: matuser@postal.dn.net
Message-ID: <37E8F708.B55D6A21@pop.dn.net>
Date: Wed, 22 Sep 1999 15:34:32 +0000
From: Bernard Frankpitt <frankpit@pop.dn.net>
Organization: AIMS
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.32 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Early evaluation of constant expresions (with PATCH)
References: <29795.938010373@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
.... (Actually, now
that I look at it, it looks like the functions rather than the
operators are missing the necessary preinitialization. Perhaps at
the place where you chose to put this in, setFcache has already
been done?)
The functions work because the funcid field in the Func node is already
filled in, and the EvalQual code uses this field to generate the Fcache.
In the case of Oper node there are two fields, one for the pg_operator
Oid,
and one for the pg_proc Oid. The pg_operator oid is already filled in,
but the pg_proc oid isn't. The EvalQual code wants the pg_proc oid, so
I provide it in the patch before I do the evaluation.
There are additional smarts that could/should be put in, though. ....
{ Many good suggestions here }
.... without adding a flag to pg_proc that tells us if it is OK.
All points well taken. I don't have time to do this thoroughly right
now,
but I will get back to it. My original ( needed-for-project-at-hand )
motivation for this was to get index scans to work with expressions that
evaluate to constants. I can see that I am about to learn quite a bit
more about parsing and planning.
I puzzled over case of now() for a while but I don't think that it
raises a problem.No, you can't just define the problem away by saying that whatever
behavior is convenient to implement is acceptable.
Oh darn! -- I've spent too many years studying mathematics
and user-defined functions could be a problem. SQL functions probably
shouldn't be folded either (not quite sure of that).Bruce points out in another reply that the proiscachable field of
pg_proc is intended for exactly this purpose.
Perhaps adding another option to create function is in order here. I
know how to do that already. Seriously, there are some interesting
semantic issues here, especially if the database were being used as the
basis for a large dynamic stochastic model.
Bernie
From bouncefilter Wed Sep 22 11:36:38 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA79049
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 11:36:12 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA00357;
Wed, 22 Sep 1999 11:35:34 -0400 (EDT)
To: Bernard Frankpitt <frankpit@pop.dn.net>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Early evaluation of constant expresions (with PATCH)
In-reply-to: Your message of Wed, 22 Sep 1999 15:34:32 +0000
<37E8F708.B55D6A21@pop.dn.net>
Date: Wed, 22 Sep 1999 11:35:34 -0400
Message-ID: <355.938014534@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bernard Frankpitt <frankpit@pop.dn.net> writes:
.... (Actually, now
that I look at it, it looks like the functions rather than the
operators are missing the necessary preinitialization. Perhaps at
the place where you chose to put this in, setFcache has already
been done?)
The functions work because the funcid field in the Func node is already
filled in, and the EvalQual code uses this field to generate the
Fcache.
Oh, OK. Cool. For some reason I was thinking that the planner
was supposed to generate the fcache entry somewhere along the line.
All points well taken. I don't have time to do this thoroughly right
now, but I will get back to it.
OK, or I will work on it if I get to it before you do. As Thomas
remarked, you've provided a great starting point --- thanks!
I know I already have one patch from you that I promised to integrate,
but I'm up to my ass in buffer refcount bugs :-(. As soon as I can come
up for air, I will stick in this code, though I think I will call it
from somewhere near cnfify per prior discussion.
Bruce points out in another reply that the proiscachable field of
pg_proc is intended for exactly this purpose.
Perhaps adding another option to create function is in order here.
Actually, create function *has* an iscachable option which sets that
field. According to glimpse, it's the only code in the system that
knows the field exists :-(
regards, tom lane
From bouncefilter Wed Sep 22 11:50:41 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA82096
for <docs@postgreSQL.org>; Wed, 22 Sep 1999 11:49:40 -0400 (EDT)
(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 PAA17607;
Wed, 22 Sep 1999 15:48:29 GMT
Sender: lockhart@hub.org
Message-ID: <37E8FA4D.C0A1606F@alumni.caltech.edu>
Date: Wed, 22 Sep 1999 15:48:29 +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: Peter Eisentraut <peter_e@gmx.net>
CC: Bruce Momjian <maillist@candle.pha.pa.us>,
Vince Vielhaber <vev@michvhf.com>, The Hermit Hacker <scrappy@hub.org>,
docs@postgreSQL.org
Subject: Re: [DOCS] INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)
References: <Pine.LNX.4.10.9909212031480.1899-200000@peter-e.yi.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I agree our INSTALL is very large. Is there some way we can simplify
the install process?On the one hand a database server is probably not your everyday
./configure && make && make install program you get from freshmeat and you
do want to put some time into a proper installation. On the other hand the
INSTALL file is really way too long and makes for unpleasant reading.
Here are a couple of ideas.
That should make the file somewhat smaller, then also it is really to
verbose at times and is formatted really oddly, at least on my system.
Formatted oddly, eh? ;)
We actually generate this file from files in doc/src/sgml/. We
generate RTF from the sgml sources, and then format to ascii text
using ApplixWare or <insert your favorite word processor here>. The
formatting options at that point are fairly limited afaik.
Okay, now I really went out of my way and redid the whole thing. You'll
find the result attached. This is merely an idea of what I would consider
simpler. I removed some inconsistencies, things that were unnecessary, too
complicated, etc. Okay, I removed a lot of stuff, but most of the stuff
people can really figure out themselves if they need them in the first
place. And I shrunk the thing to 25%.
Sounds great, except for the "people can figure it out for themselves"
part. But as long as the info is available somewhere in the docs, and
as long as people can get to them somehow if they need, then there is
probably no need for them to be in the INSTALL file.
Perhaps there should be a separate Install FAQ of the sort "My shell said
'export: Command not found.'" or "What's a shared library?" to move the
really annoying stuff out of people's ways.
And afaik once people have gotten to that point, the *real* docs will
have already been installed, so we can have that info there. I haven't
had a chance to look at your specific suggestions/changes, but I'm
sure they are a step forward.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Sep 22 12:33:39 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA91727
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 12:32:53 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA07804;
Wed, 22 Sep 1999 12:20:56 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909221620.MAA07804@candle.pha.pa.us>
Subject: Re: [HACKERS] Operator definitions
In-Reply-To: <37E8DBD7.4E79A61E@albourne.com> from Adriaan Joubert at "Sep 22,
1999 04:38:31 pm"
To: Adriaan Joubert <a.joubert@albourne.com>
Date: Wed, 22 Sep 1999 12:20:56 -0400 (EDT)
CC: Postgresql <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I've got a big problem: I had an operator defined as follows:
CREATE OPERATOR ^ (
leftarg = bit1,
rightarg = bit1,
procedure = bit1xor
);and this was fine until 6.5.1, but in 6.5.2 I get
ERROR: parser: parse error at or near "^"
I've got the same problem with
CREATE OPERATOR | (
leftarg = bit1,
rightarg = bit1,
procedure = bit1or,
commutator = |
);but at least that didn't work under 6.5.1 either. Can anybody give me a
hint how to fix this? I know nothing about the parser, or lex or yacc so
I don't even know where to start. I need to fix this rather urgently ,
as I have tons of plpgsql functions that make use of the ^ operator. At
the moment I get a power for all of these which leads to pretty
disastrous consequences :-(.If anybody can give me any hint at all, I'll have a go at fixing it.
Much appreciated!
We do special things for ^ and | so it has proper precedence for
select 2 ^ 1*2
select 'asdf' | 'asdf' | 'asdf'
However, there were no changes I know of in 6.5.2 that would cause it to
break.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Wed Sep 22 12:41:39 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA93314
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 12:41:29 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA08003;
Wed, 22 Sep 1999 12:39:14 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909221639.MAA08003@candle.pha.pa.us>
Subject: Re: [HACKERS] postmaster disappears
In-Reply-To: <29875.938011100@sss.pgh.pa.us> from Tom Lane at "Sep 22,
1999 10:38:20 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 22 Sep 1999 12:39:14 -0400 (EDT)
CC: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Do we even need a signal handler at all for ECHILD? I suppose the
select might not get interrupted (at least on some platforms) if there
isn't one.Actually I guess there still is a race condition: there is a window
between the last wait() of the reap loop and the select() wherein an
ECHILD won't be serviced right away, because we hit the select() before
noticing it. We could maybe use a timeout on the select to fix that.
Don't really like it though, since the timeout couldn't be very long,
but we don't want the postmaster wasting cycles when there's nothing
to do. Is there another way around this?
Here is code I use for reaping dead child processes. Under SysV, if you
say you want to ignore child processes, they just disappear, but on BSD,
the children stay as zombies. This fixes that.
Seems you need to define a singnal handler, and just put select() in a
loop:
while (1)
if (select(...) != -1 || errno != EINTR)
break;
I see you are are loosing your error inside the singnal handler. Seems
you may have to save/restore errno.
---------------------------------------------------------------------------
/*
* From: rstevens@noao.edu (W. Richard Stevens)
* Newsgroups: comp.unix.bsd.misc,comp.unix.bsd.bsdi.misc
* Subject: Re: BSD 4.4: Preventing zombies SIGCHLD
* Date: 19 Dec 1995 13:24:39 GMT
*/
void
reapchild(int signo)
{
pid_t pid;
int stat;
while ( (pid = waitpid(-1, &stat, WNOHANG)) > 0) {
/* handle "pid" and "stat" */
}
if (pid < 0)
;/* error */
/* we are done playing the current sound */
cur_sound_id = -1;
/* return value is 0 if no more children */
return;
}
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Wed Sep 22 13:01:42 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA96611
for <docs@postgreSQL.org>; Wed, 22 Sep 1999 13:01:33 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA08069;
Wed, 22 Sep 1999 12:45:49 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909221645.MAA08069@candle.pha.pa.us>
Subject: Re: [DOCS] INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)
In-Reply-To: <37E8FA4D.C0A1606F@alumni.caltech.edu> from Thomas Lockhart at
"Sep 22, 1999 03:48:29 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Wed, 22 Sep 1999 12:45:49 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>, Vince Vielhaber <vev@michvhf.com>,
The Hermit Hacker <scrappy@hub.org>, docs@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I agree our INSTALL is very large. Is there some way we can simplify
the install process?On the one hand a database server is probably not your everyday
./configure && make && make install program you get from freshmeat and you
do want to put some time into a proper installation. On the other hand the
INSTALL file is really way too long and makes for unpleasant reading.
Here are a couple of ideas.
That should make the file somewhat smaller, then also it is really to
verbose at times and is formatted really oddly, at least on my system.Formatted oddly, eh? ;)
We actually generate this file from files in doc/src/sgml/. We
generate RTF from the sgml sources, and then format to ascii text
using ApplixWare or <insert your favorite word processor here>. The
formatting options at that point are fairly limited afaik.
My recommendation is to output HTML, and use lynx to output ASCII. I use:
lynx -force_html -dump -hiddenlinks=ignore -nolist "$@"
You would be surprised how much better it looks, assuming the HTML is
good.
Okay, now I really went out of my way and redid the whole thing. You'll
find the result attached. This is merely an idea of what I would consider
simpler. I removed some inconsistencies, things that were unnecessary, too
complicated, etc. Okay, I removed a lot of stuff, but most of the stuff
people can really figure out themselves if they need them in the first
place. And I shrunk the thing to 25%.Sounds great, except for the "people can figure it out for themselves"
part. But as long as the info is available somewhere in the docs, and
as long as people can get to them somehow if they need, then there is
probably no need for them to be in the INSTALL file.
Our big problem with the ASCII file is that we can't nest text, like we
can in HTML. In HTML, we can say "Do this, and if it doesn't work,
click HERE", and have a page to describe known problems. This allows
us to be brief, but give additional detail. Footnotes in a book have a
similar purpose. Maybe we can implement footnotes in the ASCII file.
That is how I would do it in LyX.
Perhaps there should be a separate Install FAQ of the sort "My shell said
'export: Command not found.'" or "What's a shared library?" to move the
really annoying stuff out of people's ways.And afaik once people have gotten to that point, the *real* docs will
have already been installed, so we can have that info there. I haven't
had a chance to look at your specific suggestions/changes, but I'm
sure they are a step forward.
Interesting idea, but you would have to point them to the exact spot.
That may be tough.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Wed Sep 22 16:27:41 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA36066
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 16:27:38 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id QAA13137
for pgsql-hackers@postgreSQL.org; Wed, 22 Sep 1999 16:16:28 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909222016.QAA13137@candle.pha.pa.us>
Subject: Compile timing
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Wed, 22 Sep 1999 16:16:28 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Someone mentioned that it took them quite a while to compile the
PostgreSQL code. My wallclock time is 3:52 for a compile with -O1 using
gcc 2.7.2.1. This is on a dual-PII 350MHz running BSD/OS 4.01.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Wed Sep 22 16:54:42 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA40941
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 16:54:26 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA02453;
Wed, 22 Sep 1999 17:54:33 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 22 Sep 1999 17:54:32 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
In-Reply-To: <27362.937756381@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9909221754210.66830-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Anyone get a chance to look into this?
On Sun, 19 Sep 1999, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
MySQL: 0.498u 0.150s 0:02.50 25.6% 10+1652k 0+0io 0pf+0w
PgSQL: 0.494u 0.061s 0:19.78 2.7% 10+1532k 0+0io 0pf+0w
From the 'time' numbers, MySQL is running ~17sec faster, but uses up 23%
more CPU to do this...so where is our slowdown?It's gotta be going into I/O, obviously. (I hate profilers that can't
count disk accesses...) My guess is that the index scans are losing
because they wind up touching too many disk pages. You showNOTICE: QUERY PLAN:
Unique (cost=1271.15 rows=5 width=84)
-> Sort (cost=1271.15 rows=5 width=84)
-> Nested Loop (cost=1271.15 rows=5 width=84)
-> Index Scan using aecwebentry_primary on aecwebentry b (cost=1269.08 rows=1 width=60)
-> Index Scan using aecentmain_primary on aecentmain a (cost=2.07 rows=16560 width=24)EXPLAIN
which means this should be a great plan if the optimizer is guessing
right about the selectivity of the index scans: it's estimating only
one tuple returned from the aecwebentry scan, hence only one iteration
of the nested scan over aecentmain, which it is estimating will yield
only five output tuples to be sorted and uniquified.I am betting these estimates are off rather badly :-(. The indexscans
are probably hitting way more pages than the optimizer guessed they will.It may just be that I have optimizer on the brain from having spent too
much time looking at it, but this smells to me like bad-plan-resulting-
from-bad-selectivity-estimation syndrome. Perhaps I can fix it for 6.6
as a part of the optimizer cleanups I am doing. I'd like to get as much
info as I can about the test case.How many tuples *does* your test query produce, anyway? If you
eliminate all the joining WHERE-clauses and just consider the
restriction clauses for each of the tables, how many tuples?
In other words, what do you get fromSELECT count(*)
FROM aecEntMain a
WHERE (a.id=??? AND a.mid=???)
AND (a.status like 'active%')
AND (a.status like '%active:ALL%')
AND (a.representation like '%:ALL%');SELECT count(*)
FROM aecWebEntry b
WHERE (b.status like 'active%')
AND (b.status like '%active:ALL%')
AND (b.indid=? and b.divid=? and b.catid=?);(In the first of these, substitute a representative id/mid pair from
table b for the ???, to simulate what will happen in any one iteration
of the inner scan over table a.) Also, how many rows in each table?regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Sep 22 16:57:42 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA41472
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 16:57:33 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id QAA02200;
Wed, 22 Sep 1999 16:56:20 -0400 (EDT)
To: Adriaan Joubert <a.joubert@albourne.com>
cc: Postgresql <pgsql-hackers@postgreSQL.org>,
Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] Operator definitions
In-reply-to: Your message of Wed, 22 Sep 1999 16:38:31 +0300
<37E8DBD7.4E79A61E@albourne.com>
Date: Wed, 22 Sep 1999 16:56:20 -0400
Message-ID: <2198.938033780@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Adriaan Joubert <a.joubert@albourne.com> writes:
I've got a big problem: I had an operator defined as follows:
CREATE OPERATOR ^ (
leftarg = bit1,
rightarg = bit1,
procedure = bit1xor
);
and this was fine until 6.5.1, but in 6.5.2 I get
ERROR: parser: parse error at or near "^"
It looks to me like '^' and '|' have been left out of the alternatives
for MathOp in src/backend/parser/gram.y. It could be they were
deliberately omitted, but I bet it's just an oversight.
regards, tom lane
From bouncefilter Wed Sep 22 17:09:42 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA47926
for <pgsql-hackers@postgresql.org>;
Wed, 22 Sep 1999 17:09:02 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id RAA15786;
Wed, 22 Sep 1999 17:08:57 -0400
Message-ID: <37E9455F.3FAFA875@wgcr.org>
Date: Wed, 22 Sep 1999 17:08:47 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Compile timing
References: <199909222016.QAA13137@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Someone mentioned that it took them quite a while to compile the
PostgreSQL code. My wallclock time is 3:52 for a compile with -O1 using
gcc 2.7.2.1. This is on a dual-PII 350MHz running BSD/OS 4.01.
Someone is me. Someone only has a Pentium 133 with 256K L2 cache and
32MB RAM. Someone is also running KDE/X on this laptop.
Using egcs 1.1.2 under Linux 2.2.5.(RedHat 6.0).
You have a machine that is 5 times faster than mine. Also, this is more
than a compile -- this is a whole sequence of events -- cleaning out the
old build directory, unpacking the tarball, applying patches,
configure;make;make install, some other sequences of events, and then
cpio'ing and compressing to build several rpm's. So, about two thirds
of the time is actually spent compiling, which is still a little slow
compared to your result.
If my machine compiled PostgreSQL as fast as yours, I'd be one happy
camper!
Lamar Owen
WGCR Internet Radio
From bouncefilter Wed Sep 22 18:30:44 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA59572
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 18:30:31 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA04213;
Wed, 22 Sep 1999 18:29:28 -0400 (EDT)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
In-reply-to: Your message of Wed, 22 Sep 1999 17:54:32 -0300 (ADT)
<Pine.BSF.4.10.9909221754210.66830-100000@thelab.hub.org>
Date: Wed, 22 Sep 1999 18:29:28 -0400
Message-ID: <4211.938039368@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Anyone get a chance to look into this?
Only just now, but I do have a couple of thoughts.
For the query
SELECT distinct b.indid, b.divid, b.catid, a.id, a.mid \
FROM aecEntMain a, aecWebEntry b \
WHERE (a.id=b.id AND a.mid=b.mid) \
AND (a.status like 'active%' and b.status like 'active%')
AND (a.status like '%active:ALL%' and b.status like '%active:ALL%')
AND (a.representation like '%:ALL%')
AND (b.indid=? and b.divid=? and b.catid=?)";
you're showing a plan of
Unique (cost=1271.15 rows=5 width=84)
-> Sort (cost=1271.15 rows=5 width=84)
-> Nested Loop (cost=1271.15 rows=5 width=84)
-> Index Scan using aecwebentry_primary on aecwebentry b (cost=1269.08 rows=1 width=60)
-> Index Scan using aecentmain_primary on aecentmain a (cost=2.07 rows=16560 width=24)
which indicates that the optimizer is guessing only one match in
aecwebentry and is therefore putting it on the outside of the nested
loop (so that the inner scan over aecentmain would only have to be
done once, if it's guessing right). But in a later message you
say that the actual number of hits is more like 39 for aecwebentry
and one for aecentmain. Which means that the nested loop would go
faster if it were done the other way round, aecentmain on the outside.
I'm not sure of a way to force the system to try it that way, though.
The other question is why is it using a nested loop at all, rather
than something more intelligent like merge or hash join. Presumably
the optimizer thinks those would be more expensive, but it might be
wrong.
You could try forcing selection of merge and hash joins for this
query and see (a) what kind of plan do you get, (b) how long does
it really take? To do that, start psql with PGOPTIONS environment
variable set:
PGOPTIONS="-fn -fh" # forbid nestloop and hash, ie, force mergejoin
PGOPTIONS="-fn -fm" # forbid nestloop and merge, ie, force hashjoin
Also, I don't think you ever mentioned exactly what the available
indexes are on these tables?
regards, tom lane
From bouncefilter Wed Sep 22 20:06:50 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA74982
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 20:06:25 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id UAA06411
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 20:05:40 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Progress report: buffer refcount bugs and SQL functions
Date: Wed, 22 Sep 1999 20:05:39 -0400
Message-ID: <6408.938045139@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I have been finding a lot of interesting stuff while looking into
the buffer reference count/leakage issue.
It turns out that there were two specific things that were camouflaging
the existence of bugs in this area:
1. The BufferLeakCheck routine that's run at transaction commit was
only looking for nonzero PrivateRefCount to indicate a missing unpin.
It failed to notice nonzero LastRefCount --- which meant that an
error in refcount save/restore usage could leave a buffer pinned,
and BufferLeakCheck wouldn't notice.
2. The BufferIsValid macro, which you'd think just checks whether
it's handed a valid buffer identifier or not, actually did more:
it only returned true if the buffer ID was valid *and* the buffer
had positive PrivateRefCount. That meant that the common pattern
if (BufferIsValid(buf))
ReleaseBuffer(buf);
wouldn't complain if it were handed a valid but already unpinned buffer.
And that behavior masks bugs that result in buffers being unpinned too
early. For example, consider a sequence like
1. LockBuffer (buffer now has refcount 1). Store reference to
a tuple on that buffer page in a tuple table slot.
2. Copy buffer reference to a second tuple-table slot, but forget to
increment buffer's refcount.
3. Release second tuple table slot. Buffer refcount drops to 0,
so it's unpinned.
4. Release original tuple slot. Because of BufferIsValid behavior,
no assert happens here; in fact nothing at all happens.
This is, of course, buggy code: during the interval from 3 to 4 you
still have an apparently valid tuple reference in the original slot,
which someone might try to use; but the buffer it points to is unpinned
and could be replaced at any time by another backend.
In short, we had errors that would mask both missing-pin bugs and
missing-unpin bugs. And naturally there were a few such bugs lurking
behind them...
3. The buffer refcount save/restore stuff, which I had suspected
was useless, is not only useless but also buggy. The reason it's
buggy is that it only works if used in a nested fashion. You could
save state A, pin some buffers, save state B, pin some more
buffers, restore state B (thereby unpinning what you pinned since
the save), and finally restore state A (unpinning the earlier stuff).
What you could not do is save state A, pin, save B, pin more, then
restore state A --- that might unpin some of A's buffers, or some
of B's buffers, or some unforeseen combination thereof. If you
restore A and then restore B, you do not necessarily return to a zero-
pins state, either. And it turns out the actual usage pattern was a
nearly random sequence of saves and restores, compounded by a failure to
do all of the restores reliably (which was masked by the oversight in
BufferLeakCheck).
What I have done so far is to rip out the buffer refcount save/restore
support (including LastRefCount), change BufferIsValid to a simple
validity check (so that you get an assert if you unpin something that
was pinned), change ExecStoreTuple so that it increments the refcount
when it is handed a buffer reference (for symmetry with ExecClearTuple's
decrement of the refcount), and fix about a dozen bugs exposed by these
changes.
I am still getting Buffer Leak notices in the "misc" regression test,
specifically in the queries that invoke more than one SQL function.
What I find there is that SQL functions are not always run to
completion. Apparently, when a function can return multiple tuples,
it won't necessarily be asked to produce them all. And when it isn't,
postquel_end() isn't invoked for the function's current query, so its
tuple table isn't cleared, so we have dangling refcounts if any of the
tuples involved are in disk buffers.
It may be that the save/restore code was a misguided attempt to fix
this problem. I can't tell. But I think what we really need to do is
find some way of ensuring that Postquel function execution contexts
always get shut down by the end of the query, so that they don't leak
resources.
I suppose a straightforward approach would be to keep a list of open
function contexts somewhere (attached to the outer execution context,
perhaps), and clean them up at outer-plan shutdown.
What I am wondering, though, is whether this addition is actually
necessary, or is it a bug that the functions aren't run to completion
in the first place? I don't really understand the semantics of this
"nested dot notation". I suppose it is a Berkeleyism; I can't find
anything about it in the SQL92 document. The test cases shown in the
misc regress test seem peculiar, not to say wrong. For example:
regression=> SELECT p.hobbies.equipment.name, p.hobbies.name, p.name FROM person p;
name |name |name
-------------+-----------+-----
advil |posthacking|mike
peet's coffee|basketball |joe
hightops |basketball |sally
(3 rows)
which doesn't appear to agree with the contents of the underlying
relations:
regression=> SELECT * FROM hobbies_r;
name |person
-----------+------
posthacking|mike
posthacking|jeff
basketball |joe
basketball |sally
skywalking |
(5 rows)
regression=> SELECT * FROM equipment_r;
name |hobby
-------------+-----------
advil |posthacking
peet's coffee|posthacking
hightops |basketball
guts |skywalking
(4 rows)
I'd have expected an output along the lines of
advil |posthacking|mike
peet's coffee|posthacking|mike
hightops |basketball |joe
hightops |basketball |sally
Is the regression test's expected output wrong, or am I misunderstanding
what this query is supposed to do? Is there any documentation anywhere
about how SQL functions returning multiple tuples are supposed to
behave?
regards, tom lane
From bouncefilter Wed Sep 22 20:30:58 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id UAA79270
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 20:30:18 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11Twf0-0003kLC; Thu, 23 Sep 99 02:22 MET DST
Message-Id: <m11Twf0-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Compile timing
To: lamar.owen@wgcr.org (Lamar Owen)
Date: Thu, 23 Sep 1999 02:22:54 +0200 (MET DST)
Cc: maillist@candle.pha.pa.us, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37E9455F.3FAFA875@wgcr.org> from "Lamar Owen" at Sep 22,
99 05:08:47 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Lamar Owen wrote:
Bruce Momjian wrote:
Someone mentioned that it took them quite a while to compile the
PostgreSQL code. My wallclock time is 3:52 for a compile with -O1 using
gcc 2.7.2.1. This is on a dual-PII 350MHz running BSD/OS 4.01.
Hmmm,
Is there something wrong with your system, Bruce? My 64MB
333MHz singe-PII (same gcc version under Linux 2.2.10) does a
-O1 clean-compile in 3:28.
Maybe the SMP overhead is eating up the missing cycles. You
would like a parallelized make to outperform me again - no?
You have a machine that is 5 times faster than mine. Also, this is more
than a compile -- this is a whole sequence of events -- cleaning out the
old build directory, unpacking the tarball, applying patches,
configure;make;make install, some other sequences of events, and then
cpio'ing and compressing to build several rpm's. So, about two thirds
of the time is actually spent compiling, which is still a little slow
compared to your result.
Lamar, shouldn't you run at least the regression suite too
before building the rpm's?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Wed Sep 22 20:27:46 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA78584
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 20:26:46 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA03871;
Wed, 22 Sep 1999 21:25:04 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 22 Sep 1999 21:25:03 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
In-Reply-To: <4211.938039368@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9909222100560.38923-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Okay, after playing around with this some more tonight, and playing with
the PGOPTIONS you've presented...I've gotten the query to be faster then
with mysql :) The error of my ways: not enough indices *sigh* I created a
few more on the fields that were being used on the query, and have:
SELECT c.id, c.name, c.url
FROM aecCategory c
WHERE EXISTS (
SELECT a.status
FROM aecEntMain a, aecWebEntry b
WHERE a.status LIKE 'active:ALL%'
AND a.representation LIKE '%:ALL%'
AND b.status LIKE 'active:ALL%'
AND b.indid='000001'
AND b.divid='100016'
AND ((a.id,a.mid) = (b.id,b.mid))
AND ((b.catid,b.indid,b.divid) = (c.id,c.ppid,c.pid)));
==========
Seq Scan on aeccategory c (cost=69.61 rows=1170 width=36)
SubPlan
-> Nested Loop (cost=4.10 rows=1 width=60)
-> Index Scan using aecwebentry_divid on aecwebentry b (cost=2.03 rows=1 width=24)
-> Index Scan using aecentmain_primary on aecentmain a (cost=2.07 rows=480 width=36)
===========
producing the results I need in 1.26seconds, using 1.5% of the CPU.
Now, something does bother me here, and I'm not sure if its a problem we
need to address, or if its expected, but if I remove the index
aecwebentry_divid, it reverts to using aecwebentry_primary and increases
the query time to 12secs, which is:
create unique index aecWebEntry_primary on aecWebEntry ( indid,divid,catid,id,mid);
Should it do that?
On Wed, 22 Sep 1999, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Anyone get a chance to look into this?
Only just now, but I do have a couple of thoughts.
For the query
SELECT distinct b.indid, b.divid, b.catid, a.id, a.mid \
FROM aecEntMain a, aecWebEntry b \
WHERE (a.id=b.id AND a.mid=b.mid) \
AND (a.status like 'active%' and b.status like 'active%')
AND (a.status like '%active:ALL%' and b.status like '%active:ALL%')
AND (a.representation like '%:ALL%')
AND (b.indid=? and b.divid=? and b.catid=?)";you're showing a plan of
Unique (cost=1271.15 rows=5 width=84)
-> Sort (cost=1271.15 rows=5 width=84)
-> Nested Loop (cost=1271.15 rows=5 width=84)
-> Index Scan using aecwebentry_primary on aecwebentry b (cost=1269.08 rows=1 width=60)
-> Index Scan using aecentmain_primary on aecentmain a (cost=2.07 rows=16560 width=24)which indicates that the optimizer is guessing only one match in
aecwebentry and is therefore putting it on the outside of the nested
loop (so that the inner scan over aecentmain would only have to be
done once, if it's guessing right). But in a later message you
say that the actual number of hits is more like 39 for aecwebentry
and one for aecentmain. Which means that the nested loop would go
faster if it were done the other way round, aecentmain on the outside.
I'm not sure of a way to force the system to try it that way, though.The other question is why is it using a nested loop at all, rather
than something more intelligent like merge or hash join. Presumably
the optimizer thinks those would be more expensive, but it might be
wrong.You could try forcing selection of merge and hash joins for this
query and see (a) what kind of plan do you get, (b) how long does
it really take? To do that, start psql with PGOPTIONS environment
variable set:PGOPTIONS="-fn -fh" # forbid nestloop and hash, ie, force mergejoin
PGOPTIONS="-fn -fm" # forbid nestloop and merge, ie, force hashjoin
Also, I don't think you ever mentioned exactly what the available
indexes are on these tables?regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Sep 22 21:26:44 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id VAA87909
for <pgsql-hackers@postgresql.org>;
Wed, 22 Sep 1999 21:26:36 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgresql.org
id m11TxXw-0003kLC; Thu, 23 Sep 99 03:19 MET DST
Message-Id: <m11TxXw-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Progress report: buffer refcount bugs and SQL functions
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Thu, 23 Sep 1999 03:19:39 +0200 (MET DST)
Cc: pgsql-hackers@postgresql.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <6408.938045139@sss.pgh.pa.us> from "Tom Lane" at Sep 22,
99 08:05:39 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Tom Lane wrote:
[...]
What I am wondering, though, is whether this addition is actually
necessary, or is it a bug that the functions aren't run to completion
in the first place? I don't really understand the semantics of this
"nested dot notation". I suppose it is a Berkeleyism; I can't find
anything about it in the SQL92 document. The test cases shown in the
misc regress test seem peculiar, not to say wrong. For example:[...]
Is the regression test's expected output wrong, or am I misunderstanding
what this query is supposed to do? Is there any documentation anywhere
about how SQL functions returning multiple tuples are supposed to
behave?
I've said some time (maybe too long) ago, that SQL functions
returning tuple sets are broken in general. This nested dot
notation (which I think is an artefact from the postquel
querylanguage) is implemented via set functions.
Set functions have total different semantics from all other
functions. First they don't really return a tuple set as
someone might think - all that screwed up code instead
simulates that they return something you could consider a
scan of the last SQL statement in the function. Then, on
each subsequent call inside of the same command, they return
a "tupletable slot" containing the next found tuple (that's
why their Func node is mangled up after the first call).
Second they have a targetlist what I think was originally
intended to extract attributes out of the tuples returned
when the above scan is asked to get the next tuple. But as I
read the code it invokes the function again and this might
cause the resource leakage you see.
Third, all this seems to never have been implemented
(thought?) to the end. A targetlist doesn't make sense at
this place because it could at max contain a single attribute
- so a single attno would have the same power. And if set
functions could appear in the rangetable (FROM clause), than
they would be treated as that and regular Var nodes in the
query would do it.
I think you shouldn't really care for that regression test
and maybe we should disable set functions until we really
implement stored procedures returning sets in the rangetable.
Set functions where planned by Stonebraker's team as
something that today is called stored procedures. But AFAIK
they never reached the useful state because even in Postgres
4.2 you haven't been able to get more than one attribute out
of a set function. It was a feature of the postquel
querylanguage that you could get one attribute from a set
function via
RETRIEVE (attributename(setfuncname()))
While working on the constraint triggers I've came across
another regression test (triggers :-) that's errorneous too.
The funny_dup17 trigger proc executes an INSERT into the same
relation where it get fired for by a previous INSERT. And it
stops this recursion only if it reaches a nesting level of
17, which could only occur if it is fired DURING the
execution of it's own SPI_exec(). After Vadim quouted some
SQL92 definitions about when constraint checks and triggers
are to be executed, I decided to fire regular triggers at the
end of a query too. Thus, there is absolutely no nesting
possible for AFTER triggers resulting in an endless loop.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Wed Sep 22 21:22:44 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA87297
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 21:22:37 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA09138
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 21:22:06 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Re: Progress report: buffer refcount bugs and SQL functions
In-reply-to: Your message of Wed, 22 Sep 1999 20:05:39 -0400
<6408.938045139@sss.pgh.pa.us>
Date: Wed, 22 Sep 1999 21:22:06 -0400
Message-ID: <9136.938049726@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I wrote:
What I have done so far is to rip out the buffer refcount save/restore
support (including LastRefCount), change BufferIsValid to a simple
validity check (so that you get an assert if you unpin something that
was pinned), ...
er, make that "unpin something that *wasn't* pinned".
regards, tom lane
From bouncefilter Wed Sep 22 22:24:45 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id WAA02622
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 22:24:33 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11TyS1-0003kzC; Thu, 23 Sep 99 04:17 MET DST
Message-Id: <m11TyS1-0003kzC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Another RI question
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Thu, 23 Sep 1999 04:17:37 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Me again,
I'm just collecting info's for later. What I need to know is
how PK/FK constraints are defined in the standard.
Is it ALLWAYS the case, that a FK constraint refers to the PK
of another table? Or could arbitraty attributes of another
table be referenced by a FK too?
Is it guaranteed that I find the PK definition of a table
allways in the index <tablename>_pkey? If so it would be nice
to ensure that an index with that name created manually is
defined unique and/or cannot be created/dropped explicitly -
this is important for RI.
Another (my preferred) way would be to name the automatically
created PK index something like "pg_pkey_<tableoid>". This
would have the advantage that we never run out of 32 char
limit on name and that the user cannot create/drop this index
by hand.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Wed Sep 22 23:31:48 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA27177
for <pgsql-hackers@postgreSQL.org>;
Wed, 22 Sep 1999 23:31:19 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id XAA02096;
Wed, 22 Sep 1999 23:01:10 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909230301.XAA02096@candle.pha.pa.us>
Subject: Re: [HACKERS] Compile timing
In-Reply-To: <m11Twf0-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Sep 23, 1999 02:22:54 am"
To: Jan Wieck <wieck@debis.com>
Date: Wed, 22 Sep 1999 23:01:10 -0400 (EDT)
CC: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lamar Owen wrote:
Bruce Momjian wrote:
Someone mentioned that it took them quite a while to compile the
PostgreSQL code. My wallclock time is 3:52 for a compile with -O1 using
gcc 2.7.2.1. This is on a dual-PII 350MHz running BSD/OS 4.01.Hmmm,
Is there something wrong with your system, Bruce? My 64MB
333MHz singe-PII (same gcc version under Linux 2.2.10) does a
-O1 clean-compile in 3:28.Maybe the SMP overhead is eating up the missing cycles. You
would like a parallelized make to outperform me again - no?
I knew someone would find this an interesting topic.
I should also mention I have 256MB of RAM, and Baracuda SCSI-Ultra
drives with tagged queuing enabled.
OK, I turned off my custom flags, and got for -O1:
real 3m8.080s
user 2m21.752s
sys 0m35.291s
I usually do:
CUSTOM_COPT=-g -Wall -O1 -Wmissing-prototypes -Wmissing-declarations
My bet is the symbol output takes some time to produce. I noticed the
link of the postgres binary was faster without -g.
With parallelization, using gmake -j2, I got:
real 3m8.980s
user 2m23.442s
sys 0m36.142s
Not sure why -j2 is not faster than normal -j, unless gmake knows to use
-j2 on a 2-cpu system by default. Looking at the xps output, I don't
see multiple compiles being performed by gmake.
Gmake -j fails because compiles happen before supporting files are
created.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Thu Sep 23 01:39:52 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA61252
for <pgsql-hackers@postgresql.org>;
Thu, 23 Sep 1999 01:39:43 -0400 (EDT)
(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 FAA18624;
Thu, 23 Sep 1999 05:38:55 GMT
Sender: lockhart@hub.org
Message-ID: <37E9BCEF.57C8F6A8@alumni.caltech.edu>
Date: Thu, 23 Sep 1999 05:38:55 +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: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Jan Wieck <wieck@debis.com>, Lamar Owen <lamar.owen@wgcr.org>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Compile timing
References: <199909230301.XAA02096@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Not sure why -j2 is not faster than normal -j...
I was just looking at this a little while ago at work. It is not
faster because gmake does not propagate the "-j2" flag to submakes, on
the (correct) theory that you might get a geometrically growing system
load, rather than just keeping two makes running through all the
subdirectories.
This is the behavior of "-j", unless you specify it without a numeric
parameter, in which case it *does* allow parallel submakes.
The first time I tried "-j", I did it without reading the man pages
and without specifying a numeric parameter. It did a magnificent job
of bringing down my system trying to build ACE/TAO, a *large* Corba
package. Chewed up all of real memory, then all of swap; not sure if I
ran out of process slots or memory first but it wasn't pretty. It was
*very* fast though :)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Sep 23 01:46:48 1999
Received: from socket.house (anonymous@mumble.frotz.net [216.15.97.250])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA62268
for <pgsql-hackers@postgresql.org>;
Thu, 23 Sep 1999 01:45:56 -0400 (EDT)
(envelope-from adam@newsnipple.com)
Received: by newsnipple.com via sendmail from stdin
id <m11U1hb-000KsJC@socket.house> (Debian Smail3.2.0.102)
for pgsql-hackers@postgresql.org; Wed, 22 Sep 1999 22:45:55 -0700 (PDT)
Date: Wed, 22 Sep 1999 22:45:55 -0700
From: Adam Haberlach <haberlaa@ricochet.net>
To: pgsql-hackers@postgresql.org
Message-ID: <19990922224555.C13363@ricochet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
unsubscribe
From bouncefilter Thu Sep 23 03:45:49 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA81908
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 03:45:18 -0400 (EDT)
(envelope-from a.joubert@albourne.com)
Received: from isadora.cy.albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.6X) with ESMTP
id KAA16890; Thu, 23 Sep 1999 10:47:43 +0300 (EET DST)
Received: from albourne.com (localhost [127.0.0.1])
by isadora.cy.albourne.com (8.9.3/8.9.3/Albourne/CYC/1.4) with ESMTP id
KAA31671; Thu, 23 Sep 1999 10:45:09 +0300 (EET DST)
Sender: a.joubert@albourne.com
Message-ID: <37E9DA85.F0210261@albourne.com>
Date: Thu, 23 Sep 1999 10:45:09 +0300
From: Adriaan Joubert <a.joubert@albourne.com>
Organization: APL Financial Services (Overseas) Ltd
X-Mailer: Mozilla 4.61 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Postgresql <pgsql-hackers@postgreSQL.org>,
Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] Operator definitions
References: <2198.938033780@sss.pgh.pa.us>
Content-Type: multipart/mixed; boundary="------------827046437B2B894D41A4E11C"
This is a multi-part message in MIME format.
--------------827046437B2B894D41A4E11C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
It looks to me like '^' and '|' have been left out of the alternatives
for MathOp in src/backend/parser/gram.y. It could be they were
deliberately omitted, but I bet it's just an oversight.
OK, here is a patch to allow both ^ and | as operators, both in operator
definitions and expressions. It seems to work for me. Unfortunately the
regression tests do not tell me an awful lot, as several of them fail on
the Alpha anyway. As I don;t really know what I'm doing, I'd appreciate
it if somebody else could check the patch out and let me know whether it
is ok.
Cheers,
Adriaan
--------------827046437B2B894D41A4E11C
Content-Type: text/plain; charset=us-ascii;
name="pgram"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="pgram"
*** src/backend/parser/gram.y Thu Sep 23 10:36:47 1999
--- src/backend/parser/gram.y.orig Tue Sep 14 09:07:35 1999
***************
*** 2021,2028 ****
| '*' { $$ = "*"; }
| '/' { $$ = "/"; }
| '%' { $$ = "%"; }
- | '^' { $$ = "^"; }
- | '|' { $$ = "|"; }
| '<' { $$ = "<"; }
| '>' { $$ = ">"; }
| '=' { $$ = "="; }
--- 2021,2026 ----
***************
*** 3666,3673 ****
{ $$ = makeA_Expr(OP, "*", $1, $3); }
| a_expr '^' a_expr
{ $$ = makeA_Expr(OP, "^", $1, $3); }
- | a_expr '|' a_expr
- { $$ = makeA_Expr(OP, "|", $1, $3); }
| a_expr '<' a_expr
{ $$ = makeA_Expr(OP, "<", $1, $3); }
| a_expr '>' a_expr
--- 3664,3669 ------------------827046437B2B894D41A4E11C--
From bouncefilter Thu Sep 23 03:58:49 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id DAA83345
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 03:58:15 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11U3em-0003kLC; Thu, 23 Sep 99 09:51 MET DST
Message-Id: <m11U3em-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Compile timing
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Thu, 23 Sep 1999 09:51:08 +0200 (MET DST)
Cc: wieck@debis.com, lamar.owen@wgcr.org, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199909230301.XAA02096@candle.pha.pa.us> from "Bruce Momjian" at
Sep 22, 99 11:01:10 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
With parallelization, using gmake -j2, I got:
real 3m8.980s
user 2m23.442s
sys 0m36.142sNot sure why -j2 is not faster than normal -j, unless gmake knows to use
-j2 on a 2-cpu system by default. Looking at the xps output, I don't
see multiple compiles being performed by gmake.
Because it hasn't prallelized :-)
The -j2 wasn't handed down to the submakes and I'm sure
there's only one started from the top.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Thu Sep 23 04:10:49 1999
Received: from wilk.lupus.pl (root@wilk.lupus.pl [195.116.206.178])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA84963
for <pgsql-hackers@postgresql.org>;
Thu, 23 Sep 1999 04:10:05 -0400 (EDT)
(envelope-from grzegorz_przezdziecki@crn.pl)
Received: from crn.pl ([195.116.206.135])
by wilk.lupus.pl with ESMTP id JAA14736
for <pgsql-hackers@postgresql.org>; Thu, 23 Sep 1999 09:57:09 +0200
Message-ID: <37E9DF3B.55E430D9@crn.pl>
Date: Thu, 23 Sep 1999 10:05:15 +0200
From: Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?= <grzegorz_przezdziecki@crn.pl>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Problem with new function
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
I tray create new function bye read from file.
When I read this file I have errors
pgReadData()- backend closed the channel unexpectedly
in may log file :
Fatal 1 : btree: cannot split if start (2) >= maxoff (2)
or somethings like this:
fatal 1: my bits moved right off the end of the world!
PostgreSQL 6.5.1 on i686-pc-linux-gnu, compiled by gcc 2.7.2.31
on Debian Slink
Need help
Best regards
From bouncefilter Thu Sep 23 04:08:49 1999
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA84632
for <hackers@postgresql.org>; Thu, 23 Sep 1999 04:08:03 -0400 (EDT)
(envelope-from andreas.zeugswetter@telecom.at)
Received: from telecom.at (w0188000580.f000.d0188.sd.spardat.at
[172.18.65.249])
by gandalf.telecom.at (xxx/xxx) with ESMTP id KAA195294
for <hackers@postgresql.org>; Thu, 23 Sep 1999 10:07:27 +0200
Message-ID: <37E9DFBC.5C0978F@telecom.at>
Date: Thu, 23 Sep 1999 10:07:24 +0200
From: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgresql.org
Subject: Re: [HACKERS] Progress report: buffer refcount bugs and SQL functions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Is the regression test's expected output wrong, or am I
misunderstanding
what this query is supposed to do? Is there any
documentation anywhere
about how SQL functions returning multiple tuples are supposed to
behave?
They are supposed to behave somewhat like a view.
Not all rows are necessarily fetched.
If used in a context that needs a single row answer,
and the answer has multiple rows it is supposed to
runtime elog. Like in:
select * from tbl where col=funcreturningmultipleresults();
-- this must elog
while this is ok:
select * from tbl where col in (select funcreturningmultipleresults());
But the caller could only fetch the first row if he wanted.
The nested notation is supposed to call the function passing it the tuple
as the first argument. This is what can be used to "fake" a column
onto a table (computed column).
That is what I use it for. I have never used it with a
returns setof function, but reading the comments in the regression test,
-- mike needs advil and peet's coffee,
-- joe and sally need hightops, and
-- everyone else is fine.
it looks like the results you expected are correct, and currently the
wrong result is given.
But I think this query could also elog whithout removing substantial
functionality.
SELECT p.name, p.hobbies.name, p.hobbies.equipment.name FROM person p;
Actually for me it would be intuitive, that this query return one row per
person, but elog on those that have more than one hobbie or a hobbie that
needs more than one equipment. Those that don't have a hobbie should
return name|NULL|NULL. A hobbie that does'nt need equipment name|hobbie|NULL.
Andreas
From bouncefilter Thu Sep 23 04:17:49 1999
Received: from wilk.lupus.pl (root@wilk.lupus.pl [195.116.206.178])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA85704
for <pgsql-hackers@postgresql.org>;
Thu, 23 Sep 1999 04:16:48 -0400 (EDT)
(envelope-from grzegorz_przezdziecki@lupus.waw.pl)
Received: from lupus.waw.pl ([195.116.206.135])
by wilk.lupus.pl with ESMTP id KAA14836
for <pgsql-hackers@postgresql.org>; Thu, 23 Sep 1999 10:03:48 +0200
Message-ID: <37E9E0CB.C2FFF09B@lupus.waw.pl>
Date: Thu, 23 Sep 1999 10:11:55 +0200
From: Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?=
<grzegorz_przezdziecki@lupus.waw.pl>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Problem with new function
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
I tray create new function bye read from file.
When I read this file I have errors
pgReadData()- backend closed the channel unexpectedly
in may log file :
Fatal 1 : btree: cannot split if start (2) >= maxoff (2)
or somethings like this:
fatal 1: my bits moved right off the end of the world!
PostgreSQL 6.5.1 on i686-pc-linux-gnu, compiled by gcc 2.7.2.31
on Debian Slink
Need help
Best regards
From bouncefilter Thu Sep 23 04:28:49 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA87275
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 04:28:08 -0400 (EDT)
(envelope-from a.joubert@albourne.com)
Received: from isadora.cy.albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.6X) with ESMTP
id LAA16931; Thu, 23 Sep 1999 11:30:34 +0300 (EET DST)
Received: from albourne.com (localhost [127.0.0.1])
by isadora.cy.albourne.com (8.9.3/8.9.3/Albourne/CYC/1.4) with ESMTP id
LAA31715; Thu, 23 Sep 1999 11:28:00 +0300 (EET DST)
Sender: a.joubert@albourne.com
Message-ID: <37E9E490.1CD9623B@albourne.com>
Date: Thu, 23 Sep 1999 11:28:00 +0300
From: Adriaan Joubert <a.joubert@albourne.com>
Organization: APL Financial Services (Overseas) Ltd
X-Mailer: Mozilla 4.61 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <Pine.BSF.4.10.9909220246160.38923-100000@thelab.hub.org>
<37E87542.2F8ADA4A@albourne.com>
<37E8F672.9B98E9BF@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I don't have time right now to type up a short summary, but can do
that later if you like. But the data entry for an SQL92 bit type looks
likeB'10111'
X'17'The underlying data type is BIT(n), a fixed-length type where n is the
exact number of bits. BIT VARYING (n) allows a variable number of bits
(duh!) up to n bits. We can support these SQL92 constructs in the
parser, folding them into an internal type as we do for character
strings currently.It could be implemented just like the character types, having a header
on the internal representation which holds the length. It can't re-use
the character type support functions as-is, since they currently
consider a zero byte in the string as end-of-string.
OK, I'll have a go at this as I get a chance. If somebody has the SQL
standard on line and could send me the appropriate sections I would
appreciate it.
As I know very little about the postgres internals I would also
appreciate a short roadmap as to what needs to be done where, i.e. does
the parser need to be changed, and where the files are /new files hsould
go that I need to update. If this is somewhere in the docs please point
me to it.
What I've found upto now is
backend/utils/adt/varlena.c
backend/utils/adt/varchar.c
which I will use as starting point?
I found the file src/backend/lib/bit.c (Bruce's according to the log
message). Has that got anything to do with bit arrays?
Cheers,
Adriaan
From bouncefilter Thu Sep 23 04:50:52 1999
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA90540
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 04:50:48 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (A173.dialup.udm.net [213.24.0.173])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id NAA58285;
Thu, 23 Sep 1999 13:50:32 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37E9E7F8.5160801C@udmnet.ru>
Date: Thu, 23 Sep 1999 13:42:32 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: Adam Haberlach <haberlaa@ricochet.net>
CC: pgsql-hackers@postgreSQL.org
Subject: Re:
References: <19990922224555.C13363@ricochet.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
unsubscribe
Majordomo@hub.org: error: no such command 'unsubscribe'.
Try 'unsubscribe please'
************
From bouncefilter Thu Sep 23 05:00:50 1999
Received: from wilk.lupus.pl (root@wilk.lupus.pl [195.116.206.178])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA91532
for <hackers@postgreSQL.org>; Thu, 23 Sep 1999 04:59:45 -0400 (EDT)
(envelope-from grzegorz_przezdziecki@lupus.waw.pl)
Received: from lupus.waw.pl ([195.116.206.135])
by wilk.lupus.pl with ESMTP id KAA15534
for <hackers@postgreSQL.org>; Thu, 23 Sep 1999 10:46:50 +0200
Message-ID: <37E9EAE2.A9DC3B9F@lupus.waw.pl>
Date: Thu, 23 Sep 1999 10:54:58 +0200
From: Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?=
<grzegorz_przezdziecki@lupus.waw.pl>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgreSQL.org
Subject: Re Problem with new function
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
I write to you few minuts ego.
I show you two files
-----------------------------------1---------------------------------
--/***************************************************************************/
--! 23.09.1999 Warszawa
--% Grzegorz Przezdziecki
--@ grzegorz_przezdziecki@crn.pl;gprzezdz@elektron.elka.pw.edu.pl
--# CREATE FUNCTION fu_idklienci() RETURNS OPAQUE AS'
--$ funkcja bedzie wywololywana przez triger w momencie dodania nowego
telefonu
--$ do tablei telefonow klienta
--/***************************************************************************/
--/***************************************************************************/
-- FUNKCJA PRZED INSERTEM DO TABELI telefon klienta
--/***************************************************************************/
CREATE FUNCTION fu_idklienci() RETURNS OPAQUE AS'
DECLARE
id int4;
BEGIN
--SPRAWDZAMY FIRME
IF NEW.firma ISNULL THEN
RAISE EXCEPTION ''Pole firma musi
posiadac wartosc'';
END IF;
SELECT id_firmy INTO id FROM tb_firmy WHERE
id_firmy = NEW.id_firma;
IF NOT FOUND THEN
RAISE EXCEPTION ''Brak firmy numer
%'',NEW.id_firma;
END If;
NEW.ID_klienci:=nextval(''se_idklienci'');
RETURN NEW;
END;'
LANGUAGE 'plpgsql';
--/***************************************************************************/
--/***************************************************************************/
this file makes errors
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is
impossible.
Terminating.
and in log file :
Sep 23 11:00:14 Databases logger: FATAL 1: btree: cannot split if start
(2) >=
maxoff (2)
second file is OK
------------------------------------------2------------------------------------------
--/***************************************************************************/
--! 23.09.1999 Warszawa
--% Grzegorz Przezdziecki
--@ grzegorz_przezdziecki@crn.pl;gprzezdz@elektron.elka.pw.edu.pl
--# CREATE FUNCTION fu_idklienci() RETURNS OPAQUE AS'
--$ funkcja bedzie wywololywana przez triger w momencie dodania nowego
telefonu
--$ do tablei telefonow klienta
--/***************************************************************************/
--/***************************************************************************/
-- FUNKCJA PRZED INSERTEM DO TABELI telefon klienta
--/***************************************************************************/
CREATE FUNCTION fu_idklienci() RETURNS OPAQUE AS'
DECLARE
id int4;
BEGIN
IF NEW.firma ISNULL THEN
RAISE EXCEPTION ''Pole firma musi
posiadac wartosc'';
END IF;
SELECT id_firmy INTO id FROM tb_firmy WHERE
id_firmy = NEW.id_firma;
IF NOT FOUND THEN
RAISE EXCEPTION ''Brak firmy numer
%'',NEW.id_firma;
END If;
NEW.ID_klienci:=nextval(''se_idklienci'');
RETURN NEW;
END;'
LANGUAGE 'plpgsql';
--/***************************************************************************/
--/***************************************************************************/
Diference is in line
--SPRAWDZAMY FIRME
I use
Zed editor
[PostgreSQL 6.5.1 on i686-pc-linux-gnu, compiled by gcc 2.7.2.3]
on Debian
kernel 2.0.36
What is means this error
Sep 23 11:00:14 Databases logger: FATAL 1: btree: cannot split if start
(2) >=
maxoff (2)
Best regards
From bouncefilter Thu Sep 23 05:13:50 1999
Received: from oak.fernuni-hagen.de (oak.fernuni-hagen.de [132.176.114.41])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA94927
for <pgsql-hackers@postgresql.org>;
Thu, 23 Sep 1999 05:13:38 -0400 (EDT)
(envelope-from Jose-Antonio.Cotelo-Lema@FernUni-Hagen.de)
Received: from nansen.fernuni-hagen.de by oak.fernuni-hagen.de
via local-channel with SMTP; Thu, 23 Sep 1999 11:13:08 +0200
Received: from robinson.fernuni-hagen.de
by nansen.fernuni-hagen.de (SMI-8.6/SMI-SVR4) id LAA28215;
Thu, 23 Sep 1999 11:13:00 +0200
Received: from fernuni-hagen.de
by robinson.fernuni-hagen.de (SMI-8.6/SMI-SVR4) id LAA18728;
Thu, 23 Sep 1999 11:13:02 +0200
Sender: cotelo@FernUni-Hagen.de
Message-ID: <37E9EF1E.47926D0B@fernuni-hagen.de>
Date: Thu, 23 Sep 1999 11:13:02 +0200
From: Jose Antonio Cotelo lema <Jose-Antonio.Cotelo-Lema@FernUni-Hagen.de>
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Problems when opening large objects in the server side.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi!
My problem is that I am defining a user data type that stores some
information in a large object (inversion object). If I compile the code
of such data type as part of a stand alone program (comunicating with
the PostgreSQL server usign libpq), I am able to create the large object
but I get an error when trying to open it.
After searching in recopilations of newsgroups emails, I know that in
this case what I need to do is to execute the "begin" command (using
pqexec()) before opening the large object, because any access to a large
object must be enclosed into a transaction. If I do so, I get my data
types working propertly and being able to open the large objects that
they use.
But my problem is that I do not want to use my data types in a
stand alone program, but added to the PostgreSQL server as new user data
types. An the problem in this case is that I can not execute the "begin"
command in the code of my data types in this context: first because it
would be definetly wrong if the code of the data type defines where
should start or end a transaction (the program accessing the database or
the user if working interactively are the only that should do it), and
second because in this case the call to pgexec() with the command
"begin" fails (with some error mesage saying that there was a parsing
error).
So, my question is: What do I need to do for solve this problen and
being able to use large objects in my user data types, taking into
account that their code should be executed in the server side?
Thanks in advance,
Tony.
--
Jose Antonio Cotelo Lema. | Jose-Antonio.Cotelo-Lema@FernUni-Hagen.de
Praktische Informatik IV. Fernuniversitaet Hagen.
D-58084 Hagen. Germany.
From bouncefilter Thu Sep 23 05:21:50 1999
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA96206
for <hackers@postgresql.org>; Thu, 23 Sep 1999 05:21:12 -0400 (EDT)
(envelope-from andreas.zeugswetter@telecom.at)
Received: from telecom.at (w0188000580.f000.d0188.sd.spardat.at
[172.18.65.249])
by gandalf.telecom.at (xxx/xxx) with ESMTP id LAA54768
for <hackers@postgresql.org>; Thu, 23 Sep 1999 11:20:40 +0200
Message-ID: <37E9F0E6.A88EFB66@telecom.at>
Date: Thu, 23 Sep 1999 11:20:38 +0200
From: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgresql.org
Subject: Re: [HACKERS] Another RI question
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Is it ALLWAYS the case, that a FK constraint refers to the PK
of another table? Or could arbitraty attributes of another
table be referenced by a FK too?
arbitrary (usually unique indexed) columns
Is it guaranteed that I find the PK definition of a table
allways in the index <tablename>_pkey?
No. I think there is a column in pg_index that marks a pk already.
(for odbc) This would imho be the best way.
Another (my preferred) way would be to name the automatically
created PK index something like "pg_pkey_<tableoid>". This
You want to have the ability to:
1. create table
2. create unique index
3. alter table add constraint primary key (uses existing index)
The automatic naming should be irrelevant.
Andreas
From bouncefilter Thu Sep 23 06:18:51 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA03778
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 06:18:35 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id TAA13250; Thu, 23 Sep 1999 19:18:22 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Horak Daniel" <horak@mmp.plzen-city.cz>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] IPC on win32 - additions for 6.5.2 and current trees
Date: Thu, 23 Sep 1999 19:21:55 +0900
Message-ID: <000e01bf05ad$75b8f540$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000F_01BF05F8.E5A09D40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To:
<2E7F82FAC1FCD2118E1500A024B3BF907DED62@exchange.mmp.plzen-city.cz>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
This is a multi-part message in MIME format.
------=_NextPart_000_000F_01BF05F8.E5A09D40
Content-Type: text/plain;
charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Horak Daniel
Sent: Monday, August 30, 1999 9:15 PM
To: 'pgsql-hackers@postgreSQL.org'; 'pgsql-patches@postgresql.org'
Subject: [HACKERS] IPC on win32 - additions for 6.5.2 and current treesHi,
please add the file ipc.patch (patch for the cygipc library) into
src/win32
directory and apply the patch for README.NT (readme.patch). I think it
should go into both the 6.5.2 and current trees.I have no reaction from the author of the cygipc library yet, so
it will be
better to include the patch into the sources of PostgreSQL
It's me who made the patch. Yutaka Tanida also provided a patch
for cygipc library to prevent lock freezing by changing the
implementation of semaphore.
These patches are necessary to prevent freezing in cygwin port.
If there's no objection,I would add a new ipc.patch provided by
Yutaka into src/win32 and commit the patch for README.NT
for current tree.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
------=_NextPart_000_000F_01BF05F8.E5A09D40
Content-Type: application/octet-stream;
name="ipc.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="ipc.patch"
*** ./ipc-daemon.c.orig Tue Dec 01 00:04:24 1998
--- ./ipc-daemon.c Mon Aug 30 17:16:03 1999
***************
*** 280,285 ****
--- 280,286 ----
LAdrSem->semary[id] =3D IPC_UNUSED ;
LAdrSem->state[id] =3D 0 ;
}
+ /*
else
{
for (Index =3D 0; Index < sma->sem_nsems; Index++)
***************
*** 288,293 ****
--- 289,295 ----
LHandle =3D OpenSemaphore(SEMAPHORE_ALL_ACCESS, FALSE, LBuff) =
;
}
}
+ */
}
}
=20
*** ./msg.c.orig Tue Dec 01 00:16:09 1998
--- ./msg.c Fri Sep 17 12:50:50 1999
***************
*** 57,62 ****
--- 57,77 ----
static int GFirstMsg =3D 0; /*PCPC*/
static int GFdMsg ; /*PCPC*/
=20
+ /*****************************************/
+ /* Initialization of static variables */
+ /*****************************************/
+ static pid_t GProcessId =3D 0;
+ static void init_globals(void)
+ {
+ pid_t pid;
+=20
+ if (pid=3Dgetpid(), pid !=3D GProcessId)
+ {
+ GFirstMsg =3D 0;
+ msgbytes =3D msghdrs =3D msg_seq =3D used_queues =3D max_msqid =3D =
0;
+ GProcessId =3D pid;
+ }
+ }
=
/************************************************************************=
/
/* Demande d'acces a la zone partagee de gestion des semaphores */
=
/************************************************************************=
/
***************
*** 79,84 ****
--- 94,100 ----
{
int LRet ;
=20
+ init_globals();
if( GFirstMsg =3D=3D 0 )
{
if( IsGSemMsgExist() )
*** ./sem.c.orig Tue Dec 01 00:16:25 1998
--- ./sem.c Fri Sep 17 12:47:11 1999
***************
*** 58,63 ****
--- 58,78 ----
static int GFirstSem =3D 0; /*PCPC*/
static int GFdSem ; /*PCPC*/
=20
+ static pid_t GProcessId =3D 0;
+=20
+ static void init_globals(void)
+ {
+ pid_t pid;
+=20
+ if (pid=3Dgetpid(), pid !=3D GProcessId)
+ {
+ GFirstSem =3D 0;
+ used_sems =3D used_semids =3D max_semid =3D 0;
+ sem_seq =3D 0;
+ GProcessId =3D pid;
+ }
+ }
+=20
=
/************************************************************************=
/
/* Demande d'acces a la zone partagee de gestion des semaphores */
=
/************************************************************************=
/
***************
*** 77,82 ****
--- 92,98 ----
{
int LRet ;
=20
+ init_globals();
if( GFirstSem =3D=3D 0 )
{
if( IsGSemSemExist() )
***************
*** 187,193 ****
{
CloseHandle ( LHandle ) ;
}
! LHandle =3D CreateSemaphore(NULL, 0, 0x7FFFFFFF, LBuff) ;
if( LHandle =3D=3D NULL )
{
printf( "Creation de Semaphore \"Sem\" impossible\n" ) ;
--- 203,209 ----
{
CloseHandle ( LHandle ) ;
}
! LHandle =3D CreateSemaphore(NULL, 0, 1, LBuff) ;
if( LHandle =3D=3D NULL )
{
printf( "Creation de Semaphore \"Sem\" impossible\n" ) ;
***************
*** 357,371 ****
debug_printf("do_semop : return -EACCES\n");
CYGWIN32_IPCNT_RETURN (-EACCES) ;
}
! ReleaseSemaphore(LHandle, sop->sem_op, &LVal) ;
! shareadrsem->current_nb[id].current_nb[sop->sem_num] +=3D
! sop->sem_op ;
sem_deconnect() ;
} else {
if( sop->sem_flg =3D=3D IPC_NOWAIT )
{
! LRet =3D WaitForSingleObject(LHandle, 0) ;
! if( LRet =3D=3D WAIT_TIMEOUT )
{
debug_printf("do_semop : return -EAGAIN\n");
CYGWIN32_IPCNT_RETURN (-EAGAIN) ;
--- 373,386 ----
debug_printf("do_semop : return -EACCES\n");
CYGWIN32_IPCNT_RETURN (-EACCES) ;
}
! shareadrsem->current_nb[id].current_nb[sop->sem_num] +=3D
! sop->sem_op ;
sem_deconnect() ;
+ ReleaseSemaphore(LHandle, 1 , &LVal) ;
} else {
if( sop->sem_flg =3D=3D IPC_NOWAIT )
{
! if( sop->sem_op + =
shareadrsem->current_nb[id].current_nb[sop->sem_num] <0 )
{
debug_printf("do_semop : return -EAGAIN\n");
CYGWIN32_IPCNT_RETURN (-EAGAIN) ;
***************
*** 375,390 ****
debug_printf("do_semop : return -EACCES\n");
CYGWIN32_IPCNT_RETURN (-EACCES) ;
}
! shareadrsem->current_nb[id].current_nb[sop->sem_num] -=3D 1 ;
sem_deconnect() ;
} else {
! LRet =3D WaitForSingleObject(LHandle, INFINITE) ;
if (sem_connect() =3D=3D 0)
{
debug_printf("do_semop : return -EACCES\n");
CYGWIN32_IPCNT_RETURN (-EACCES) ;
}
! shareadrsem->current_nb[id].current_nb[sop->sem_num] -=3D 1 ;
sem_deconnect() ;
}
}
--- 390,407 ----
debug_printf("do_semop : return -EACCES\n");
CYGWIN32_IPCNT_RETURN (-EACCES) ;
}
! shareadrsem->current_nb[id].current_nb[sop->sem_num] +=3D =
sop->sem_op;
sem_deconnect() ;
} else {
! while(sop->sem_op + =
shareadrsem->current_nb[id].current_nb[sop->sem_num] <0)
! LRet =3D WaitForSingleObject(LHandle, INFINITE) ;
! =20
if (sem_connect() =3D=3D 0)
{
debug_printf("do_semop : return -EACCES\n");
CYGWIN32_IPCNT_RETURN (-EACCES) ;
}
! shareadrsem->current_nb[id].current_nb[sop->sem_num] +=3D =
sop->sem_op ;
sem_deconnect() ;
}
}
***************
*** 435,441 ****
char LBuff[100] ;
HANDLE LHandle ;
long LPrevious ;
- int LIndex;
=20
debug_printf("semctl : semid=3D%X semnum=3D%X cmd=3D0x%02X =
arg=3D%p\n",semid,semnum,cmd,arg);
if (semid < 0 || semnum < 0 || cmd < 0)
--- 452,457 ----
***************
*** 568,589 ****
if( LHandle !=3D NULL )
{
if( arg.val > shareadrsem->current_nb[id].current_nb[semnum] )
! {
! ReleaseSemaphore(LHandle,
! arg.val-shareadrsem->current_nb[id].current_nb[semnum],
! &LPrevious) ;
! }
! else if (arg.val <
! shareadrsem->current_nb[id].current_nb[semnum] )
! {
! for( LIndex =3D arg.val;
! LIndex < shareadrsem->current_nb[id].current_nb[semnum];
! LIndex++ )
! {
! WaitForSingleObject(LHandle, 0) ;
! }
! }
! shareadrsem->current_nb[id].current_nb[semnum] =3D =
arg.val ;
}
debug_printf("semctl : SETVAL : return 0\n");
CYGWIN32_IPCNT_RETURN_DECONNECT (0);
--- 584,591 ----
if( LHandle !=3D NULL )
{
if( arg.val > shareadrsem->current_nb[id].current_nb[semnum] )
! ReleaseSemaphore(LHandle,1,&LPrevious) ;
! shareadrsem->current_nb[id].current_nb[semnum] =3D arg.val =
;
}
debug_printf("semctl : SETVAL : return 0\n");
CYGWIN32_IPCNT_RETURN_DECONNECT (0);
*** ./shm.c.orig Fri Sep 17 12:46:24 1999
--- ./shm.c Fri Sep 17 12:47:11 1999
***************
*** 59,64 ****
--- 59,81 ----
static int GFirstShm =3D 0; /*PCPC*/
static int GFdShm ; /*PCPC*/
=20
+ /*****************************************/
+ /* Initialization of static variables */
+ /*****************************************/
+ static pid_t GProcessId =3D 0;
+ static void init_globals(void)
+ {
+ pid_t pid;
+=20
+ if (pid=3Dgetpid(), pid !=3D GProcessId)
+ {
+ GFirstShm =3D 0;
+ shm_rss =3D shm_swp =3D max_shmid =3D 0;
+ shm_seq =3D 0;
+ GProcessId =3D pid;
+ }
+ }
+=20
=
/************************************************************************=
/
/* Demande d'acces a la zone partagee de gestion des shm */
=
/************************************************************************=
/
***************
*** 82,87 ****
--- 99,105 ----
{
int LRet ;
=20
+ init_globals();
if( GFirstShm =3D=3D 0 )
{
if( IsGSemShmExist() )------=_NextPart_000_000F_01BF05F8.E5A09D40
Content-Type: application/octet-stream;
name="readme.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="readme.patch"
LS0tIGRvYy9SRUFETUUuTlQub3JpZwlUaHUgQXVnIDI2IDA5OjIzOjE2IDE5OTkKKysrIGRvYy9S
RUFETUUuTlQJTW9uIEF1ZyAzMCAxNDowODo0MyAxOTk5CkBAIC0yMSw2ICsyMSw3IEBACiAxLiBE
b3dubG9hZCB0aGUgQ3lnd2luMzIgSVBDIFBhY2thZ2UgYnkgTHVkb3ZpYyBMQU5HRSAKICAgIGh0
dHA6Ly93d3cubXVsdGlvbmUuY2FwZ2VtaW5pLmZyOjgwL3Rvb2xzL3BhY2tfaXBjL2N1cnJlbnQu
dGFyLmd6CiAyLiBVbnRhciB0aGUgcGFja2FnZSBhbmQgZm9sbG93IHRoZSByZWFkbWUgaW5zdHJ1
Y3Rpb25zLgorMmEuIEFwcGx5IHRoZSBwYXRjaCBmcm9tIHNyYy93aW4zMi9pcGMucGF0Y2gKIDMu
IEkgdGVzdGVkIDEuMDMuCiA0LiBJIHVzZWQgdGhlIFxjeWd3aW4tYjIwXGgtaTU2OC1jeWd3aW4z
MlxpNTg2LWN5Z3dpbjMyXGxpYiBhbmQKIFxjeWd3aW4tYjIwXGgtaTU2OC1jeWd3aW4zMlxpNTg2
LWN5Z3dpbjMyXGluY2x1ZGVcc3lzIGluc3RlYWQgb2YgdGhlCg==
------=_NextPart_000_000F_01BF05F8.E5A09D40--
From bouncefilter Thu Sep 23 06:35:02 1999
Received: from gate.plzen-city.cz (gate.plzen-city.cz [194.212.191.10])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA05755
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 06:34:12 -0400 (EDT)
(envelope-from horak@mmp.plzen-city.cz)
Received: (from mail@localhost) by gate.plzen-city.cz (8.9.3/8.9.1) id
MAA11183
for <pgsql-hackers@postgreSQL.org>; Thu, 23 Sep 1999 12:34:10 +0200
Received: from EXCHANGE.mmp.plzen-city.cz(s5srvr1.mmp.plzen-city.cz
192.168.51.21) by gate.plzen-city.cz via smap (v1.3-ps12tp)
id sma011169; Thu Sep 23 12:33:40 1999
Received: by exchange.mmp.plzen-city.cz with Internet Mail Service
(5.5.2448.0)
id <TJSAXH2Y>; Thu, 23 Sep 1999 12:33:39 +0200
Message-ID:
<2E7F82FAC1FCD2118E1500A024B3BF907DED84@exchange.mmp.plzen-city.cz>
From: Horak Daniel <horak@mmp.plzen-city.cz>
To: "'Hiroshi Inoue'" <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] IPC on win32 - additions for 6.5.2 and current tree
s
Date: Thu, 23 Sep 1999 12:33:36 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-2"
It's me who made the patch. Yutaka Tanida also provided a patch
for cygipc library to prevent lock freezing by changing the
implementation of semaphore.
These patches are necessary to prevent freezing in cygwin port.If there's no objection,I would add a new ipc.patch provided by
Yutaka into src/win32 and commit the patch for README.NT
for current tree.
I still don't have any reaction from the cygipc author so we should include
the patch into pgsql sources.
Dan
From bouncefilter Thu Sep 23 09:34:54 1999
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 JAA45216
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 09:34:11 -0400 (EDT)
(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 NAA21288;
Thu, 23 Sep 1999 13:32:50 GMT
Sender: lockhart@hub.org
Message-ID: <37EA2C02.C0759C88@alumni.caltech.edu>
Date: Thu, 23 Sep 1999 13:32:50 +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: Adriaan Joubert <a.joubert@albourne.com>,
Bruce Momjian <maillist@candle.pha.pa.us>, Lamar Owen <lamar.owen@wgcr.org>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Operator definitions
References: <2198.938033780@sss.pgh.pa.us> <37E9DA85.F0210261@albourne.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
It looks to me like '^' and '|' have been left out of the alternatives
for MathOp in src/backend/parser/gram.y. It could be they were
deliberately omitted, but I bet it's just an oversight.OK, here is a patch to allow both ^ and | as operators, both in operator
definitions and expressions. It seems to work for me. Unfortunately the
regression tests do not tell me an awful lot, as several of them fail on
the Alpha anyway. As I don;t really know what I'm doing, I'd appreciate
it if somebody else could check the patch out and let me know whether it
is ok.
It's fine as far as it goes, but istm that there are other cases
missing from gram.y also :(
Bruce, how did this stuff get into the stable release? Looks like we
are going to need a v6.5.3 Real Soon Now. And packagers, we should
plan on having a patch for v6.5.2. I'll try coming up with one in the
next couple of days; I've tested on my own gram.y but it has too many
other changes to be used as-is.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Sep 23 09:45:59 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id JAA46673
for <hackers@postgreSQL.org>; Thu, 23 Sep 1999 09:44:55 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m11U94R-0003kLC; Thu, 23 Sep 99 15:37 MET DST
Message-Id: <m11U94R-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Another RI question
To: andreas.zeugswetter@telecom.at (Andreas Zeugswetter)
Date: Thu, 23 Sep 1999 15:37:59 +0200 (MET DST)
Cc: hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37E9F0E6.A88EFB66@telecom.at> from "Andreas Zeugswetter" at Sep
23, 99 11:20:38 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Andreas Zeugswetter wrote:
Is it ALLWAYS the case, that a FK constraint refers to the PK
of another table? Or could arbitraty attributes of another
table be referenced by a FK too?arbitrary (usually unique indexed) columns
NOOOO! It will be too bad if the referenced PK isn't unique
indexed! An ON DELETE CASCADE constraint will fire a trigger
to delete all the rows where FK equals deleted PK. But this
shouldn't happen if PK isn't guaranteed to be unique, instead
it must check if another row with same PK still exists.
And it is absolutely damned for the DELETE,INSERT situation.
How should I be able to see that this happened and suppress
the triggers on DELETE/INSERT though? I think I can't.
Thus, the sequence
BEGIN;
DELETE PK;
INSERT same PK
COMMIT;
where FK's with ON DELETE CASCADE exist will delete them if
the constraint has been set to IMMEDIATE. No chance to
prevent except we add a non-standard feature "NOT
IMMEDIATEABLE" to constraints so these triggers will allways
be fired at transaction commit.
And the INITIAL DEFERRED trigger doing the ON DELETE CASCADE
must check if at the time it's called really no such PK
exists any more. These generic RI-trigger proc's will be
sophisticated, man.
Is it guaranteed that I find the PK definition of a table
allways in the index <tablename>_pkey?No. I think there is a column in pg_index that marks a pk already.
(for odbc) This would imho be the best way.
Ah - yes. It's pg_index.indisprimary - thanks.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Thu Sep 23 10:02:53 1999
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 KAA49700
for <hackers@postgreSQL.org>; Thu, 23 Sep 1999 10:02:21 -0400 (EDT)
(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 NAA21305;
Thu, 23 Sep 1999 13:46:20 GMT
Sender: lockhart@hub.org
Message-ID: <37EA2F2C.162F600E@alumni.caltech.edu>
Date: Thu, 23 Sep 1999 13:46:20 +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: "Grzegorz Prze<dziecki" <grzegorz_przezdziecki@lupus.waw.pl>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] Re Problem with new function
References: <37E9EAE2.A9DC3B9F@lupus.waw.pl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Diference is in line
--SPRAWDZAMY FIRME
What is means this error
Sep 23 11:00:14 Databases logger: FATAL 1: btree: cannot split
if start (2) >= maxoff (2)
I'm guessing that you have exceeded the requirement that a tuple
(index tuples only? but I don't know why this would be indexed) must
fit on half of a page. Try taking out more whitespace (in particular
the large spaced indents), and perhaps you can put the comment back
in.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Sep 23 09:47:57 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA47254
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 09:47:52 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA13212;
Thu, 23 Sep 1999 09:46:49 -0400 (EDT)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?
In-reply-to: Your message of Wed, 22 Sep 1999 21:25:03 -0300 (ADT)
<Pine.BSF.4.10.9909222100560.38923-100000@thelab.hub.org>
Date: Thu, 23 Sep 1999 09:46:48 -0400
Message-ID: <13209.938094408@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Now, something does bother me here, and I'm not sure if its a problem we
need to address, or if its expected, but if I remove the index
aecwebentry_divid, it reverts to using aecwebentry_primary and increases
the query time to 12secs, which is:
create unique index aecWebEntry_primary on aecWebEntry ( indid,divid,catid,id,mid);
Should it do that?
Yeah, that does seem odd. The other way is presumably visiting the
aecwebentry tuples in a different order (the one induced by the other
index), but I don't see why that should produce a 10:1 difference in
runtime.
Can you send me the EXPLAIN VERBOSE output for the query with and
without the extra index? (Preferably the prettyprinted version from
the postmaster log file, not what comes out as a NOTICE...)
Also, I assume you found that merge or hash join wasn't any better?
regards, tom lane
From bouncefilter Thu Sep 23 09:59:05 1999
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 JAA48858
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 09:58:11 -0400 (EDT)
(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 NAA22226;
Thu, 23 Sep 1999 13:57:17 GMT
Sender: lockhart@hub.org
Message-ID: <37EA31BC.A18A31EE@alumni.caltech.edu>
Date: Thu, 23 Sep 1999 13:57:16 +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: Adriaan Joubert <a.joubert@albourne.com>
CC: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <Pine.BSF.4.10.9909220246160.38923-100000@thelab.hub.org>
<37E87542.2F8ADA4A@albourne.com>
<37E8F672.9B98E9BF@alumni.caltech.edu>
<37E9E490.1CD9623B@albourne.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
OK, I'll have a go at this as I get a chance. If somebody has the SQL
standard on line and could send me the appropriate sections I would
appreciate it.
I have a text version of the SQL92 draft standard. Let me know if you
want the whole thing.
As I know very little about the postgres internals I would also
appreciate a short roadmap as to what needs to be done where, i.e. does
the parser need to be changed, and where the files are /new files hsould
go that I need to update. If this is somewhere in the docs please point
me to it.
What I've found upto now is
backend/utils/adt/varlena.c
backend/utils/adt/varchar.c
which I will use as starting point?
That's probably the right place to look. I'll help with the parser
issues; the first thing to do is to figure out the appropriate
behavior and implement the underlying types. Then we can modify the
parser (backend/parser/gram.y) to support SQL92->Postgres internal
type syntax, just as is done for char and numeric types.
I found the file src/backend/lib/bit.c (Bruce's according to the log
message). Has that got anything to do with bit arrays?
Yes it does, but not as a user-accessible type. btw, if you go by the
cvs logs, Bruce owns *every* file in the tree since he does wholesale
reformatting on files; in this case the code has been there since the
beginning.
Looks like it might be a good start at some underlying utilities for
what you want though, and it is OK to reuse them.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Sep 23 10:18:54 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA52431
for <pgsql-hackers@postgresql.org>;
Thu, 23 Sep 1999 10:18:47 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA13253;
Thu, 23 Sep 1999 10:18:02 -0400 (EDT)
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Progress report: buffer refcount bugs and SQL functions
In-reply-to: Your message of Thu, 23 Sep 1999 03:19:39 +0200 (MET DST)
<m11TxXw-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Thu, 23 Sep 1999 10:18:01 -0400
Message-ID: <13251.938096281@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
wieck@debis.com (Jan Wieck) writes:
Tom Lane wrote:
What I am wondering, though, is whether this addition is actually
necessary, or is it a bug that the functions aren't run to completion
in the first place?
I've said some time (maybe too long) ago, that SQL functions
returning tuple sets are broken in general.
Indeed they are. Try this on for size (using the regression database):
SELECT p.name, p.hobbies.equipment.name FROM person p;
SELECT p.hobbies.equipment.name, p.name FROM person p;
You get different result sets!?
The problem in this example is that ExecTargetList returns the isDone
flag from the last targetlist entry, regardless of whether there are
incomplete iterations in previous entries. More generally, the buffer
leak problem that I started with only occurs if some Iter nodes are not
run to completion --- but execQual.c has no mechanism to make sure that
they have all reached completion simultaneously.
What we really need to make functions-returning-sets work properly is
an implementation somewhat like aggregate functions. We need to make
a list of all the Iter nodes present in a targetlist and cycle through
the values returned by each in a methodical fashion (run the rightmost
through its full cycle, then advance the next-to-rightmost one value,
run the rightmost through its cycle again, etc etc). Also there needs
to be an understanding of the hierarchy when an Iter appears in the
arguments of another Iter's function. (You cycle the upper one for
*each* set of arguments created by cycling its sub-Iters.)
I am not particularly interested in working on this feature right now,
since AFAIK it's a Berkeleyism not found in SQL92. What I've done
is to hack ExecTargetList so that it behaves semi-sanely when there's
more than one Iter at the top level of the target list --- it still
doesn't really give the right answer, but at least it will keep
generating tuples until all the Iters are done at the same time.
It happens that that's enough to give correct answers for the examples
shown in the misc regress test. Even when it fails to generate all
the possible combinations, there will be no buffer leaks.
So, I'm going to declare victory and go home ;-). We ought to add a
TODO item along the lines of
* Functions returning sets don't really work right
in hopes that someone will feel like tackling this someday.
regards, tom lane
From bouncefilter Thu Sep 23 10:31:57 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA54605
for <pgsql-hackers@hub.org>; Thu, 23 Sep 1999 10:31:15 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <T2ZVS20Z>; Thu, 23 Sep 1999 16:30:44 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C0C5@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: pgsql-hackers@hub.org
Subject: Lexxing and yaccing...
Date: Thu, 23 Sep 1999 16:25:51 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Hi, all
For those of us who are working on the parser, and compiler, 'A Guide to Lex
& Yacc' by Thomas Niemann should probably be prescribed reading (if you
haven't already read it). This is a really constructive guide to using the
two together, and very informative.
However, the most interesting part that I noticed is on the second page,
under the 'Other Titles' section. It's called 'Operator-Precedence
Parsing'. I haven't yet managed to get to it, because the web server (or my
browser, I'm not sure yet) keeps hooching over the page, however, I'll put
money on the fact that it will provide us with some insight into solving the
current operator problem(s?) that we have (see previous postings titled
'Status Report: long query string changes' and "Postgres' lexer"). I will
try to get it. If anybody wants a copy and is too lazy to go to the web
site, let me know and I'll mail you a copy.
MikeA
From bouncefilter Thu Sep 23 10:42:58 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA56145
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 10:42:05 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA14156;
Thu, 23 Sep 1999 10:40:59 -0400 (EDT)
To: Adriaan Joubert <a.joubert@albourne.com>
cc: Postgresql <pgsql-hackers@postgreSQL.org>,
Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] Operator definitions
In-reply-to: Your message of Thu, 23 Sep 1999 10:45:09 +0300
<37E9DA85.F0210261@albourne.com>
Date: Thu, 23 Sep 1999 10:40:58 -0400
Message-ID: <14154.938097658@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Adriaan Joubert <a.joubert@albourne.com> writes:
OK, here is a patch to allow both ^ and | as operators, both in operator
definitions and expressions. It seems to work for me. Unfortunately the
regression tests do not tell me an awful lot, as several of them fail on
the Alpha anyway. As I don;t really know what I'm doing, I'd appreciate
it if somebody else could check the patch out and let me know whether it
is ok.
If you search for, eg, '%', you will find there are several production
lists that call out all the operators; your patch only caught one of them.
This is a real pain in the neck to maintain, but AFAIK we couldn't
collapse the productions into a single one using MathOp without losing
operator precedence info :-(
It might be helpful if gram.y had annotations like "# Here be MathOps"
so that you could search for the darn things and make sure you had
adjusted each and every production list whenever you added/deleted one.
regards, tom lane
From bouncefilter Thu Sep 23 11:02:56 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA59961
for <pgsql-hackers@postgresql.org>;
Thu, 23 Sep 1999 11:02:33 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id KAA14756;
Thu, 23 Sep 1999 10:42:52 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909231442.KAA14756@candle.pha.pa.us>
Subject: Re: [HACKERS] Compile timing
In-Reply-To: <37E9BCEF.57C8F6A8@alumni.caltech.edu> from Thomas Lockhart at
"Sep 23, 1999 05:38:55 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 23 Sep 1999 10:42:52 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, Lamar Owen <lamar.owen@wgcr.org>,
pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Not sure why -j2 is not faster than normal -j...
I was just looking at this a little while ago at work. It is not
faster because gmake does not propagate the "-j2" flag to submakes, on
the (correct) theory that you might get a geometrically growing system
load, rather than just keeping two makes running through all the
subdirectories.This is the behavior of "-j", unless you specify it without a numeric
parameter, in which case it *does* allow parallel submakes.The first time I tried "-j", I did it without reading the man pages
and without specifying a numeric parameter. It did a magnificent job
of bringing down my system trying to build ACE/TAO, a *large* Corba
package. Chewed up all of real memory, then all of swap; not sure if I
ran out of process slots or memory first but it wasn't pretty. It was
*very* fast though :)
Yes, make -j without a number does so many makes here the compile fails
too, and the load average soars.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Thu Sep 23 10:50:05 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA57351
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 10:49:50 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id KAA16704;
Thu, 23 Sep 1999 10:49:44 -0400
Message-ID: <37EA3E02.5F4F670B@wgcr.org>
Date: Thu, 23 Sep 1999 10:49:38 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: maillist@candle.pha.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Compile timing
References: <m11Twf0-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jan Wieck wrote:
Lamar, shouldn't you run at least the regression suite too
before building the rpm's?
Well, once the compile passes regression on a particular architecture,
IMO it doesn't need to be done for every compile of that version of
PostgreSQL.
However, as part of the testing for the built RPM's, I do run the
regression tests (which I have packaged into the RPM set --
postgresql-test) before releasing. The regression tests don't take too
long (unless I run bigtest).
Running regression as part of the RPM build is a possibility, however.
As it stands, Intel fails two tests (float8 and geometry) and Alpha
fails two tests (geometry and another one that I can't remember right
now) -- one of which is due to the documented problem with sort order on
the Alpha (Uncle George has thoroughly covered that topic, recently).
The RPM building development cycle is a little different than most.
RPM's are built in a fully automatic fashion -- a single command
invocation (rpm -ba postgresql.spec) compiles, mungs, and packages all
the way to the binary RPM's, then it cleans up. Getting to that point,
however, can be a challenge, as some patches are necessary to get a
build in the FHS-compliant RedHat environment. It took me about 2 hours
to get a good build of 6.5.2, due to the need for a couple of Makefile
patches in the perl client (in particular, the src/interfaces Makefile
issues a 'perl5 makefile.pl' command, when there is no executable on
RedHat 6 named perl5), along with some other munging that had to be
done.
I have to think in the mindset of a packager, not a developer, when
doing this -- but I have to also keep up with development in order to
package. And I LOVE it!
So, in short, every binary RPM set I build for RedHat 6 has been
installed on my personal laptop running a close to virgin RedHat 6
installation -- and has had regression run. The set built for RedHat
5.2 has had the same thing done on my inhouse utility machine, which is
a puny little machine (486/100 with 16MB). It takes almost two hours to
build the binary RPM set on that machine. But, then again, that is also
my amanda server and is quite loaded.
Lamar Owen
WGCR Internet Radio
From bouncefilter Thu Sep 23 10:52:12 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA57841
for <hackers@postgreSQL.org>; Thu, 23 Sep 1999 10:51:50 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA14211;
Thu, 23 Sep 1999 10:51:10 -0400 (EDT)
To: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Progress report: buffer refcount bugs and SQL functions
In-reply-to: Your message of Thu, 23 Sep 1999 10:07:24 +0200
<37E9DFBC.5C0978F@telecom.at>
Date: Thu, 23 Sep 1999 10:51:10 -0400
Message-ID: <14209.938098270@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Andreas Zeugswetter <andreas.zeugswetter@telecom.at> writes:
That is what I use it for. I have never used it with a
returns setof function, but reading the comments in the regression test,
-- mike needs advil and peet's coffee,
-- joe and sally need hightops, and
-- everyone else is fine.
it looks like the results you expected are correct, and currently the
wrong result is given.
Yes, I have concluded the same (and partially fixed it, per my previous
message).
Those that don't have a hobbie should return name|NULL|NULL. A hobbie
that does'nt need equipment name|hobbie|NULL.
That's a good point. Currently (both with and without my uncommitted
fix) you get *no* rows out from ExecTargetList if there are any Iters
that return empty result sets. It might be more reasonable to treat an
empty result set as if it were NULL, which would give the behavior you
suggest.
This would be an easy change to my current patch, and I'm prepared to
make it before committing what I have, if people agree that that's a
more reasonable definition. Comments?
regards, tom lane
From bouncefilter Thu Sep 23 10:59:54 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA59110
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 10:59:08 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA14227;
Thu, 23 Sep 1999 10:53:10 -0400 (EDT)
To: Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?=
<grzegorz_przezdziecki@lupus.waw.pl>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Problem with new function
In-reply-to: Your message of Thu, 23 Sep 1999 10:11:55 +0200
<37E9E0CB.C2FFF09B@lupus.waw.pl>
Date: Thu, 23 Sep 1999 10:53:10 -0400
Message-ID: <14225.938098390@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?= <grzegorz_przezdziecki@lupus.waw.pl> writes:
in may log file :
Fatal 1 : btree: cannot split if start (2) >= maxoff (2)
or somethings like this:
fatal 1: my bits moved right off the end of the world!
I think we fixed some bugs in that area in 6.5.2 --- please update
and see if the problem is still there.
Note you will probably need to dump / drop / restore your database
to get that index back into an uncorrupted state :-(
regards, tom lane
From bouncefilter Thu Sep 23 10:58:08 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA58859
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 10:57:04 -0400 (EDT)
(envelope-from a.joubert@albourne.com)
Received: from isadora.cy.albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.6X) with ESMTP
id RAA17202; Thu, 23 Sep 1999 17:59:31 +0300 (EET DST)
Received: from albourne.com (localhost [127.0.0.1])
by isadora.cy.albourne.com (8.9.3/8.9.3/Albourne/CYC/1.4) with ESMTP id
RAA31860; Thu, 23 Sep 1999 17:56:56 +0300 (EET DST)
Sender: a.joubert@albourne.com
Message-ID: <37EA3FB8.95336FAE@albourne.com>
Date: Thu, 23 Sep 1999 17:56:56 +0300
From: Adriaan Joubert <a.joubert@albourne.com>
Organization: APL Financial Services (Overseas) Ltd
X-Mailer: Mozilla 4.61 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Postgresql <pgsql-hackers@postgreSQL.org>,
Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] Operator definitions
References: <14154.938097658@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Adriaan Joubert <a.joubert@albourne.com> writes:
OK, here is a patch to allow both ^ and | as operators, both in operator
definitions and expressions. It seems to work for me. Unfortunately the
regression tests do not tell me an awful lot, as several of them fail on
the Alpha anyway. As I don;t really know what I'm doing, I'd appreciate
it if somebody else could check the patch out and let me know whether it
is ok.If you search for, eg, '%', you will find there are several production
lists that call out all the operators; your patch only caught one of them.
Well, as I said, I don't really understand what is going on in that file
and I added the minimum to make my stuff work. Thomas said he was going
to have a look at it, so I think I'll rely on him fixing it, before I
break anything else ;-).
I've already noticed that I will need | as an operator for the SQL bit
types, so I may have to hack it a bit more. I just hate changing things
blindly I don't really understand. Thanks for pointing it out though!
Adriaan
From bouncefilter Thu Sep 23 11:03:07 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA59798
for <pgsql-hackers@postgresql.org>;
Thu, 23 Sep 1999 11:01:40 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id KAA16017;
Thu, 23 Sep 1999 10:59:12 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909231459.KAA16017@candle.pha.pa.us>
Subject: Re: [HACKERS] Compile timing
In-Reply-To: <37E9BCEF.57C8F6A8@alumni.caltech.edu> from Thomas Lockhart at
"Sep 23, 1999 05:38:55 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 23 Sep 1999 10:59:12 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, Lamar Owen <lamar.owen@wgcr.org>,
pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Not sure why -j2 is not faster than normal -j...
I was just looking at this a little while ago at work. It is not
faster because gmake does not propagate the "-j2" flag to submakes, on
the (correct) theory that you might get a geometrically growing system
load, rather than just keeping two makes running through all the
subdirectories.This is the behavior of "-j", unless you specify it without a numeric
parameter, in which case it *does* allow parallel submakes.The first time I tried "-j", I did it without reading the man pages
and without specifying a numeric parameter. It did a magnificent job
of bringing down my system trying to build ACE/TAO, a *large* Corba
package. Chewed up all of real memory, then all of swap; not sure if I
ran out of process slots or memory first but it wasn't pretty. It was
*very* fast though :)
I just tried:
gmake MAKE="gmake -j 2"
and that fails because we can't parellize because we need certain
includes. I can't seem to get the proper includes to happen before it
fails.
I am getting:
gmake[3]: Entering directory
`/var/local/src/pgsql/CURRENT/pgsql/src/backend/access/common'
gmake[3]: *** No rule to make target `hash/SUBSYS.o'. Stop.
gmake[3]: Leaving directory `/var/local/src/pgsql/CURRENT/pgsql/src/backend/acce
Seems it is trying to complete the linking before the compiles are done.
If I made -j2 happen only in directories with compiles, and not outside,
that might fix it. The propogation of -j2 to subdirectories and the
exponential explosion is exactly what happens.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Thu Sep 23 11:14:57 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id LAA62577
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 11:14:07 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11UASn-0003kLC; Thu, 23 Sep 99 17:07 MET DST
Message-Id: <m11UASn-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: RI and NULL's
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Thu, 23 Sep 1999 17:07:13 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
One more question:
I'm planning to create generic trigger procs for PK/FK stuff.
So that it's simply insert/delete the appropriate pg_trigger
entries during CREATE/ALTER table.
Assuming NULL's are allowed in FK values (are they?), I'd
like to know what the correct handling of NULL values is. If
an attribute of the FK has the NULL value, must a PK with a
NULL in the corresponding attribute exist or is this
attribute completely left out of the WHERE clause in the
check?
Other way round - NULL value in attribute of referenced
table. What to delete from FK in the case of ON DELETE
CASCADE?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Thu Sep 23 11:23:54 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id LAA64746
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 11:23:25 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11UAYh-0003kLC; Thu, 23 Sep 99 17:13 MET DST
Message-Id: <m11UAYh-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Problem with new function
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Thu, 23 Sep 1999 17:13:19 +0200 (MET DST)
Cc: grzegorz_przezdziecki@lupus.waw.pl, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <14225.938098390@sss.pgh.pa.us> from "Tom Lane" at Sep 23,
99 10:53:10 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?= <grzegorz_przezdziecki@lupus.waw.pl> writes:
in may log file :
Fatal 1 : btree: cannot split if start (2) >= maxoff (2)
or somethings like this:
fatal 1: my bits moved right off the end of the world!I think we fixed some bugs in that area in 6.5.2 --- please update
and see if the problem is still there.
The pg_proc_prosrc_index (causing this failure) is still
there. If I remember right, something on SQL functions
requires this index to quickly find a particular function BY
SOURCE. Seems a little screwed up.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Thu Sep 23 11:35:57 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id LAA67641
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 11:35:45 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11UAnj-0003kzC; Thu, 23 Sep 99 17:28 MET DST
Message-Id: <m11UAnj-0003kzC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Progress report: buffer refcount bugs and SQL functions
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Thu, 23 Sep 1999 17:28:51 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <13251.938096281@sss.pgh.pa.us> from "Tom Lane" at Sep 23,
99 10:18:01 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Tom Lane wrote:
wieck@debis.com (Jan Wieck) writes:
Tom Lane wrote:
What we really need to make functions-returning-sets work properly is
an implementation somewhat like aggregate functions. We need to make
a list of all the Iter nodes present in a targetlist and cycle through
the values returned by each in a methodical fashion (run the rightmost
through its full cycle, then advance the next-to-rightmost one value,
run the rightmost through its cycle again, etc etc). Also there needs
to be an understanding of the hierarchy when an Iter appears in the
arguments of another Iter's function. (You cycle the upper one for
*each* set of arguments created by cycling its sub-Iters.)
Shouldn't a function returning a SET of tuples cause a proper
join?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Thu Sep 23 11:38:54 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA68160
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 11:38:10 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id LAA16699;
Thu, 23 Sep 1999 11:31:04 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909231531.LAA16699@candle.pha.pa.us>
Subject: Re: [HACKERS] Progress report: buffer refcount bugs and SQL functions
In-Reply-To: <13251.938096281@sss.pgh.pa.us> from Tom Lane at "Sep 23,
1999 10:18:01 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 23 Sep 1999 11:31:04 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
So, I'm going to declare victory and go home ;-). We ought to add a
TODO item along the lines of
* Functions returning sets don't really work right
in hopes that someone will feel like tackling this someday.
Added to TODO, with your e-mail messages archived:
* Functions returning sets don't really work right(see TODO.detail/functions)
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Thu Sep 23 11:43:57 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA69294
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 11:43:41 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id LAA17066;
Thu, 23 Sep 1999 11:39:18 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909231539.LAA17066@candle.pha.pa.us>
Subject: Re: [HACKERS] Operator definitions
In-Reply-To: <37EA2C02.C0759C88@alumni.caltech.edu> from Thomas Lockhart at
"Sep 23, 1999 01:32:50 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 23 Sep 1999 11:39:18 -0400 (EDT)
CC: Adriaan Joubert <a.joubert@albourne.com>,
Lamar Owen <lamar.owen@wgcr.org>,
Tom Lane <tgl@sss.pgh.pa.us>, Postgresql <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
It looks to me like '^' and '|' have been left out of the alternatives
for MathOp in src/backend/parser/gram.y. It could be they were
deliberately omitted, but I bet it's just an oversight.OK, here is a patch to allow both ^ and | as operators, both in operator
definitions and expressions. It seems to work for me. Unfortunately the
regression tests do not tell me an awful lot, as several of them fail on
the Alpha anyway. As I don;t really know what I'm doing, I'd appreciate
it if somebody else could check the patch out and let me know whether it
is ok.It's fine as far as it goes, but istm that there are other cases
missing from gram.y also :(Bruce, how did this stuff get into the stable release? Looks like we
are going to need a v6.5.3 Real Soon Now. And packagers, we should
plan on having a patch for v6.5.2. I'll try coming up with one in the
next couple of days; I've tested on my own gram.y but it has too many
other changes to be used as-is.
I have no idea how this got in. Looking at the cvs logs, I don't see
anything since 6.5 that would cause this to break in 6.5.2. Even
looking at an actual diff against 6.5.1, I don't see anything.
--
Bruce Momjian | http://www.op.net/~candle
maillist@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 Thu Sep 23 11:59:01 1999
Received: from aurora-borealis.satimex.tvnet.hu
(mail@aurora-borealis.satimex.tvnet.hu [195.38.97.151])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA72221
for <pgsql-hackers@postgresql.org>;
Thu, 23 Sep 1999 11:58:21 -0400 (EDT) (envelope-from infrared@a-b.hu)
Received: from localhost by mail.a-b.hu id 11UB3O-00086Q-00;
Thu, 23 Sep 1999 17:45:02 +0200
Message-ID: <XFMail.990923174501.infrared@a-b.hu>
X-Mailer: XFMail 1.3.1 [p0] on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <123.938012354@sss.pgh.pa.us>
Date: Thu, 23 Sep 1999 17:45:01 +0200 (CEST)
Sender: infrared@a-b.hu
From: InfraRED/Veres Tibor <infrared@a-b.hu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] [GENERAL] when are indexes used?
Cc: pgsql-hackers@postgresql.org
explain select * from auth order by uid;
Sort (cost=2.06 rows=32 width=40)
-> Seq Scan on auth (cost=2.06 rows=32 width=40)With only 32 rows in the table, I suspect the machine is making the
right choices here. (If you actually have more than 32 rows then you
need to vacuum to update the stats...) Index scans are not some sort of
free magic solution; they cost a lot more per row scanned than
sequential scans. They aren't necessarily cheaper than a sequential
scan plus in-memory sort, either.
I did't know about these guesses, and I provided these only for example.. My
real problem is with a ~6000 row database and a select * ... order by query
which takes more than 5 sec. The same query runs for less than 0.1 sec on mssql
:-((
--
InfraRED of aurora-borealis/Veres Tibor
E-Mail: infrared@a-b.hu
From bouncefilter Thu Sep 23 12:20:55 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA77522
for <pgsql-hackers@postgreSQL.org>;
Thu, 23 Sep 1999 12:20:52 -0400 (EDT)
(envelope-from a.joubert@albourne.com)
Received: from isadora.cy.albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.6X) with ESMTP
id TAA17303; Thu, 23 Sep 1999 19:23:24 +0300 (EET DST)
Received: from albourne.com (localhost [127.0.0.1])
by isadora.cy.albourne.com (8.9.3/8.9.3/Albourne/CYC/1.4) with ESMTP id
TAA31883; Thu, 23 Sep 1999 19:20:49 +0300 (EET DST)
Sender: a.joubert@albourne.com
Message-ID: <37EA5361.59EC106D@albourne.com>
Date: Thu, 23 Sep 1999 19:20:49 +0300
From: Adriaan Joubert <a.joubert@albourne.com>
Organization: APL Financial Services (Overseas) Ltd
X-Mailer: Mozilla 4.61 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <Pine.BSF.4.10.9909220246160.38923-100000@thelab.hub.org>
<37E87542.2F8ADA4A@albourne.com>
<37E8F672.9B98E9BF@alumni.caltech.edu>
<37E9E490.1CD9623B@albourne.com>
<37EA31BC.A18A31EE@alumni.caltech.edu>
<37EA3723.B513E03@albourne.com>
<37EA459C.29E2B38D@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas asked how I was going to implement bitstring comparisons.
How do you handle the length and ordering issues? Is x'01' greater
than x'1' since it is longer? And if you have a 16-bit bit column, how
does it look internally if you assign x'01' rather than x'0001'?
I had a look in my freshly down-loaded draft standard. On page 336 it
says:
7) The comparison of two bit string values, X and Y, is
determined
by comparison of their bits with the same ordinal position.
If Xi and Yi are the values of the i-th bits of X and Y,
respectively, and if LX is the length in bits of X and LY is
the length in bits of Y, then:
a) X is equal to Y if and only if X = LY and Xi = Yi for all
i.
? I presume this should be 'LX=LY' ?? Anyway, this means that b'01' <>
b'0010'.
b) X is less than Y if and only if:
i) LX < LY and Xi = Yi for all i less than or equal to LX;
or
ii) Xi = Yi for all i < n and Xn = 0 and Yn = 1 for some n
less
than or equal to the minimum of LX and LY.
b) seems to imply, rather bizarrely in my opinion, that
B'001100' < B'10'
as the second bit in B'10' is 1 and in B'001100' it is 0.
Surely I must be reading this wrong?
On the other hand, this would be a type of lexicographical ordering,
so
perhaps it is not so dumb. Comments?
Adriaan
From bouncefilter Thu Sep 23 12:48:55 1999
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA84364
for <hackers@postgresql.org>; Thu, 23 Sep 1999 12:48:42 -0400 (EDT)
(envelope-from andreas.zeugswetter@telecom.at)
Received: from telecom.at (w0188000580.f000.d0188.sd.spardat.at
[172.18.65.249])
by gandalf.telecom.at (xxx/xxx) with ESMTP id SAA379764;
Thu, 23 Sep 1999 18:47:58 +0200
Message-ID: <37EA59BB.47245CD4@telecom.at>
Date: Thu, 23 Sep 1999 18:47:55 +0200
From: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: infrared@a-b.hu, hackers@postgresql.org
Subject: Re: [HACKERS] [GENERAL] when are indexes used?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
1. run:
vacuum auth;
real problem is with a ~6000 row database and a select * ...
order by query
which takes more than 5 sec. The same query runs for less
than 0.1 sec on mssql
:-((
No way you select 6000 rows in 0.1 sec with mssql,
that would be 60000 rows/sec.
Maybe you mean the first few rows show in 0.1s, this is possible.
In PostgreSQL the order by alone currently does not use the index.
Try:
select * from auth where uid >= 0 order by uid;
if you only have positive uid's. This should use the index.
Andreas
Import Notes
Reply to msg id not found: iso-8859-3Q3C000e01befedd3e2210c0a6373ad140portable3E3B_from_Siso-8859-3QtE9phane_FILLON_on_Wed2C_Sep_152C_1999_at_035009AM_+iso-8859-3Q1100Reference msg id not found: 000e01befedd3e2210c0a6373ad1@portable