createdb -D xxxx not working
This is a transcript of what I am trying:
# setenv PGDATA2 /web/sites/1.192/db-data
# initlocation PGDATA2
initlocation: input argument points to /web/sites/1.192/db-data
We are initializing the database area with username root (uid=0).
This user will own all the files and must also own the server process.
Creating Postgres database system directory /web/sites/1.192/db-data
Creating Postgres database system directory /web/sites/1.192/db-data/base
# createdb -D PGDATA2
ERROR: Unable to locate path 'PGDATA2/root'
This may be due to a missing environment variable in the server
createdb: database creation failed on root.
From bouncefilter Sat Jan 8 01:53:04 2000
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 BAA76582
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 01:52:09 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA14768;
Sat, 8 Jan 2000 01:31:40 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001080631.BAA14768@candle.pha.pa.us>
Subject: Re: [HACKERS] Historical trivia (was Re: First Major Open Source
Database)
In-Reply-To: <5352.947309850@sss.pgh.pa.us> from Tom Lane at "Jan 8,
2000 00:37:30 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 8 Jan 2000 01:31:40 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>, jolly@weblogic.com,
ayu@informix.com
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I am CC'ing Jolly and Andrew on this. They may know the answer.
---------------------------------------------------------------------------
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
It did not use any Ingres code, as told to me by Jolly, I think. My
book has Ingres mentioned as an "ancestor" of Postgres.I suppose we could have figured this out ourselves, since Postgres was
originally written in Lisp, and afaik Ingres was always C or somesuch
traditional compiled-only code. We still see evidence of this in our
code tree with the way lists and parser nodes are handled.It's clear from both the comments and remnants of coding conventions
that the planner/optimizer was originally Lisp code, and was hand-
translated to C at some point in the dim mists of prehistory (early
1990s, possibly ;-)). That Lisp heritage is responsible for some of
the better things about the code, and also some of the worse things.But I'm not sure I believe that *all* of the code was originally
Lisp. I've never heard of a Lisp interface for yacc-generated
parsers, for example. The parts of the executor I've looked at
don't seem nearly as Lispy as the parser/planner/optimizer, either.
So it seems possible that parts of Postgres were written afresh in
Lisp while other parts were lifted from an older C implementation.</idle speculation>
Does anyone here still recall the origins of Postgres? I'm curious
to know more about the history of this beast.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 19026
Chris Griffin <cgriffin@websales.com> writes:
# setenv PGDATA2 /web/sites/1.192/db-data
# initlocation PGDATA2
# createdb -D PGDATA2
Surely you want $PGDATA2 in the latter two lines?
regards, tom lane
From bouncefilter Sat Jan 8 01:59:04 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA77379
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 01:58:52 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id CAA12353
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 02:58:56 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 8 Jan 2000 02:58:56 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Costs: Index vs Non-Index
Message-ID: <Pine.BSF.4.21.0001080254230.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hrmmm...if I'm reading this right, its more costly to create an index then
to leave it as a sequential scan, but it returns more rows? Yet, it
returns, if I do the query with a count() around the return value, 288
rows, not 334 or 1154...
udmsearch=> explain select next_index_time from url where next_index_time <= 947317073;
NOTICE: QUERY PLAN:
Seq Scan on url (cost=43.00 rows=334 width=4)
EXPLAIN
udmsearch=> create index url_next_index_time on url using btree ( next_index_time);
CREATE
udmsearch=> explain select next_index_time from url where next_index_time <= 947317073;
NOTICE: QUERY PLAN:
Index Scan using url_next_index_time on url (cost=271.68 rows=1154 width=4)
EXPLAIN
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sat Jan 8 02:04:06 2000
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA79020
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 02:03:33 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.56]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sat, 8 Jan 2000 01:04:00 -0600
Sender: ed
Message-ID: <3876E186.6ACFB028@austin.rr.com>
Date: Sat, 08 Jan 2000 01:04:38 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pghackers <pgsql-hackers@postgresql.org>
Subject: ERROR: out of free buffers: time to abort !
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This problem was posted 12/24/1999 to GENERAL with no
answer...hoping one of you know the easy answer...
I am seeing the following error during a DB rebuild. It is
occuring during the execution of a PL/pgSQL procedure which is
called from a trigger procedure on an AFTER INSERT trigger...
ERROR: out of free buffers: time to abort !
The insert fails. This is under pgsql 6.5.2, redhat 6.1, built
from tgz, running under "postmaster -i -N 15 -o -F -S 4096"...
Any ideas?
Cheers,
Ed Loehr
From bouncefilter Sat Jan 8 02:14:03 2000
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA83029
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 02:13:47 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.56]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sat, 8 Jan 2000 01:14:14 -0600
Sender: ed
Message-ID: <3876E3EC.AFB8353@austin.rr.com>
Date: Sat, 08 Jan 2000 01:14:52 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pghackers <pgsql-hackers@postgresql.org>
Subject: Re: ERROR: out of free buffers: time to abort !
References: <3876E186.6ACFB028@austin.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I am seeing the following error during a DB rebuild. It is
occuring during the execution of a PL/pgSQL procedure which is
called from a trigger procedure on an AFTER INSERT trigger...ERROR: out of free buffers: time to abort !
The insert fails. This is under pgsql 6.5.2, redhat 6.1, built
from tgz, running under "postmaster -i -N 15 -o -F -S 4096"...Any ideas?
This problem disappears when I up the number of shared mem buffers
with the -B flag from default of 64 to 256.
Cheers,
Ed Loehr
From bouncefilter Sat Jan 8 02:18:03 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA83455
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 02:17:31 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id DAA12640
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 03:17:38 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 8 Jan 2000 03:17:38 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Another index "buglet"?
Message-ID: <Pine.BSF.4.21.0001080311300.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Query is:
SELECT url.status,url2.url,url.url
FROM url,url url2
WHERE url.referrer=url2.rec_id;
There is an index on rec_id and one on referrer ... shouldn't one of the
be used? Like, I can see it having to go through every url2.rec_id, but
shouldn't the url.referrer= be abe to make use of an index? I thought
about changing the above to something like:
explain SELECT url.status,url2.url,url.url
FROM url,url url2
WHERE url.referrer IN ( SELECT rec_id FROM url );
but that didn't win me anything else :)
======
udmsearch=> create index url_rec_id on url using btree ( rec_id );
CREATE
udmsearch=> create index url_referrer on url using btree ( referrer );
CREATE
udmsearch=> explain SELECT url.status,url2.url,url.url FROM url,url url2 WHERE
udmsearch-> url.referrer=url2.rec_id;
NOTICE: QUERY PLAN:
Hash Join (cost=2045.81 rows=4544 width=36)
-> Seq Scan on url (cost=863.95 rows=4544 width=20)
-> Hash (cost=863.95 rows=4544 width=16)
-> Seq Scan on url url2 (cost=863.95 rows=4544 width=16)
EXPLAIN
udmsearch=> \d url
Table = url
+----------------------------------+----------------------------------+-------+
| Field | Type | Length|
+----------------------------------+----------------------------------+-------+
| rec_id | int4 not null default nextval ( | 4 |
| status | int4 not null default 0 | 4 |
| url | varchar() not null | 128 |
| content_type | varchar() not null default '' | 32 |
| last_modified | varchar() not null default '' | 32 |
| title | varchar() not null default '' | 128 |
| txt | varchar() not null default '' | 255 |
| docsize | int4 not null default 0 | 4 |
| last_index_time | int4 not null | 4 |
| next_index_time | int4 not null | 4 |
| referrer | int4 not null default 0 | 4 |
| tag | int4 not null default 0 | 4 |
| hops | int4 not null default 0 | 4 |
| keywords | varchar() not null default '' | 255 |
| description | varchar() not null default '' | 100 |
| crc | varchar() not null default '' | 33 |
+----------------------------------+----------------------------------+-------+
Indices: url_crc
url_pkey
url_rec_id
url_referrer
url_urlMarc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sat Jan 8 08:00:07 2000
Received: from h-62.96.159.35.host.de.colt.net
(root@h-62.96.159.35.host.de.colt.net [62.96.159.35])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA49981
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 07:59:41 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id NAA00493
for pgsql-hackers@postgresql.org; Sat, 8 Jan 2000 13:56:16 +0100
Date: Sat, 8 Jan 2000 13:56:16 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: ECPG patch for exec sql ifdef etc.
Message-ID: <20000108135616.A486@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
I just noticed that this patch added an attribute 'pertinent' to the _defines
structure. However, I cannot find a reference to this attribute anywhere
else. Since this happened before I'm afraid I removed some part of the patch
by committing my own changes I'd like to know what this is supposed to do.
And since I do not know who send the patch I just ask here.
Thanks anyway for this patch.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Sat Jan 8 11:01:09 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA07041;
Sat, 8 Jan 2000 11:00:33 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id KAA53554;
Sat, 8 Jan 2000 10:45:15 -0500 (EST) (envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: "HEALTH&MONEY$!!!" <money1@nemo.bizhosting.com>
X-Newsgroups: comp.databases.postgresql.admin, comp.databases.postgresql.bugs,
comp.databases.postgresql.docs,
comp.databases.postgresql.general,
comp.databases.postgresql.hackers,
comp.databases.postgresql.interfaces,
comp.databases.postgresql.patches, comp.databases.
Subject: MAKE MONEY AT HOME
Date: Sat, 8 Jan 2000 16:17:03 +0100
Organization: Public news server of EUnet Yugoslavia
Lines: 59
Message-ID: <857lgs$d0a$6@SOLAIR2.EUnet.yu>
X-Trace: SOLAIR2.EUnet.yu 947345756 13322 213.240.4.105 (8 Jan 2000 15:35:56
GMT)
X-Complaints-To: abuse@EUnet.yu
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
To:
pgsql-hackers@postgresql.org.pgsql-admin@postgresql.org.pgsql-bugs@postgresql.org.pgsql-docs@postgresql.org.pgsql-general@postgresql.org.pgsql-interfaces@postgresql.org.pgsql-patches@postgresql.org
Get Paid to Surf the Web
Did I tell you about AllAdvantage.com?
http://www.alladvantage.com/go.asp?refid=bil601
Every day, AllAdvantage.com's revolutionary Viewbar? service generates cash
for our members. As of today, we're paying members in the US, UK, Canada,
France, Germany, Australia, New Zealand, and various US Territories to surf
the Web with the Viewbar? service, and we'll keep adding more and more
countries. AllAdvantage.com has made getting paid to surf the Web an
international phenomenon!
Maybe I haven't told you yet, but I get paid to surf the Web.
Really!
I recently joined AllAdvantage.com, a new company that pays
its members to surf the Web - and they've been paying out hundreds of
thousands of dollars
to members since July.
What's the catch? There is no catch. Membership is totally
free and private. To earn money you agree to download a small message
window -- called a
Viewbar - on your desktop. The Viewbar delivers information about products
and
services available online.
AllAdvantage.com is for real:
Their Web site was the 12th most-visited property on the
Web in October. Last month, more than 30 AllAdvantage.com members earned
well over US$1,000 EACH and the top earner pulled in over US$4,400!
The company has more than 3 million members worldwide,
but there are still 75 million active online users (in the US and Canada
alone) who are
still waiting to hear about AllAdvantage.com and become members. Be sure
you're the
first to tell them about it!
The sooner you join, the sooner you'll get paid. Please use my
referral ID number (bil601), because I get paid when you sign up and surf.
Be
sure to tell all your riends who use the Internet -- the more referrals we
get, the more
money we can earn. You can sign up with AllAdvantage.com right away at
http://www.alladvantage.com/go.asp?refid=bil601
This is a really great deal with no strings attached!
Member ID# BIL601
From bouncefilter Sat Jan 8 11:04:09 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA10445
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 11:04:05 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA06057;
Sat, 8 Jan 2000 11:03:59 -0500 (EST)
To: Ed Loehr <eloehr@austin.rr.com>
cc: pghackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: ERROR: out of free buffers: time to abort !
In-reply-to: <3876E3EC.AFB8353@austin.rr.com>
References: <3876E186.6ACFB028@austin.rr.com> <3876E3EC.AFB8353@austin.rr.com>
Comments: In-reply-to Ed Loehr <eloehr@austin.rr.com>
message dated "Sat, 08 Jan 2000 01:14:52 -0600"
Date: Sat, 08 Jan 2000 11:03:59 -0500
Message-ID: <6054.947347439@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Ed Loehr <eloehr@austin.rr.com> writes:
I am seeing the following error during a DB rebuild. It is
occuring during the execution of a PL/pgSQL procedure which is
called from a trigger procedure on an AFTER INSERT trigger...ERROR: out of free buffers: time to abort !
The insert fails. This is under pgsql 6.5.2, redhat 6.1, built
from tgz, running under "postmaster -i -N 15 -o -F -S 4096"...
This problem disappears when I up the number of shared mem buffers
with the -B flag from default of 64 to 256.
That's the message you get if all the disk buffers are marked as
"in use" (ref count > 0) so that there is noplace to read in another
database page. I fixed several nasty buffer-ref-count-leakage bugs
a couple of months ago, so I think this problem may be gone in current
sources. (I'd appreciate it if you'd try this test case as soon as
we are ready for 7.0 beta...)
In the meantime, upping the number of buffers will at least postpone the
problem. But I'm worried that it may not solve it completely --- you
may still find that the error occurs after you've been running long
enough.
regards, tom lane
From bouncefilter Sat Jan 8 11:11:10 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA11133;
Sat, 8 Jan 2000 11:10:33 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA00441;
Sat, 8 Jan 2000 11:10:01 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001081610.LAA00441@candle.pha.pa.us>
Subject: Re: [HACKERS] ECPG patch for exec sql ifdef etc.
In-Reply-To: <20000108135616.A486@fam-meskes.de> from Michael Meskes at "Jan
8, 2000 01:56:16 pm"
To: Michael Meskes <meskes@postgresql.org>
Date: Sat, 8 Jan 2000 11:10:01 -0500 (EST)
CC: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I just noticed that this patch added an attribute 'pertinent' to the _defines
structure. However, I cannot find a reference to this attribute anywhere
else. Since this happened before I'm afraid I removed some part of the patch
by committing my own changes I'd like to know what this is supposed to do.And since I do not know who send the patch I just ask here.
Thanks anyway for this patch.
OK, 1.19 version of type.h shows this, and the diff is attached too.
---------------------------------------------------------------------------
revision 1.19
date: 1999/12/21 17:42:16; author: momjian; state: Exp; lines: +1 -0
The first fix is to allow an input file with a relative path and without
a ".pgc " extension. The second patch fixes a coredump when there is
more than one input file (in that case, cur and types were not set to
NULL before processing the second f ile)
The patch below modifies the accepted grammar of ecpg to accept
FETCH [direction] [amount] cursor name
i.e. the IN|FROM clause becomes optional (as in Oracle and Informix).
This removes the incompatibility mentioned in section "Porting From
Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar
is modified in such a way as to avoid shift/reduce conflicts. It does
not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar
did (this seems to be a bug of the old grammar anyway).
This patch cleans up the handling of space characters in the scanner;
some patte rns require \n to be in {space}, some do not. A second fix is
the handling of cpp continuati on lines; the old pattern did not match
these. The parser is patched to fix an off-by-one error in the #line
directives. The pa rser is also enhanced to report the correct location
of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally,
some right recursions in the parser were replaced by left-recursions.
This patch adds preprocessor directives to ecpg; in particular
EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF
"EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and
defines, specified on the command line with -D. Defines, specified on
the command line are persistent across multiple input files. Defines can
be nested up to a maximum level of 128 (see patch). There is a fair
amount of error checking to make sure directives are matched properly. I
need preprocessor directives for porting code, that is written for an
Informix database, to a PostgreSQL database, while maintaining
compatibility with the original code. I decided not to extend the
already large ecpg grammar. Everything is done in the scanner by adding
some states, e.g. to skip all input except newlines and directives. The
preprocessor commands are compatible with Informix. Oracle uses a cpp
replacement.
Rene Hogendoorn
---------------------------------------------------------------------------
and the diff shows:
$ pgcvs diff -c -r 1.18 -r 1.19 type.h|less
Index: type.h
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/type.h,v
retrieving revision 1.18
retrieving revision 1.19
diff -c -r1.18 -r1.19
*** type.h 1999/05/25 16:15:04 1.18
--- type.h 1999/12/21 17:42:16 1.19
***************
*** 119,124 ****
--- 119,125 ----
{
char *old;
char *new;
+ int pertinent;
struct _defines *next;
};--
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 Jan 8 11:16:09 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA11584
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 11:15:19 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA06115;
Sat, 8 Jan 2000 11:15:16 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Costs: Index vs Non-Index
In-reply-to: <Pine.BSF.4.21.0001080254230.18498-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001080254230.18498-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Sat, 08 Jan 2000 02:58:56 -0400"
Date: Sat, 08 Jan 2000 11:15:16 -0500
Message-ID: <6112.947348116@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Hrmmm...if I'm reading this right, its more costly to create an index then
to leave it as a sequential scan, but it returns more rows? Yet, it
returns, if I do the query with a count() around the return value, 288
rows, not 334 or 1154...
This doesn't have anything to do with index vs sequential scan, but it
does have to do with whether you've done a VACUUM ANALYZE lately.
You haven't ;-)
udmsearch=> explain select next_index_time from url where next_index_time <= 947317073;
NOTICE: QUERY PLAN:
Seq Scan on url (cost=43.00 rows=334 width=4)
IIRC, rows=334 is the default estimate of result rows you will get for
this query in the absence of any information whatever. (Default table
size guess is 1000 rows, and default selectivity guess for <= is 1/3,
so...) If you have not vacuumed, it's sheer coincidence that this is
even within hailing distance of the correct figure of 288.
udmsearch=> create index url_next_index_time on url using btree ( next_index_time);
CREATE
udmsearch=> explain select next_index_time from url where next_index_time <= 947317073;
NOTICE: QUERY PLAN:
Index Scan using url_next_index_time on url (cost=271.68 rows=1154 width=4)
I believe that a side-effect of CREATE INDEX is to update the
number-of-pages-and-rows statistics in pg_class for the target table.
So after you do that, the optimizer has a correct idea of the table's
size, but still no more info about the selectivity of the WHERE clause.
(I infer that your table has size 1154*3 rows.) If you now drop the
index and repeat EXPLAIN, it'll go back to a seq scan, but it will now
say 1154 rows --- and the cost estimate will be higher, too.
If you do VACUUM ANALYZE, then the optimizer will also know the min and
max values of next_index_time, and will have some shot at making a
correct estimate of the output row count. I'd be interested to know
what it predicts then...
regards, tom lane
From bouncefilter Sat Jan 8 11:24:09 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA18542
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 11:23:20 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA06174;
Sat, 8 Jan 2000 11:23:17 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another index "buglet"?
In-reply-to: <Pine.BSF.4.21.0001080311300.18498-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001080311300.18498-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Sat, 08 Jan 2000 03:17:38 -0400"
Date: Sat, 08 Jan 2000 11:23:17 -0500
Message-ID: <6171.947348597@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
SELECT url.status,url2.url,url.url
FROM url,url url2
WHERE url.referrer=url2.rec_id;
There is an index on rec_id and one on referrer ... shouldn't one of the
be used?
Not necessarily --- hash join is a perfectly respectable alternative
choice. I'd expect to see either a hash or a merge join here (the
merge *would* use both indexes).
Now it could be that the optimizer is misestimating the relative costs
of merge and hash join. If you're interested in checking that, do
this (*after* running VACUUM ANALYZE, ahem):
1. Start psql with environment variable PGOPTIONS="-fh" (forbid hash).
Do the EXPLAIN --- it'll probably give a mergejoin plan now. Note
the estimated total cost. Run the query itself, and note the runtime.
2. Start psql with environment variable PGOPTIONS="-fm" (forbid merge),
and repeat the experiment to get the estimated cost and actual time
for the hash join.
I'd be interested to know what you find out. I'm in the middle of
rejiggering the optimizer's cost estimates right now, so more data
points would be helpful.
regards, tom lane
From bouncefilter Sat Jan 8 13:29:14 2000
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA40365
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 13:28:36 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.56]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sat, 8 Jan 2000 12:29:04 -0600
Sender: ed
Message-ID: <38778214.E8D8F2B5@austin.rr.com>
Date: Sat, 08 Jan 2000 12:29:40 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pghackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: ERROR: out of free buffers: time to abort !
References: <3876E186.6ACFB028@austin.rr.com> <3876E3EC.AFB8353@austin.rr.com>
<6054.947347439@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
I am seeing the following error during a DB rebuild.
ERROR: out of free buffers: time to abort !
This problem disappears when I up the number of shared mem buffers
with the -B flag from default of 64 to 256.That's the message you get if all the disk buffers are marked as
"in use" (ref count > 0) so that there is noplace to read in another
database page. I fixed several nasty buffer-ref-count-leakage bugs
a couple of months ago, so I think this problem may be gone in current
sources. (I'd appreciate it if you'd try this test case as soon as
we are ready for 7.0 beta...)
Great. Thanks again, Tom.
In the meantime, upping the number of buffers will at least postpone the
problem. But I'm worried that it may not solve it completely --- you
may still find that the error occurs after you've been running long
enough.
Can I postpone/workaround the problem by periodic server restarts to reset
the counts? Or is this a persistent thing across server restarts?
Cheers,
Ed Loehr
From bouncefilter Sat Jan 8 14:00:10 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA46414
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 14:00:08 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id OAA19208;
Sat, 8 Jan 2000 14:58:54 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 8 Jan 2000 14:58:54 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Costs: Index vs Non-Index
In-Reply-To: <6112.947348116@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001081457420.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Okay, I had remembered to VACUUM, but I always forget to VACUUM ANALYZE :(
results come out much better now:
udmsearch=> explain select next_index_time from url where next_index_time <= 947317073;
NOTICE: QUERY PLAN:
Seq Scan on url (cost=3368.58 rows=12623 width=4)
EXPLAIN
udmsearch=> select (next_index_time) from url where next_index_time <= 947317073;
next_index_time
---------------
(0 rows)
udmsearch=> create index url_next_index_time on url using btree ( next_index_time);
CREATE
udmsearch=> explain select next_index_time from url where next_index_time <= 947317073;
NOTICE: QUERY PLAN:
Index Scan using url_next_index_time on url (cost=1364.10 rows=12623 width=4)
EXPLAIN
On Sat, 8 Jan 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Hrmmm...if I'm reading this right, its more costly to create an index then
to leave it as a sequential scan, but it returns more rows? Yet, it
returns, if I do the query with a count() around the return value, 288
rows, not 334 or 1154...This doesn't have anything to do with index vs sequential scan, but it
does have to do with whether you've done a VACUUM ANALYZE lately.
You haven't ;-)udmsearch=> explain select next_index_time from url where next_index_time <= 947317073;
NOTICE: QUERY PLAN:
Seq Scan on url (cost=43.00 rows=334 width=4)IIRC, rows=334 is the default estimate of result rows you will get for
this query in the absence of any information whatever. (Default table
size guess is 1000 rows, and default selectivity guess for <= is 1/3,
so...) If you have not vacuumed, it's sheer coincidence that this is
even within hailing distance of the correct figure of 288.udmsearch=> create index url_next_index_time on url using btree ( next_index_time);
CREATE
udmsearch=> explain select next_index_time from url where next_index_time <= 947317073;
NOTICE: QUERY PLAN:
Index Scan using url_next_index_time on url (cost=271.68 rows=1154 width=4)I believe that a side-effect of CREATE INDEX is to update the
number-of-pages-and-rows statistics in pg_class for the target table.
So after you do that, the optimizer has a correct idea of the table's
size, but still no more info about the selectivity of the WHERE clause.
(I infer that your table has size 1154*3 rows.) If you now drop the
index and repeat EXPLAIN, it'll go back to a seq scan, but it will now
say 1154 rows --- and the cost estimate will be higher, too.If you do VACUUM ANALYZE, then the optimizer will also know the min and
max values of next_index_time, and will have some shot at making a
correct estimate of the output row count. I'd be interested to know
what it predicts then...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 Jan 8 14:06:10 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA50038
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 14:05:28 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA19251;
Sat, 8 Jan 2000 15:05:13 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 8 Jan 2000 15:05:12 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another index "buglet"?
In-Reply-To: <6171.947348597@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001081500330.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
After the VACUUM ANALYZE:
Straight start up:
Hash Join (cost=9994.31 rows=2740488 width=36)
-> Seq Scan on url (cost=3368.58 rows=37866 width=20)
-> Hash (cost=3368.58 rows=37866 width=16)
-> Seq Scan on url url2 (cost=3368.58 rows=37866 width=16)
788u 0.327s 0:03.89 28.2% 104+14868k 0+179io 0pf+0w
Forbid merge:
Hash Join (cost=9994.31 rows=2740488 width=36)
-> Seq Scan on url (cost=3368.58 rows=37866 width=20)
-> Hash (cost=3368.58 rows=37866 width=16)
-> Seq Scan on url url2 (cost=3368.58 rows=37866 width=16)
0.900u 0.217s 0:04.19 26.4% 103+14638k 0+175io 0pf+0w
Forbid Hash:
Merge Join (cost=11188.76 rows=2740488 width=36)
-> Index Scan using url_pkey on url url2 (cost=4347.30 rows=37866 width=16)
-> Index Scan using url_referrer on url (cost=4342.30 rows=37866 width=20)
0.897u 0.210s 0:03.19 34.4% 106+15120k 0+179io 0pf+0w
On Sat, 8 Jan 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
SELECT url.status,url2.url,url.url
FROM url,url url2
WHERE url.referrer=url2.rec_id;There is an index on rec_id and one on referrer ... shouldn't one of the
be used?Not necessarily --- hash join is a perfectly respectable alternative
choice. I'd expect to see either a hash or a merge join here (the
merge *would* use both indexes).Now it could be that the optimizer is misestimating the relative costs
of merge and hash join. If you're interested in checking that, do
this (*after* running VACUUM ANALYZE, ahem):1. Start psql with environment variable PGOPTIONS="-fh" (forbid hash).
Do the EXPLAIN --- it'll probably give a mergejoin plan now. Note
the estimated total cost. Run the query itself, and note the runtime.2. Start psql with environment variable PGOPTIONS="-fm" (forbid merge),
and repeat the experiment to get the estimated cost and actual time
for the hash join.I'd be interested to know what you find out. I'm in the middle of
rejiggering the optimizer's cost estimates right now, so more data
points would be helpful.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 Jan 8 15:08:11 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA61176
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 15:07:45 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id PAA03286;
Sat, 8 Jan 2000 15:07:35 -0500 (EST)
To: Ed Loehr <eloehr@austin.rr.com>
cc: pghackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: ERROR: out of free buffers: time to abort !
In-reply-to: <38778214.E8D8F2B5@austin.rr.com>
References: <3876E186.6ACFB028@austin.rr.com> <3876E3EC.AFB8353@austin.rr.com>
<6054.947347439@sss.pgh.pa.us> <38778214.E8D8F2B5@austin.rr.com>
Comments: In-reply-to Ed Loehr <eloehr@austin.rr.com>
message dated "Sat, 08 Jan 2000 12:29:40 -0600"
Date: Sat, 08 Jan 2000 15:07:35 -0500
Message-ID: <3283.947362055@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Ed Loehr <eloehr@austin.rr.com> writes:
In the meantime, upping the number of buffers will at least postpone the
problem. But I'm worried that it may not solve it completely --- you
may still find that the error occurs after you've been running long
enough.
Can I postpone/workaround the problem by periodic server restarts to reset
the counts? Or is this a persistent thing across server restarts?
Yes, a postmaster restart would clean up the buffer reference counts.
I think there were also some less drastic code paths that would clean
them up --- you might try something as simple as deliberately inducing
an SQL error now and then, so that error cleanup runs.
regards, tom lane
From bouncefilter Sat Jan 8 15:14:11 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA61746
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 15:13:36 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id PAA03313;
Sat, 8 Jan 2000 15:13:33 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another index "buglet"?
In-reply-to: <Pine.BSF.4.21.0001081500330.18498-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001081500330.18498-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Sat, 08 Jan 2000 15:05:12 -0400"
Date: Sat, 08 Jan 2000 15:13:33 -0500
Message-ID: <3310.947362413@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Forbid merge:
Hash Join (cost=9994.31 rows=2740488 width=36)
-> Seq Scan on url (cost=3368.58 rows=37866 width=20)
-> Hash (cost=3368.58 rows=37866 width=16)
-> Seq Scan on url url2 (cost=3368.58 rows=37866 width=16)
0.900u 0.217s 0:04.19 26.4% 103+14638k 0+175io 0pf+0w
Forbid Hash:
Merge Join (cost=11188.76 rows=2740488 width=36)
-> Index Scan using url_pkey on url url2 (cost=4347.30 rows=37866 width=16)
-> Index Scan using url_referrer on url (cost=4342.30 rows=37866 width=20)
0.897u 0.210s 0:03.19 34.4% 106+15120k 0+179io 0pf+0w
Thanks, but I'm confused about what I'm looking at here. Are those
time outputs for the backend, or for psql?
Also, how large are these two tables, and how many rows do you actually
get from the query?
regards, tom lane
From bouncefilter Sat Jan 8 15:46:14 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA67565
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 15:45:16 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA19804;
Sat, 8 Jan 2000 16:45:23 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 8 Jan 2000 16:45:23 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Another index "buglet"?
In-Reply-To: <3310.947362413@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001081643030.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 8 Jan 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Forbid merge:
Hash Join (cost=9994.31 rows=2740488 width=36)
-> Seq Scan on url (cost=3368.58 rows=37866 width=20)
-> Hash (cost=3368.58 rows=37866 width=16)
-> Seq Scan on url url2 (cost=3368.58 rows=37866 width=16)0.900u 0.217s 0:04.19 26.4% 103+14638k 0+175io 0pf+0w
Forbid Hash:
Merge Join (cost=11188.76 rows=2740488 width=36)
-> Index Scan using url_pkey on url url2 (cost=4347.30 rows=37866 width=16)
-> Index Scan using url_referrer on url (cost=4342.30 rows=37866 width=20)0.897u 0.210s 0:03.19 34.4% 106+15120k 0+179io 0pf+0w
Thanks, but I'm confused about what I'm looking at here. Are those
time outputs for the backend, or for psql?
just from psql ...
Also, how large are these two tables, and how many rows do you actually
get from the query?
pgsql> grep http query.out | wc -l
37825
Can't give you a count on the tables though, since I've since had to
rebuiild them :( Or, rather, the two tables are the same table...
From bouncefilter Sat Jan 8 16:16:15 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA73091
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 16:15:47 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA19941
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 17:15:57 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 8 Jan 2000 17:15:57 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: LIBPQ patches ...
Message-ID: <Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Does anyone have anything against me applying this to the current source
tree?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
---------- Forwarded message ----------
Date: Fri, 17 Dec 1999 13:51:50 -0800 (PST)
From: Alfred Perlstein <bright@wintelcom.net>
To: The Hermit Hacker <scrappy@hub.org>
Subject: Re: pctrackd updates and such
On Fri, 17 Dec 1999, The Hermit Hacker wrote:
Okay, first thing...can you redo these as context diffs? We generally
refuse *any* patches that aren't context...
sure.
Second, are these against a reasonably current snapshot of PostgreSQL
(aka. the upcoming v7), or v6.5.3 release? If v6.5.3, we're gonna need to
get these v7.x ready before we can commit them...
they are against a checked out cvs copy as of a couple days ago,
and should apply cleanly to what's in the current repo.
Once both of the above conditions are in place, and after I get back from
BC, I'll work on getting these into the v7.0 release...or, at least,
talked/commented about if there are any objections...I'm outta here for 10 days...Happy Holidays and talk with ya when I get
back...
ok, cool see you soon. :)
-Alfred
don't forget the problem with sending queries that may occur:
i'm not sure if handlesendfailure() can cope with only sending
a 'Q' to the backend, we may have to work out reservations or
something for space, another idea would be to implement a
pqWritev() of some sort that would take an array of pointers
and lengths to send to the backend and only allow any data to
go into the backend if the entire string can fit.
then again, handlesendfailure may work, but doing reservations
for the send buffer seems cleaner...
diff's contexted against pgsql-'current':
Index: fe-connect.c
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.108
diff -u -c -r1.108 fe-connect.c
cvs diff: conflicting specifications of output style
*** fe-connect.c 1999/12/02 00:26:15 1.108
--- fe-connect.c 1999/12/14 09:42:24
***************
*** 595,625 ****
return 0;
}-
- /* ----------
- * connectMakeNonblocking -
- * Make a connection non-blocking.
- * Returns 1 if successful, 0 if not.
- * ----------
- */
- static int
- connectMakeNonblocking(PGconn *conn)
- {
- #ifndef WIN32
- if (fcntl(conn->sock, F_SETFL, O_NONBLOCK) < 0)
- #else
- if (ioctlsocket(conn->sock, FIONBIO, &on) != 0)
- #endif
- {
- printfPQExpBuffer(&conn->errorMessage,
- "connectMakeNonblocking -- fcntl() failed: errno=%d\n%s\n",
- errno, strerror(errno));
- return 0;
- }
-
- return 1;
- }
-
/* ----------
* connectNoDelay -
* Sets the TCP_NODELAY socket option.
--- 595,600 ----
***************
*** 792,798 ****
* Ewan Mellor <eem21@cam.ac.uk>.
* ---------- */
#if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL)
! if (!connectMakeNonblocking(conn))
goto connect_errReturn;
#endif --- 767,773 ----
* Ewan Mellor <eem21@cam.ac.uk>.
* ---------- */
#if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL)
! if (PQsetnonblocking(conn, TRUE) != 0)
goto connect_errReturn;
#endif ***************
*** 904,910 ****
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (!connectMakeNonblocking(conn))
goto connect_errReturn;
#endif
--- 879,885 ----
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (PQsetnonblocking(conn, TRUE) != 0)
goto connect_errReturn;
#endif ***************
*** 1702,1707 ****
--- 1677,1683 ----
conn->inBuffer = (char *) malloc(conn->inBufSize);
conn->outBufSize = 8 * 1024;
conn->outBuffer = (char *) malloc(conn->outBufSize);
+ conn->nonblocking = FALSE;
initPQExpBuffer(&conn->errorMessage);
initPQExpBuffer(&conn->workBuffer);
if (conn->inBuffer == NULL ||
***************
*** 1811,1816 ****
--- 1787,1793 ----
conn->lobjfuncs = NULL;
conn->inStart = conn->inCursor = conn->inEnd = 0;
conn->outCount = 0;
+ conn->nonblocking = FALSE;}
Index: fe-exec.c
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-exec.c,v
retrieving revision 1.86
diff -u -c -r1.86 fe-exec.c
cvs diff: conflicting specifications of output style
*** fe-exec.c 1999/11/11 00:10:14 1.86
--- fe-exec.c 1999/12/14 05:55:11
***************
*** 13,18 ****
--- 13,19 ----
*/
#include <errno.h>
#include <ctype.h>
+ #include <fcntl.h> #include "postgres.h"
#include "libpq-fe.h"
***************
*** 24,30 ****
#include <unistd.h>
#endif
-
/* keep this in same order as ExecStatusType in libpq-fe.h */
const char *const pgresStatus[] = {
"PGRES_EMPTY_QUERY",
--- 25,30 ----
***************
*** 574,580 ****
--- 574,588 ----
* we will NOT block waiting for more input.
*/
if (pqReadData(conn) < 0)
+ {
+ /*
+ * try to flush the send-queue otherwise we may never get a
+ * resonce for something that may not have already been sent
+ * because it's in our write buffer!
+ */
+ pqFlush(conn);
return 0;
+ }
/* Parsing of the data waits till later. */
return 1;
}
***************
*** 1088,1095 ****
--- 1096,1112 ----
{
PGresult *result;
PGresult *lastResult;
+ bool savedblocking; /*
+ * we assume anyone calling PQexec wants blocking behaviour,
+ * we force the blocking status of the connection to blocking
+ * for the duration of this function and restore it on return
+ */
+ savedblocking = PQisnonblocking(conn);
+ PQsetnonblocking(conn, FALSE);
+
+ /*
* Silently discard any prior query result that application didn't
* eat. This is probably poor design, but it's here for backward
* compatibility.
***************
*** 1102,1115 ****
PQclear(result);
printfPQExpBuffer(&conn->errorMessage,
"PQexec: you gotta get out of a COPY state yourself.\n");
! return NULL;
}
PQclear(result);
} /* OK to send the message */
if (!PQsendQuery(conn, query))
! return NULL;
/*
* For backwards compatibility, return the last result if there are
--- 1119,1133 ----
PQclear(result);
printfPQExpBuffer(&conn->errorMessage,
"PQexec: you gotta get out of a COPY state yourself.\n");
! /* restore blocking status */
! goto errout;
}
PQclear(result);
} /* OK to send the message */
if (!PQsendQuery(conn, query))
! goto errout;
/*
* For backwards compatibility, return the last result if there are
***************
*** 1142,1148 ****
--- 1160,1172 ----
result->resultStatus == PGRES_COPY_OUT)
break;
}
+
+ PQsetnonblocking(conn, savedblocking);
return lastResult;
+
+ errout:
+ PQsetnonblocking(conn, savedblocking);
+ return NULL;
}***************
*** 1431,1438 ****
"PQendcopy() -- I don't think there's a copy in progress.\n");
return 1;
}
! (void) pqFlush(conn); /* make sure no data is waiting to be sent */
/* Return to active duty */
conn->asyncStatus = PGASYNC_BUSY;
--- 1455,1468 ----
"PQendcopy() -- I don't think there's a copy in progress.\n");
return 1;
}
+
+ /* make sure no data is waiting to be sent */
+ if (pqFlush(conn))
+ return (1);! /* non blocking connections may have to abort at this point. */
! if (PQisnonblocking(conn) && PQisBusy(conn))
! return (1);
/* Return to active duty */
conn->asyncStatus = PGASYNC_BUSY;
***************
*** 2025,2028 ****
--- 2055,2126 ----
return 1;
else
return 0;
+ }
+
+ /* PQsetnonblocking:
+ sets the PGconn's database connection non-blocking if the arg is TRUE
+ or makes it non-blocking if the arg is FALSE, this will not protect
+ you from PQexec(), you'll only be safe when using the non-blocking
+ API
+ Needs to be called only on a connected database connection.
+ */
+
+ int
+ PQsetnonblocking(PGconn *conn, int arg)
+ {
+ int fcntlarg;
+
+ arg = (arg == TRUE) ? 1 : 0;
+ if (arg == conn->nonblocking)
+ return (0);
+
+ #ifdef USE_SSL
+ if (conn->ssl)
+ {
+ printfPQExpBuffer(&conn->errorMessage,
+ "PQsetnonblocking() -- not supported when using SSL\n");
+ return (-1);
+ }
+ #endif /* USE_SSL */
+
+ #ifndef WIN32
+ fcntlarg = fcntl(conn->sock, F_GETFL, 0);
+ if (fcntlarg == -1)
+ return (-1);
+
+ if ((arg == TRUE &&
+ fcntl(conn->sock, F_SETFL, fcntlarg | O_NONBLOCK) == -1) ||
+ (arg == FALSE &&
+ fcntl(conn->sock, F_SETFL, fcntlarg & ~O_NONBLOCK) == -1))
+ #else
+ fcntlarg = arg;
+ if (ioctlsocket(conn->sock, FIONBIO, &fcntlarg) != 0)
+ #endif
+ {
+ printfPQExpBuffer(&conn->errorMessage,
+ "PQsetblocking() -- unable to set nonblocking status to %s\n",
+ arg == TRUE ? "TRUE" : "FALSE");
+ return (-1);
+ }
+
+ conn->nonblocking = arg;
+ return (0);
+ }
+
+ /* return the blocking status of the database connection, TRUE == nonblocking,
+ FALSE == blocking
+ */
+ int
+ PQisnonblocking(PGconn *conn)
+ {
+
+ return (conn->nonblocking);
+ }
+
+ /* try to force data out, really only useful for non-blocking users */
+ int
+ PQflush(PGconn *conn)
+ {
+
+ return (pqFlush(conn));
}
Index: fe-misc.c
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-misc.c,v
retrieving revision 1.33
diff -u -c -r1.33 fe-misc.c
cvs diff: conflicting specifications of output style
*** fe-misc.c 1999/11/30 03:08:19 1.33
--- fe-misc.c 1999/12/14 08:21:09
***************
*** 86,91 ****
--- 86,119 ----
{
size_t avail = Max(conn->outBufSize - conn->outCount, 0);+ /*
+ * if we are non-blocking and the send queue is too full to buffer this
+ * request then try to flush some and return an error
+ */
+ if (PQisnonblocking(conn) && nbytes > avail && pqFlush(conn))
+ {
+ /*
+ * even if the flush failed we may still have written some
+ * data, recalculate the size of the send-queue relative
+ * to the amount we have to send, we may be able to queue it
+ * afterall even though it's not sent to the database it's
+ * ok, any routines that check the data coming from the
+ * database better call pqFlush() anyway.
+ */
+ if (nbytes > Max(conn->outBufSize - conn->outCount, 0))
+ {
+ printfPQExpBuffer(&conn->errorMessage,
+ "pqPutBytes -- pqFlush couldn't flush enough"
+ " data: space available: %d, space needed %d\n",
+ Max(conn->outBufSize - conn->outCount, 0), nbytes);
+ return EOF;
+ }
+ }
+
+ /*
+ * the non-blocking code above makes sure that this isn't true,
+ * essentially this is no-op
+ */
while (nbytes > avail)
{
memcpy(conn->outBuffer + conn->outCount, s, avail);
***************
*** 548,553 ****
--- 576,589 ----
return EOF;
}+ /*
+ * don't try to send zero data, allows us to use this function
+ * without too much worry about overhead
+ */
+ if (len == 0)
+ return (0);
+
+ /* while there's still data to send */
while (len > 0)
{
/* Prevent being SIGPIPEd if backend has closed the connection. */
***************
*** 556,561 ****
--- 592,598 ----
#endif int sent;
+
#ifdef USE_SSL
if (conn->ssl)
sent = SSL_write(conn->ssl, ptr, len);
***************
*** 585,590 ****
--- 622,629 ----
case EWOULDBLOCK:
break;
#endif
+ case EINTR:
+ continue; case EPIPE:
#ifdef ECONNRESET
***************
*** 616,628 ****
ptr += sent;
len -= sent;
}
if (len > 0)
{
/* We didn't send it all, wait till we can send more */
- /* At first glance this looks as though it should block. I think
- * that it will be OK though, as long as the socket is
- * non-blocking. */
if (pqWait(FALSE, TRUE, conn))
return EOF;
}
--- 655,685 ----
ptr += sent;
len -= sent;
}
+
if (len > 0)
{
/* We didn't send it all, wait till we can send more */
+
+ /*
+ * if the socket is in non-blocking mode we may need
+ * to abort here
+ */
+ #ifdef USE_SSL
+ /* can't do anything for our SSL users yet */
+ if (conn->ssl == NULL)
+ {
+ #endif
+ if (PQisnonblocking(conn))
+ {
+ /* shift the contents of the buffer */
+ memmove(conn->outBuffer, ptr, len);
+ conn->outCount = len;
+ return EOF;
+ }
+ #ifdef USE_SSL
+ }
+ #endif if (pqWait(FALSE, TRUE, conn))
return EOF;
}
Index: libpq-fe.h
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-fe.h,v
retrieving revision 1.53
diff -u -c -r1.53 libpq-fe.h
cvs diff: conflicting specifications of output style
*** libpq-fe.h 1999/11/30 03:08:19 1.53
--- libpq-fe.h 1999/12/14 01:30:01
***************
*** 269,274 ****
--- 269,281 ----
extern int PQputnbytes(PGconn *conn, const char *buffer, int nbytes);
extern int PQendcopy(PGconn *conn);+ /* Set blocking/nonblocking connection to the backend */
+ extern int PQsetnonblocking(PGconn *conn, int arg);
+ extern int PQisnonblocking(PGconn *conn);
+
+ /* Force the write buffer to be written (or at least try) */
+ extern int PQflush(PGconn *conn);
+
/*
* "Fast path" interface --- not really recommended for application
* use
Index: libpq-int.h
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-int.h,v
retrieving revision 1.14
diff -u -c -r1.14 libpq-int.h
cvs diff: conflicting specifications of output style
*** libpq-int.h 1999/11/30 03:08:19 1.14
--- libpq-int.h 1999/12/14 01:30:01
***************
*** 215,220 ****
--- 215,223 ----
int inEnd; /* offset to first position after avail
* data */+ int nonblocking; /* whether this connection is using a blocking
+ * socket to the backend or not */
+
/* Buffer for data not yet sent to backend */
char *outBuffer; /* currently allocated buffer */
int outBufSize; /* allocated size of buffer */From bouncefilter Sat Jan 8 16:29:12 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA74281
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 16:28:34 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA14420;
Sat, 8 Jan 2000 16:27:49 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001082127.QAA14420@candle.pha.pa.us>
Subject: Re: [HACKERS] LIBPQ patches ...
In-Reply-To: <Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 8, 2000 05:15:57 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Sat, 8 Jan 2000 16:27:49 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Looks fine. I have talked to someone about doing no-blocking
connections in the past. Maybe this the same person.
I will let someone else comment on whether the protocol changes are
correct.
Does anyone have anything against me applying this to the current source
tree?Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org---------- Forwarded message ----------
Date: Fri, 17 Dec 1999 13:51:50 -0800 (PST)
From: Alfred Perlstein <bright@wintelcom.net>
To: The Hermit Hacker <scrappy@hub.org>
Subject: Re: pctrackd updates and suchOn Fri, 17 Dec 1999, The Hermit Hacker wrote:
Okay, first thing...can you redo these as context diffs? We generally
refuse *any* patches that aren't context...sure.
Second, are these against a reasonably current snapshot of PostgreSQL
(aka. the upcoming v7), or v6.5.3 release? If v6.5.3, we're gonna need to
get these v7.x ready before we can commit them...they are against a checked out cvs copy as of a couple days ago,
and should apply cleanly to what's in the current repo.Once both of the above conditions are in place, and after I get back from
BC, I'll work on getting these into the v7.0 release...or, at least,
talked/commented about if there are any objections...I'm outta here for 10 days...Happy Holidays and talk with ya when I get
back...ok, cool see you soon. :)
-Alfred
don't forget the problem with sending queries that may occur:
i'm not sure if handlesendfailure() can cope with only sending
a 'Q' to the backend, we may have to work out reservations or
something for space, another idea would be to implement a
pqWritev() of some sort that would take an array of pointers
and lengths to send to the backend and only allow any data to
go into the backend if the entire string can fit.then again, handlesendfailure may work, but doing reservations
for the send buffer seems cleaner...diff's contexted against pgsql-'current':
Index: fe-connect.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-connect.c,v retrieving revision 1.108 diff -u -c -r1.108 fe-connect.c cvs diff: conflicting specifications of output style *** fe-connect.c 1999/12/02 00:26:15 1.108 --- fe-connect.c 1999/12/14 09:42:24 *************** *** 595,625 **** return 0; }- - /* ---------- - * connectMakeNonblocking - - * Make a connection non-blocking. - * Returns 1 if successful, 0 if not. - * ---------- - */ - static int - connectMakeNonblocking(PGconn *conn) - { - #ifndef WIN32 - if (fcntl(conn->sock, F_SETFL, O_NONBLOCK) < 0) - #else - if (ioctlsocket(conn->sock, FIONBIO, &on) != 0) - #endif - { - printfPQExpBuffer(&conn->errorMessage, - "connectMakeNonblocking -- fcntl() failed: errno=%d\n%s\n", - errno, strerror(errno)); - return 0; - } - - return 1; - } - /* ---------- * connectNoDelay - * Sets the TCP_NODELAY socket option. --- 595,600 ---- *************** *** 792,798 **** * Ewan Mellor <eem21@cam.ac.uk>. * ---------- */ #if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL) ! if (!connectMakeNonblocking(conn)) goto connect_errReturn; #endif--- 767,773 ---- * Ewan Mellor <eem21@cam.ac.uk>. * ---------- */ #if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL) ! if (PQsetnonblocking(conn, TRUE) != 0) goto connect_errReturn; #endif***************
*** 904,910 ****
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (!connectMakeNonblocking(conn))
goto connect_errReturn;
#endif--- 879,885 ---- /* This makes the connection non-blocking, for all those cases which forced us not to do it above. */ #if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL) ! if (PQsetnonblocking(conn, TRUE) != 0) goto connect_errReturn; #endif*************** *** 1702,1707 **** --- 1677,1683 ---- conn->inBuffer = (char *) malloc(conn->inBufSize); conn->outBufSize = 8 * 1024; conn->outBuffer = (char *) malloc(conn->outBufSize); + conn->nonblocking = FALSE; initPQExpBuffer(&conn->errorMessage); initPQExpBuffer(&conn->workBuffer); if (conn->inBuffer == NULL || *************** *** 1811,1816 **** --- 1787,1793 ---- conn->lobjfuncs = NULL; conn->inStart = conn->inCursor = conn->inEnd = 0; conn->outCount = 0; + conn->nonblocking = FALSE;}
Index: fe-exec.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-exec.c,v retrieving revision 1.86 diff -u -c -r1.86 fe-exec.c cvs diff: conflicting specifications of output style *** fe-exec.c 1999/11/11 00:10:14 1.86 --- fe-exec.c 1999/12/14 05:55:11 *************** *** 13,18 **** --- 13,19 ---- */ #include <errno.h> #include <ctype.h> + #include <fcntl.h>#include "postgres.h"
#include "libpq-fe.h"
***************
*** 24,30 ****
#include <unistd.h>
#endif- /* keep this in same order as ExecStatusType in libpq-fe.h */ const char *const pgresStatus[] = { "PGRES_EMPTY_QUERY", --- 25,30 ---- *************** *** 574,580 **** --- 574,588 ---- * we will NOT block waiting for more input. */ if (pqReadData(conn) < 0) + { + /* + * try to flush the send-queue otherwise we may never get a + * resonce for something that may not have already been sent + * because it's in our write buffer! + */ + pqFlush(conn); return 0; + } /* Parsing of the data waits till later. */ return 1; } *************** *** 1088,1095 **** --- 1096,1112 ---- { PGresult *result; PGresult *lastResult; + bool savedblocking;/* + * we assume anyone calling PQexec wants blocking behaviour, + * we force the blocking status of the connection to blocking + * for the duration of this function and restore it on return + */ + savedblocking = PQisnonblocking(conn); + PQsetnonblocking(conn, FALSE); + + /* * Silently discard any prior query result that application didn't * eat. This is probably poor design, but it's here for backward * compatibility. *************** *** 1102,1115 **** PQclear(result); printfPQExpBuffer(&conn->errorMessage, "PQexec: you gotta get out of a COPY state yourself.\n"); ! return NULL; } PQclear(result); }/* OK to send the message */
if (!PQsendQuery(conn, query))
! return NULL;/* * For backwards compatibility, return the last result if there are --- 1119,1133 ---- PQclear(result); printfPQExpBuffer(&conn->errorMessage, "PQexec: you gotta get out of a COPY state yourself.\n"); ! /* restore blocking status */ ! goto errout; } PQclear(result); }/* OK to send the message */
if (!PQsendQuery(conn, query))
! goto errout;/* * For backwards compatibility, return the last result if there are *************** *** 1142,1148 **** --- 1160,1172 ---- result->resultStatus == PGRES_COPY_OUT) break; } + + PQsetnonblocking(conn, savedblocking); return lastResult; + + errout: + PQsetnonblocking(conn, savedblocking); + return NULL; }***************
*** 1431,1438 ****
"PQendcopy() -- I don't think there's a copy in progress.\n");
return 1;
}! (void) pqFlush(conn); /* make sure no data is waiting to be sent */
/* Return to active duty */ conn->asyncStatus = PGASYNC_BUSY; --- 1455,1468 ---- "PQendcopy() -- I don't think there's a copy in progress.\n"); return 1; } + + /* make sure no data is waiting to be sent */ + if (pqFlush(conn)) + return (1);! /* non blocking connections may have to abort at this point. */
! if (PQisnonblocking(conn) && PQisBusy(conn))
! return (1);/* Return to active duty */ conn->asyncStatus = PGASYNC_BUSY; *************** *** 2025,2028 **** --- 2055,2126 ---- return 1; else return 0; + } + + /* PQsetnonblocking: + sets the PGconn's database connection non-blocking if the arg is TRUE + or makes it non-blocking if the arg is FALSE, this will not protect + you from PQexec(), you'll only be safe when using the non-blocking + API + Needs to be called only on a connected database connection. + */ + + int + PQsetnonblocking(PGconn *conn, int arg) + { + int fcntlarg; + + arg = (arg == TRUE) ? 1 : 0; + if (arg == conn->nonblocking) + return (0); + + #ifdef USE_SSL + if (conn->ssl) + { + printfPQExpBuffer(&conn->errorMessage, + "PQsetnonblocking() -- not supported when using SSL\n"); + return (-1); + } + #endif /* USE_SSL */ + + #ifndef WIN32 + fcntlarg = fcntl(conn->sock, F_GETFL, 0); + if (fcntlarg == -1) + return (-1); + + if ((arg == TRUE && + fcntl(conn->sock, F_SETFL, fcntlarg | O_NONBLOCK) == -1) || + (arg == FALSE && + fcntl(conn->sock, F_SETFL, fcntlarg & ~O_NONBLOCK) == -1)) + #else + fcntlarg = arg; + if (ioctlsocket(conn->sock, FIONBIO, &fcntlarg) != 0) + #endif + { + printfPQExpBuffer(&conn->errorMessage, + "PQsetblocking() -- unable to set nonblocking status to %s\n", + arg == TRUE ? "TRUE" : "FALSE"); + return (-1); + } + + conn->nonblocking = arg; + return (0); + } + + /* return the blocking status of the database connection, TRUE == nonblocking, + FALSE == blocking + */ + int + PQisnonblocking(PGconn *conn) + { + + return (conn->nonblocking); + } + + /* try to force data out, really only useful for non-blocking users */ + int + PQflush(PGconn *conn) + { + + return (pqFlush(conn)); } Index: fe-misc.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-misc.c,v retrieving revision 1.33 diff -u -c -r1.33 fe-misc.c cvs diff: conflicting specifications of output style *** fe-misc.c 1999/11/30 03:08:19 1.33 --- fe-misc.c 1999/12/14 08:21:09 *************** *** 86,91 **** --- 86,119 ---- { size_t avail = Max(conn->outBufSize - conn->outCount, 0);+ /* + * if we are non-blocking and the send queue is too full to buffer this + * request then try to flush some and return an error + */ + if (PQisnonblocking(conn) && nbytes > avail && pqFlush(conn)) + { + /* + * even if the flush failed we may still have written some + * data, recalculate the size of the send-queue relative + * to the amount we have to send, we may be able to queue it + * afterall even though it's not sent to the database it's + * ok, any routines that check the data coming from the + * database better call pqFlush() anyway. + */ + if (nbytes > Max(conn->outBufSize - conn->outCount, 0)) + { + printfPQExpBuffer(&conn->errorMessage, + "pqPutBytes -- pqFlush couldn't flush enough" + " data: space available: %d, space needed %d\n", + Max(conn->outBufSize - conn->outCount, 0), nbytes); + return EOF; + } + } + + /* + * the non-blocking code above makes sure that this isn't true, + * essentially this is no-op + */ while (nbytes > avail) { memcpy(conn->outBuffer + conn->outCount, s, avail); *************** *** 548,553 **** --- 576,589 ---- return EOF; }+ /* + * don't try to send zero data, allows us to use this function + * without too much worry about overhead + */ + if (len == 0) + return (0); + + /* while there's still data to send */ while (len > 0) { /* Prevent being SIGPIPEd if backend has closed the connection. */ *************** *** 556,561 **** --- 592,598 ---- #endifint sent; + #ifdef USE_SSL if (conn->ssl) sent = SSL_write(conn->ssl, ptr, len); *************** *** 585,590 **** --- 622,629 ---- case EWOULDBLOCK: break; #endif + case EINTR: + continue;case EPIPE:
#ifdef ECONNRESET
***************
*** 616,628 ****
ptr += sent;
len -= sent;
}
if (len > 0)
{
/* We didn't send it all, wait till we can send more */- /* At first glance this looks as though it should block. I think - * that it will be OK though, as long as the socket is - * non-blocking. */ if (pqWait(FALSE, TRUE, conn)) return EOF; } --- 655,685 ---- ptr += sent; len -= sent; } + if (len > 0) { /* We didn't send it all, wait till we can send more */ + + /* + * if the socket is in non-blocking mode we may need + * to abort here + */ + #ifdef USE_SSL + /* can't do anything for our SSL users yet */ + if (conn->ssl == NULL) + { + #endif + if (PQisnonblocking(conn)) + { + /* shift the contents of the buffer */ + memmove(conn->outBuffer, ptr, len); + conn->outCount = len; + return EOF; + } + #ifdef USE_SSL + } + #endifif (pqWait(FALSE, TRUE, conn)) return EOF; } Index: libpq-fe.h =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-fe.h,v retrieving revision 1.53 diff -u -c -r1.53 libpq-fe.h cvs diff: conflicting specifications of output style *** libpq-fe.h 1999/11/30 03:08:19 1.53 --- libpq-fe.h 1999/12/14 01:30:01 *************** *** 269,274 **** --- 269,281 ---- extern int PQputnbytes(PGconn *conn, const char *buffer, int nbytes); extern int PQendcopy(PGconn *conn);+ /* Set blocking/nonblocking connection to the backend */ + extern int PQsetnonblocking(PGconn *conn, int arg); + extern int PQisnonblocking(PGconn *conn); + + /* Force the write buffer to be written (or at least try) */ + extern int PQflush(PGconn *conn); + /* * "Fast path" interface --- not really recommended for application * use Index: libpq-int.h =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-int.h,v retrieving revision 1.14 diff -u -c -r1.14 libpq-int.h cvs diff: conflicting specifications of output style *** libpq-int.h 1999/11/30 03:08:19 1.14 --- libpq-int.h 1999/12/14 01:30:01 *************** *** 215,220 **** --- 215,223 ---- int inEnd; /* offset to first position after avail * data */+ int nonblocking; /* whether this connection is using a blocking + * socket to the backend or not */ + /* Buffer for data not yet sent to backend */ char *outBuffer; /* currently allocated buffer */ int outBufSize; /* allocated size of buffer */************
--
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 Jan 8 16:54:14 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA79463
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 16:53:51 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA20125;
Sat, 8 Jan 2000 17:53:39 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 8 Jan 2000 17:53:39 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Alfred Perlstein <pc-team@wintelcom.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] LIBPQ patches ...
In-Reply-To: <200001082127.QAA14420@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001081752460.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 8 Jan 2000, Bruce Momjian wrote:
Looks fine. I have talked to someone about doing no-blocking
connections in the past. Maybe this the same person.I will let someone else comment on whether the protocol changes are
correct.
Okay, if I haven't heard anything major by Sunday, I'm going to include
these, whic still gives us a month before beta (well, not quite, but
close) and then the beta period in order to clean it up...
Does anyone have anything against me applying this to the current source
tree?Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org---------- Forwarded message ----------
Date: Fri, 17 Dec 1999 13:51:50 -0800 (PST)
From: Alfred Perlstein <bright@wintelcom.net>
To: The Hermit Hacker <scrappy@hub.org>
Subject: Re: pctrackd updates and suchOn Fri, 17 Dec 1999, The Hermit Hacker wrote:
Okay, first thing...can you redo these as context diffs? We generally
refuse *any* patches that aren't context...sure.
Second, are these against a reasonably current snapshot of PostgreSQL
(aka. the upcoming v7), or v6.5.3 release? If v6.5.3, we're gonna need to
get these v7.x ready before we can commit them...they are against a checked out cvs copy as of a couple days ago,
and should apply cleanly to what's in the current repo.Once both of the above conditions are in place, and after I get back from
BC, I'll work on getting these into the v7.0 release...or, at least,
talked/commented about if there are any objections...I'm outta here for 10 days...Happy Holidays and talk with ya when I get
back...ok, cool see you soon. :)
-Alfred
don't forget the problem with sending queries that may occur:
i'm not sure if handlesendfailure() can cope with only sending
a 'Q' to the backend, we may have to work out reservations or
something for space, another idea would be to implement a
pqWritev() of some sort that would take an array of pointers
and lengths to send to the backend and only allow any data to
go into the backend if the entire string can fit.then again, handlesendfailure may work, but doing reservations
for the send buffer seems cleaner...diff's contexted against pgsql-'current':
Index: fe-connect.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-connect.c,v retrieving revision 1.108 diff -u -c -r1.108 fe-connect.c cvs diff: conflicting specifications of output style *** fe-connect.c 1999/12/02 00:26:15 1.108 --- fe-connect.c 1999/12/14 09:42:24 *************** *** 595,625 **** return 0; }- - /* ---------- - * connectMakeNonblocking - - * Make a connection non-blocking. - * Returns 1 if successful, 0 if not. - * ---------- - */ - static int - connectMakeNonblocking(PGconn *conn) - { - #ifndef WIN32 - if (fcntl(conn->sock, F_SETFL, O_NONBLOCK) < 0) - #else - if (ioctlsocket(conn->sock, FIONBIO, &on) != 0) - #endif - { - printfPQExpBuffer(&conn->errorMessage, - "connectMakeNonblocking -- fcntl() failed: errno=%d\n%s\n", - errno, strerror(errno)); - return 0; - } - - return 1; - } - /* ---------- * connectNoDelay - * Sets the TCP_NODELAY socket option. --- 595,600 ---- *************** *** 792,798 **** * Ewan Mellor <eem21@cam.ac.uk>. * ---------- */ #if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL) ! if (!connectMakeNonblocking(conn)) goto connect_errReturn; #endif--- 767,773 ---- * Ewan Mellor <eem21@cam.ac.uk>. * ---------- */ #if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL) ! if (PQsetnonblocking(conn, TRUE) != 0) goto connect_errReturn; #endif***************
*** 904,910 ****
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (!connectMakeNonblocking(conn))
goto connect_errReturn;
#endif--- 879,885 ---- /* This makes the connection non-blocking, for all those cases which forced us not to do it above. */ #if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL) ! if (PQsetnonblocking(conn, TRUE) != 0) goto connect_errReturn; #endif*************** *** 1702,1707 **** --- 1677,1683 ---- conn->inBuffer = (char *) malloc(conn->inBufSize); conn->outBufSize = 8 * 1024; conn->outBuffer = (char *) malloc(conn->outBufSize); + conn->nonblocking = FALSE; initPQExpBuffer(&conn->errorMessage); initPQExpBuffer(&conn->workBuffer); if (conn->inBuffer == NULL || *************** *** 1811,1816 **** --- 1787,1793 ---- conn->lobjfuncs = NULL; conn->inStart = conn->inCursor = conn->inEnd = 0; conn->outCount = 0; + conn->nonblocking = FALSE;}
Index: fe-exec.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-exec.c,v retrieving revision 1.86 diff -u -c -r1.86 fe-exec.c cvs diff: conflicting specifications of output style *** fe-exec.c 1999/11/11 00:10:14 1.86 --- fe-exec.c 1999/12/14 05:55:11 *************** *** 13,18 **** --- 13,19 ---- */ #include <errno.h> #include <ctype.h> + #include <fcntl.h>#include "postgres.h"
#include "libpq-fe.h"
***************
*** 24,30 ****
#include <unistd.h>
#endif- /* keep this in same order as ExecStatusType in libpq-fe.h */ const char *const pgresStatus[] = { "PGRES_EMPTY_QUERY", --- 25,30 ---- *************** *** 574,580 **** --- 574,588 ---- * we will NOT block waiting for more input. */ if (pqReadData(conn) < 0) + { + /* + * try to flush the send-queue otherwise we may never get a + * resonce for something that may not have already been sent + * because it's in our write buffer! + */ + pqFlush(conn); return 0; + } /* Parsing of the data waits till later. */ return 1; } *************** *** 1088,1095 **** --- 1096,1112 ---- { PGresult *result; PGresult *lastResult; + bool savedblocking;/* + * we assume anyone calling PQexec wants blocking behaviour, + * we force the blocking status of the connection to blocking + * for the duration of this function and restore it on return + */ + savedblocking = PQisnonblocking(conn); + PQsetnonblocking(conn, FALSE); + + /* * Silently discard any prior query result that application didn't * eat. This is probably poor design, but it's here for backward * compatibility. *************** *** 1102,1115 **** PQclear(result); printfPQExpBuffer(&conn->errorMessage, "PQexec: you gotta get out of a COPY state yourself.\n"); ! return NULL; } PQclear(result); }/* OK to send the message */
if (!PQsendQuery(conn, query))
! return NULL;/* * For backwards compatibility, return the last result if there are --- 1119,1133 ---- PQclear(result); printfPQExpBuffer(&conn->errorMessage, "PQexec: you gotta get out of a COPY state yourself.\n"); ! /* restore blocking status */ ! goto errout; } PQclear(result); }/* OK to send the message */
if (!PQsendQuery(conn, query))
! goto errout;/* * For backwards compatibility, return the last result if there are *************** *** 1142,1148 **** --- 1160,1172 ---- result->resultStatus == PGRES_COPY_OUT) break; } + + PQsetnonblocking(conn, savedblocking); return lastResult; + + errout: + PQsetnonblocking(conn, savedblocking); + return NULL; }***************
*** 1431,1438 ****
"PQendcopy() -- I don't think there's a copy in progress.\n");
return 1;
}! (void) pqFlush(conn); /* make sure no data is waiting to be sent */
/* Return to active duty */ conn->asyncStatus = PGASYNC_BUSY; --- 1455,1468 ---- "PQendcopy() -- I don't think there's a copy in progress.\n"); return 1; } + + /* make sure no data is waiting to be sent */ + if (pqFlush(conn)) + return (1);! /* non blocking connections may have to abort at this point. */
! if (PQisnonblocking(conn) && PQisBusy(conn))
! return (1);/* Return to active duty */ conn->asyncStatus = PGASYNC_BUSY; *************** *** 2025,2028 **** --- 2055,2126 ---- return 1; else return 0; + } + + /* PQsetnonblocking: + sets the PGconn's database connection non-blocking if the arg is TRUE + or makes it non-blocking if the arg is FALSE, this will not protect + you from PQexec(), you'll only be safe when using the non-blocking + API + Needs to be called only on a connected database connection. + */ + + int + PQsetnonblocking(PGconn *conn, int arg) + { + int fcntlarg; + + arg = (arg == TRUE) ? 1 : 0; + if (arg == conn->nonblocking) + return (0); + + #ifdef USE_SSL + if (conn->ssl) + { + printfPQExpBuffer(&conn->errorMessage, + "PQsetnonblocking() -- not supported when using SSL\n"); + return (-1); + } + #endif /* USE_SSL */ + + #ifndef WIN32 + fcntlarg = fcntl(conn->sock, F_GETFL, 0); + if (fcntlarg == -1) + return (-1); + + if ((arg == TRUE && + fcntl(conn->sock, F_SETFL, fcntlarg | O_NONBLOCK) == -1) || + (arg == FALSE && + fcntl(conn->sock, F_SETFL, fcntlarg & ~O_NONBLOCK) == -1)) + #else + fcntlarg = arg; + if (ioctlsocket(conn->sock, FIONBIO, &fcntlarg) != 0) + #endif + { + printfPQExpBuffer(&conn->errorMessage, + "PQsetblocking() -- unable to set nonblocking status to %s\n", + arg == TRUE ? "TRUE" : "FALSE"); + return (-1); + } + + conn->nonblocking = arg; + return (0); + } + + /* return the blocking status of the database connection, TRUE == nonblocking, + FALSE == blocking + */ + int + PQisnonblocking(PGconn *conn) + { + + return (conn->nonblocking); + } + + /* try to force data out, really only useful for non-blocking users */ + int + PQflush(PGconn *conn) + { + + return (pqFlush(conn)); } Index: fe-misc.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-misc.c,v retrieving revision 1.33 diff -u -c -r1.33 fe-misc.c cvs diff: conflicting specifications of output style *** fe-misc.c 1999/11/30 03:08:19 1.33 --- fe-misc.c 1999/12/14 08:21:09 *************** *** 86,91 **** --- 86,119 ---- { size_t avail = Max(conn->outBufSize - conn->outCount, 0);+ /* + * if we are non-blocking and the send queue is too full to buffer this + * request then try to flush some and return an error + */ + if (PQisnonblocking(conn) && nbytes > avail && pqFlush(conn)) + { + /* + * even if the flush failed we may still have written some + * data, recalculate the size of the send-queue relative + * to the amount we have to send, we may be able to queue it + * afterall even though it's not sent to the database it's + * ok, any routines that check the data coming from the + * database better call pqFlush() anyway. + */ + if (nbytes > Max(conn->outBufSize - conn->outCount, 0)) + { + printfPQExpBuffer(&conn->errorMessage, + "pqPutBytes -- pqFlush couldn't flush enough" + " data: space available: %d, space needed %d\n", + Max(conn->outBufSize - conn->outCount, 0), nbytes); + return EOF; + } + } + + /* + * the non-blocking code above makes sure that this isn't true, + * essentially this is no-op + */ while (nbytes > avail) { memcpy(conn->outBuffer + conn->outCount, s, avail); *************** *** 548,553 **** --- 576,589 ---- return EOF; }+ /* + * don't try to send zero data, allows us to use this function + * without too much worry about overhead + */ + if (len == 0) + return (0); + + /* while there's still data to send */ while (len > 0) { /* Prevent being SIGPIPEd if backend has closed the connection. */ *************** *** 556,561 **** --- 592,598 ---- #endifint sent; + #ifdef USE_SSL if (conn->ssl) sent = SSL_write(conn->ssl, ptr, len); *************** *** 585,590 **** --- 622,629 ---- case EWOULDBLOCK: break; #endif + case EINTR: + continue;case EPIPE:
#ifdef ECONNRESET
***************
*** 616,628 ****
ptr += sent;
len -= sent;
}
if (len > 0)
{
/* We didn't send it all, wait till we can send more */- /* At first glance this looks as though it should block. I think - * that it will be OK though, as long as the socket is - * non-blocking. */ if (pqWait(FALSE, TRUE, conn)) return EOF; } --- 655,685 ---- ptr += sent; len -= sent; } + if (len > 0) { /* We didn't send it all, wait till we can send more */ + + /* + * if the socket is in non-blocking mode we may need + * to abort here + */ + #ifdef USE_SSL + /* can't do anything for our SSL users yet */ + if (conn->ssl == NULL) + { + #endif + if (PQisnonblocking(conn)) + { + /* shift the contents of the buffer */ + memmove(conn->outBuffer, ptr, len); + conn->outCount = len; + return EOF; + } + #ifdef USE_SSL + } + #endifif (pqWait(FALSE, TRUE, conn)) return EOF; } Index: libpq-fe.h =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-fe.h,v retrieving revision 1.53 diff -u -c -r1.53 libpq-fe.h cvs diff: conflicting specifications of output style *** libpq-fe.h 1999/11/30 03:08:19 1.53 --- libpq-fe.h 1999/12/14 01:30:01 *************** *** 269,274 **** --- 269,281 ---- extern int PQputnbytes(PGconn *conn, const char *buffer, int nbytes); extern int PQendcopy(PGconn *conn);+ /* Set blocking/nonblocking connection to the backend */ + extern int PQsetnonblocking(PGconn *conn, int arg); + extern int PQisnonblocking(PGconn *conn); + + /* Force the write buffer to be written (or at least try) */ + extern int PQflush(PGconn *conn); + /* * "Fast path" interface --- not really recommended for application * use Index: libpq-int.h =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-int.h,v retrieving revision 1.14 diff -u -c -r1.14 libpq-int.h cvs diff: conflicting specifications of output style *** libpq-int.h 1999/11/30 03:08:19 1.14 --- libpq-int.h 1999/12/14 01:30:01 *************** *** 215,220 **** --- 215,223 ---- int inEnd; /* offset to first position after avail * data */+ int nonblocking; /* whether this connection is using a blocking + * socket to the backend or not */ + /* Buffer for data not yet sent to backend */ char *outBuffer; /* currently allocated buffer */ int outBufSize; /* allocated size of buffer */************
-- 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 Sat Jan 8 17:27:15 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA85449
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 17:27:06 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA09128;
Sat, 8 Jan 2000 17:27:02 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] LIBPQ patches ...
In-reply-to: <Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Sat, 08 Jan 2000 17:15:57 -0400"
Date: Sat, 08 Jan 2000 17:27:02 -0500
Message-ID: <9125.947370422@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Does anyone have anything against me applying this to the current source
tree?
I'm not particularly comfortable with it --- it looks like the semantics
need more careful thought, particularly concerning when the output buffer
gets flushed and what happens if we can't send data right away. The
insertion of a pqFlush into PQconsumeInput, in particular, looks like
an ill-thought-out hack that could break some applications.
I also object strongly to the lack of documentation. Patches that
change public APIs and come without doco updates should be rejected
out of hand, IMNSHO. Keeping the documentation up to date should
not be considered optional --- especially not when you're talking
about something that makes subtle and pervasive changes to library
behavior.
regards, tom lane
From bouncefilter Sat Jan 8 17:27:16 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA85373
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 17:26:16 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.206]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sat, 8 Jan 2000 16:17:16 -0600
Sender: ed
Message-ID: <3877B9E9.63E8C129@austin.rr.com>
Date: Sat, 08 Jan 2000 16:27:53 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pghackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: ERROR: out of free buffers: time to abort !
References: <3876E186.6ACFB028@austin.rr.com> <3876E3EC.AFB8353@austin.rr.com>
<6054.947347439@sss.pgh.pa.us> <38778214.E8D8F2B5@austin.rr.com>
<3283.947362055@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Can I postpone/workaround the problem by periodic server restarts to reset
the counts? Or is this a persistent thing across server restarts?Yes, a postmaster restart would clean up the buffer reference counts.
I think there were also some less drastic code paths that would clean
them up --- you might try something as simple as deliberately inducing
an SQL error now and then, so that error cleanup runs.
What *kind* of SQL error would trigger the cleanup? I've certainly had
numerous SQL errors prior to this problem showing up (parse errors, misnamed
attributes, ...), but that didn't apparently fix the problem system wide.
Also, are these buffer counts per backend or per postmaster? In other words,
does a particular kind of SQL error need to occur on each backend?
Cheers,
Ed Loehr
From bouncefilter Sat Jan 8 17:38:13 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA89829
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 17:38:12 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA20419;
Sat, 8 Jan 2000 18:38:17 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 8 Jan 2000 18:38:16 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Alfred Perlstein <bright@wintelcom.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] LIBPQ patches ...
In-Reply-To: <9125.947370422@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001081835130.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 8 Jan 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Does anyone have anything against me applying this to the current source
tree?I'm not particularly comfortable with it --- it looks like the semantics
need more careful thought, particularly concerning when the output buffer
gets flushed and what happens if we can't send data right away. The
insertion of a pqFlush into PQconsumeInput, in particular, looks like
an ill-thought-out hack that could break some applications.
Well, at least we have more discussion on this then the previous two posts
about it, so it should give something for Alfred to address :) Is there
anyone workign with libpq that could comment on possible a better way of
it being implemented?
I also object strongly to the lack of documentation. Patches that
change public APIs and come without doco updates should be rejected
out of hand, IMNSHO. Keeping the documentation up to date should
not be considered optional --- especially not when you're talking
about something that makes subtle and pervasive changes to library
behavior.
Agreed here...Alfred and I talked about that on the phone tonight...I
posted the patches tonight so that he could get some feedback on them...if
we could figure out what needs to be fixed/improved, and he has an
indication that he's working in the right direction, then documentation is
forthcoming...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sat Jan 8 17:58:16 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA96159
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 17:57:19 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA09211;
Sat, 8 Jan 2000 17:57:15 -0500 (EST)
To: Ed Loehr <eloehr@austin.rr.com>
cc: pghackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: ERROR: out of free buffers: time to abort !
In-reply-to: <3877B9E9.63E8C129@austin.rr.com>
References: <3876E186.6ACFB028@austin.rr.com> <3876E3EC.AFB8353@austin.rr.com>
<6054.947347439@sss.pgh.pa.us> <38778214.E8D8F2B5@austin.rr.com>
<3283.947362055@sss.pgh.pa.us> <3877B9E9.63E8C129@austin.rr.com>
Comments: In-reply-to Ed Loehr <eloehr@austin.rr.com>
message dated "Sat, 08 Jan 2000 16:27:53 -0600"
Date: Sat, 08 Jan 2000 17:57:15 -0500
Message-ID: <9208.947372235@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Ed Loehr <eloehr@austin.rr.com> writes:
Tom Lane wrote:
Yes, a postmaster restart would clean up the buffer reference counts.
I think there were also some less drastic code paths that would clean
them up --- you might try something as simple as deliberately inducing
an SQL error now and then, so that error cleanup runs.
What *kind* of SQL error would trigger the cleanup?
Actually, on looking at the code it doesn't seem that error recovery
will fix things --- nothing short of a postmaster restart will do it.
Instead of hacking up your application code to work around this problem,
why don't you try applying the following patch to the 6.5.3 sources.
You may get some "Buffer Leak" notice messages, but it ought to work
better than it does now. (I think --- this is off-the-cuff and not
tested ... but the complete changes that I put into current sources are
much too large to risk back-patching.)
Keep us posted.
regards, tom lane
*** src/backend/storage/buffer/bufmgr.c~ Sat Jan 8 17:44:58 2000
--- src/backend/storage/buffer/bufmgr.c Sat Jan 8 17:49:15 2000
***************
*** 1202,1213 ****
for (i = 1; i <= NBuffers; i++)
{
CommitInfoNeedsSave[i - 1] = 0;
if (BufferIsValid(i))
{
while (PrivateRefCount[i - 1] > 0)
ReleaseBuffer(i);
}
- LastRefCount[i - 1] = 0;
} ResetLocalBufferPool();
--- 1202,1218 ----
for (i = 1; i <= NBuffers; i++)
{
CommitInfoNeedsSave[i - 1] = 0;
+ /*
+ * quick hack: any refcount still being held in LastRefCount
+ * needs to be released.
+ */
+ PrivateRefCount[i - 1] += LastRefCount[i - 1];
+ LastRefCount[i - 1] = 0;
if (BufferIsValid(i))
{
while (PrivateRefCount[i - 1] > 0)
ReleaseBuffer(i);
}
} ResetLocalBufferPool();
***************
*** 1228,1233 ****
--- 1233,1244 ---- for (i = 1; i <= NBuffers; i++)
{
+ /*
+ * quick hack: any refcount still being held in LastRefCount
+ * needs to be released.
+ */
+ PrivateRefCount[i - 1] += LastRefCount[i - 1];
+ LastRefCount[i - 1] = 0;
if (BufferIsValid(i))
{
BufferDesc *buf = &(BufferDescriptors[i - 1]);From bouncefilter Sat Jan 8 19:01:15 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA08864
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 19:00:35 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id SAA91000
for pgsql-hackers@postgresql.org; Sat, 8 Jan 2000 18:36:02 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: "HydroMan" <peebs90@hotmail.com>
X-Newsgroups: comp.databases.postgresql.hackers
Subject: Postgresql Perl Problem
Lines: 19
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: <pRPd4.14389$G55.169885@news1.rdc1.ab.home.com>
Date: Sat, 08 Jan 2000 23:35:49 GMT
X-Complaints-To: abuse@home.net
X-Trace: news1.rdc1.ab.home.com 947374549 24.64.236.211 (Sat,
08 Jan 2000 15:35:49 PST)
Organization: @Home Network Canada
To: pgsql-hackers@postgresql.org
I am trying my first query a postgresql database using perl (using a Redhat
6.0 distribution). The script fails on the line:
$conn=Pg::connectdb("dbname=mydatabase");
with the error 'Can't locate pg.pm in @INC.
I thought that I may have been missing the perl5 interface for postgres, and
tried to find one. The linux documentation suggests the site
ftp://ftp.kciLink.com/pub/PostgresPerl-1.3.tar.gz, but its not there. Can
anyone tell me if this missing intergace is the problem, and if it is, where
I can get PostgresPerl-1.3.tar.gz?
Thanx,
Jason
From bouncefilter Sat Jan 8 18:48:15 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA07544
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 18:47:21 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.206]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sat, 8 Jan 2000 17:38:20 -0600
Sender: ed
Message-ID: <3877CCE8.1750C5EC@austin.rr.com>
Date: Sat, 08 Jan 2000 17:48:56 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pghackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: ERROR: out of free buffers: time to abort !
References: <3876E186.6ACFB028@austin.rr.com> <3876E3EC.AFB8353@austin.rr.com>
<6054.947347439@sss.pgh.pa.us> <38778214.E8D8F2B5@austin.rr.com>
<3283.947362055@sss.pgh.pa.us> <3877B9E9.63E8C129@austin.rr.com>
<9208.947372235@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Instead of hacking up your application code to work around this problem,
why don't you try applying the following patch to the 6.5.3 sources.
I am running 6.5.2. Were there any other pertinent changes from 6.5.2 to 6.5.3
that would make you uncomfortable about applying that patch to 6.5.2?
Cheers,
Ed Loehr
From bouncefilter Sat Jan 8 18:39:14 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA06776
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 18:39:03 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id QAA19275;
Sat, 8 Jan 2000 16:01:48 -0800 (PST)
Date: Sat, 8 Jan 2000 16:01:48 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] LIBPQ patches ...
Message-ID: <20000108160148.A17727@fw.wintelcom.net>
References: <Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
<9125.947370422@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <9125.947370422@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Sat, Jan 08, 2000 at 05:27:02PM -0500
* Tom Lane <tgl@sss.pgh.pa.us> [000108 14:56] wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Does anyone have anything against me applying this to the current source
tree?I'm not particularly comfortable with it --- it looks like the semantics
need more careful thought, particularly concerning when the output buffer
gets flushed and what happens if we can't send data right away.
Could you be more specific? My patches address the fact that
although there is work to make libpq non-blocking you can easily
block while sending large queries expecially because of the select()
that is done in pqFlush().
The problem is that libpq doesn't reserve space in the send buffer
and will just block if waiting for the socket to the backend to
drain. This needs to be fixed if libpq is trully going to offer
non-blocking behavior.
Unless you reserve the space in the buffer you have to block
otherwise if you abort (so as not to block) then libpq may have
sent a partial query down the pipe or just buffered part of some
data you've sent to the backend. At this point you will be out of sync
with the backend.
If you are in 'normal mode' (blocking) then the behavior shouldn't
be any different, if you are non-blocking then if you attempt to
send data and it's not possible you'll get an error without
potentially sending a partial line to the backend.
The
insertion of a pqFlush into PQconsumeInput, in particular, looks like
an ill-thought-out hack that could break some applications.
I think I agree, the code I was using would attempt an PQconsumeInput()
before doing a PQendcopy(), there could be data in the send buffer
that would make PQconsumeInput() never succeed hence the need for a
flush.
I'm going to try it without the PQconsumeInput() before the PQendcopy()
my modifications for PQendcopy() should make it non-blocking safe.
but in the meanwhile here's my (probably wrong) reasoning behind this
'hack':
No, IMHO it's needed, the problem is that there may be data
in the send buffer that hasn't been sent yet, it could be
part of a request to the backend that you are explicitly
waiting for a result from.
This can happen when doing a COPY into the database.
What happens is that you send data, then when you send the
'end copy' it can get buffered, then you loop forever
attempting to read a result for a query that was never
sent.
In regards to it breaking applications, the send buffer
should be opaque to the libpq user, libpq never has offered
a truly non-blocking api, and even when using non-blocking
the flush will fail if it can't be done and PQconsumeInput()
will error out accordingly.
Old applications can be snagged by the Flush since in theory
PQconsumeInput shouldn't block, however I'm not sure if
there's a real workaround for this except
1.. saving the blocking status of the connection,
2.. setting it non-blocking and attempting a flush and then
3.. restoring the blocking status.
It seems that old applications can break (looping on an
unsent line) regardless because of the not-flushed-query
problem.
If you can figure an occasion where this might actually happen
(with the exception of my accidentaly abuse of libpq) then it
may need to be revisited.
I'll get back to you guys on the PQendcopy before PQconsumeInput
tests.
I also object strongly to the lack of documentation. Patches that
change public APIs and come without doco updates should be rejected
out of hand, IMNSHO. Keeping the documentation up to date should
not be considered optional --- especially not when you're talking
about something that makes subtle and pervasive changes to library
behavior.
I agree with you about the documentation issues, I will try to add
some documentation to the patches.
I think I can also take out the visibility of the PQflush() function
as normal applications really shouldn't need it.
How do you feel about the explicit PQsetnonblocking and PQisnonblocking
functions that I added as well as the additional field 'nonblocking'
added to PGconn? IMO the user shouldn't set the socket non-blocking
without informing the library about it otherwise it gets really ugly
because we have to constantly poll the socket's flags to make sure we
DTRT.
I also apologize for my not indented patches, is there a way to indent
according to postgresql standards on a FreeBSD system? The patches
for pgindent are a bit out of date and I get floating point exceptions
when attempting to pgindent.
Thanks for the feedback.
-Alfred
From bouncefilter Sat Jan 8 19:12:14 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA12635
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 19:12:01 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id QAA19971;
Sat, 8 Jan 2000 16:34:52 -0800 (PST)
Date: Sat, 8 Jan 2000 16:34:52 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] LIBPQ patches ...
Message-ID: <20000108163451.B17727@fw.wintelcom.net>
References: <Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
<9125.947370422@sss.pgh.pa.us>
<20000108160148.A17727@fw.wintelcom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000108160148.A17727@fw.wintelcom.net>;
from bright@wintelcom.net on Sat, Jan 08, 2000 at 04:01:48PM -0800
* Alfred Perlstein <bright@wintelcom.net> [000108 16:08] wrote:
* Tom Lane <tgl@sss.pgh.pa.us> [000108 14:56] wrote:
The
insertion of a pqFlush into PQconsumeInput, in particular, looks like
an ill-thought-out hack that could break some applications.I think I agree, the code I was using would attempt an PQconsumeInput()
before doing a PQendcopy(), there could be data in the send buffer
that would make PQconsumeInput() never succeed hence the need for a
flush.I'm going to try it without the PQconsumeInput() before the PQendcopy()
my modifications for PQendcopy() should make it non-blocking safe.
but in the meanwhile here's my (probably wrong) reasoning behind this
'hack':No, IMHO it's needed, the problem is that there may be data
in the send buffer that hasn't been sent yet, it could be
part of a request to the backend that you are explicitly
waiting for a result from.This can happen when doing a COPY into the database.
What happens is that you send data, then when you send the
'end copy' it can get buffered, then you loop forever
attempting to read a result for a query that was never
sent.In regards to it breaking applications, the send buffer
should be opaque to the libpq user, libpq never has offered
a truly non-blocking api, and even when using non-blocking
the flush will fail if it can't be done and PQconsumeInput()
will error out accordingly.Old applications can be snagged by the Flush since in theory
PQconsumeInput shouldn't block, however I'm not sure if
there's a real workaround for this except1.. saving the blocking status of the connection,
2.. setting it non-blocking and attempting a flush and then
3.. restoring the blocking status.It seems that old applications can break (looping on an
unsent line) regardless because of the not-flushed-query
problem.If you can figure an occasion where this might actually happen
(with the exception of my accidentaly abuse of libpq) then it
may need to be revisited.I'll get back to you guys on the PQendcopy before PQconsumeInput
tests.
I just remebered where the problem is (sorry it's been about 2 weeks
since i've read through the code) it's a bit different
and messier than I thought:
I begin my COPY commands with a PQsendQuery() which has this block
of code in it:
/* send the query to the backend; */
/* the frontend-backend protocol uses 'Q' to designate queries */
if (pqPutnchar("Q", 1, conn) ||
pqPuts(query, conn) ||
pqFlush(conn))
{
handleSendFailure(conn);
return 0;
}
It can get really hairy for non-blocking connections if any of the
functions in the 'if' conditional fail, any ideas on a workaround?
One that comes to mind is using the low/high watermarks in sockets,
if we do that then a write-ready true condition would garantee that
we have X number of bytes available in our send buffer and we can
safely queue the data. This doesn't seem portable and would be
pretty complex.
Another is to attempt a flush beforehand aborting early if it fails
however we still need to flush after we pqPutnchar and pqPuts,
if that fails we are back to needing to call pqFlush from PQconsumeInput
beccause the only failure is that the backend's pipe is potentially full
and we may have queued something.
This 'hack' would be to allow the last flush to fail and always call
pqFlush in PQconsumeInput when the connection is non-blocking because
with the new code it shouldn't block, PQconsumeInput will function to
drive data to the backend in that situation. We'll only do the
flush in PQconsumeInput() for non-blocking connections because
the conditional in PQsendQuery shouldn't fail for blocking connections
unless something is seriously wrong.
I hate to say it, but I like the hack approach, it is somewhat wierd
but looks like it would work quite well as any error returned from
the backend would be delayed until PQconsumeInput and a broken connection
would still be returned immediatly from PQsendQuery.
Your opinion?
--
-Alfred Perlstein - [bright@rush.net|alfred@freebsd.org]
Wintelcom systems administrator and programmer
- http://www.wintelcom.net/ [bright@wintelcom.net]
From bouncefilter Sat Jan 8 21:47:16 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA39506
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 21:46:26 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA22369;
Sat, 8 Jan 2000 21:46:23 -0500 (EST)
To: Ed Loehr <eloehr@austin.rr.com>
cc: pghackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: ERROR: out of free buffers: time to abort !
In-reply-to: <3877CCE8.1750C5EC@austin.rr.com>
References: <3876E186.6ACFB028@austin.rr.com> <3876E3EC.AFB8353@austin.rr.com>
<6054.947347439@sss.pgh.pa.us> <38778214.E8D8F2B5@austin.rr.com>
<3283.947362055@sss.pgh.pa.us> <3877B9E9.63E8C129@austin.rr.com>
<9208.947372235@sss.pgh.pa.us> <3877CCE8.1750C5EC@austin.rr.com>
Comments: In-reply-to Ed Loehr <eloehr@austin.rr.com>
message dated "Sat, 08 Jan 2000 17:48:56 -0600"
Date: Sat, 08 Jan 2000 21:46:23 -0500
Message-ID: <22366.947385983@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Ed Loehr <eloehr@austin.rr.com> writes:
Tom Lane wrote:
Instead of hacking up your application code to work around this problem,
why don't you try applying the following patch to the 6.5.3 sources.
I am running 6.5.2. Were there any other pertinent changes from 6.5.2 to 6.5.3
that would make you uncomfortable about applying that patch to 6.5.2?
No, but I would recommend trying it in a playpen installation, in any
case, not straight into production servers ;-)
regards, tom lane
From bouncefilter Sat Jan 8 22:18:16 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA45096
for <pgsql-hackers@postgresql.org>; Sat, 8 Jan 2000 22:17:27 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA21618;
Sat, 8 Jan 2000 23:17:27 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 8 Jan 2000 23:17:26 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
cc: Alexander Barkov <bar@izhcom.ru>
Subject: Table locking ...
Message-ID: <Pine.BSF.4.21.0001082305350.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I'm seeing a weird problem, that I don't think I should be expecting in
v6.5.3 of PostgreSQL ... an inability to SELECT form a database while the
UdmSearch/indexer is running...
ps shows:
30040 ?? R 20:54.37 /home/database/v6.5.3/bin/postgres pgsql 216.126.84.1 udmsearch UPDATE
43846 ?? I 0:00.03 /home/database/v6.5.3/bin/postgres pgsql 216.126.84.1 udmsearch SELECT waiting
And, if I do successive ps's in a row, the 'SELECT waiting' stays, but the
UPDATING keeps flashing between 'UPDATING' and 'idle'...
*Eventually*, the SELECT gets perform and the call returns...
But, with MVCC, I didn't think that I should see any 'hangs' on SELECT
calls...the process on 43846 is 'indexer -S', which just generates stats
on the database.
The problem, in the case of this particular application, is that if
multiple searches were to happen, while the database is being updated, it
seems that this could be a point of contention?
From what I can tell reading through the reading through the code, there
is never a TABLE LOCK issued when using PostgreSQL, but it does use
BEGIN/END...
Am I misunderstanding how MVCC is supposed to work? Could we have a bug
in v6.5.3?
I'm still looking through the code, to see if I've overlooked something,
but I figure I'd check to see if maybe I'm misunderstanding MVCC
altogether first...
I'm CCng in the author of the code, just in case this is something that
I'm overlooking in theh code...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sat Jan 8 22:27:16 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA45961
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 22:27:06 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA21676;
Sat, 8 Jan 2000 23:27:03 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 8 Jan 2000 23:27:03 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgreSQL.org
cc: Alexander Barkov <bar@izhcom.ru>
Subject: Re: [HACKERS] Table locking ...
In-Reply-To: <Pine.BSF.4.21.0001082305350.18498-100000@thelab.hub.org>
Message-ID: <Pine.BSF.4.21.0001082326400.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Okay, I did find a LOCK being issued, just not sure if its required or
not, with MVCC...
On Sat, 8 Jan 2000, The Hermit Hacker wrote:
I'm seeing a weird problem, that I don't think I should be expecting in
v6.5.3 of PostgreSQL ... an inability to SELECT form a database while the
UdmSearch/indexer is running...ps shows:
30040 ?? R 20:54.37 /home/database/v6.5.3/bin/postgres pgsql 216.126.84.1 udmsearch UPDATE
43846 ?? I 0:00.03 /home/database/v6.5.3/bin/postgres pgsql 216.126.84.1 udmsearch SELECT waitingAnd, if I do successive ps's in a row, the 'SELECT waiting' stays, but the
UPDATING keeps flashing between 'UPDATING' and 'idle'...*Eventually*, the SELECT gets perform and the call returns...
But, with MVCC, I didn't think that I should see any 'hangs' on SELECT
calls...the process on 43846 is 'indexer -S', which just generates stats
on the database.The problem, in the case of this particular application, is that if
multiple searches were to happen, while the database is being updated, it
seems that this could be a point of contention?From what I can tell reading through the reading through the code, there
is never a TABLE LOCK issued when using PostgreSQL, but it does use
BEGIN/END...Am I misunderstanding how MVCC is supposed to work? Could we have a bug
in v6.5.3?I'm still looking through the code, to see if I've overlooked something,
but I figure I'd check to see if maybe I'm misunderstanding MVCC
altogether first...I'm CCng in the author of the code, just in case this is something that
I'm overlooking in theh code...Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sat Jan 8 22:55:17 2000
Received: from elwood.cais.com (elwood.cais.com [199.0.216.215])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA51356
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 22:54:59 -0500 (EST)
(envelope-from clark.evans@manhattanproject.com)
Received: from cauchy.clarkevans.com (IDENT:clark@209-9-30-66.sdsl.cais.net
[209.9.30.66]) by elwood.cais.com (8.9.1/Elwood) with ESMTP
id WAA04530 for <pgsql-hackers@postgreSQL.org>;
Sat, 8 Jan 2000 22:58:26 -0500 (EST)
Date: Sat, 8 Jan 2000 22:57:34 -0500 (EST)
From: "Clark C. Evans" <clark.evans@manhattanproject.com>
X-Sender: clark@cauchy.clarkevans.com
To: pgsql-hackers@postgreSQL.org
Subject: A Markup Database Interface; Borrowing from Groves
In-Reply-To: <Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
Message-ID: <Pine.LNX.4.10.10001082200590.3652-100000@cauchy.clarkevans.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hello all. I wanted to throw up an idea for a
XML interface to PostgreSQL.
The underlying information model for SGML documents
is called the "groves" model. The model's primary
prupose is to handle multiple content hierarchites
within a single network; as this is the primary
problem with multimedia hypertext markup (HyTime).
Anyway, what is interesting is that the core of the
groves model seems to be the following seemingly
simple production:
node := character | map( string, list(node) )
It is an alternation between a map (unordered
set) and a list (ordered bag). Anyway, the discovery
made me sit back in my chair and go hmmmmmm. As it
seems to me; this model is the essence of a multi-level
result set, and could point towards a rather natural
mapping of a multi-hierarchy result set onto a tag
based markup language like XML.
For starters, here is a row...
row-node := map (string, list(characters))
For example, here is an order, and two order-line rows:
order-row-node := { id = '345'
, buyer = 'Clark Evans'
}
order-line-row := { order-id = '345'
, product = 'Bag of rice'
, quantity = '1'
}
order-line-row := { order-id = '345'
, product = 'Tofo'
, quantity = '3'
And here, is a table:
relation-node := map('relation-name',list(row-node))
line-relation := { order-line =
[
{ order-id = '345'
, product = 'Bag of rice'
, quantity = '1'
}
,
...
,
{ order-id = '345'
, product = 'Tofo'
, quantity = '1'
}
]
}
Here is the origonal production again:
node := character | map( string, list(node) )
It could then be used to return a nested
result set like:
SELECT *
FROM ORDER
WHERE ID = '345'
with this sub-query nested...
SELECT PRODUCT, QUANTITY
FROM ORDER_LINE
WHERE ORDER_ID = ID;
my-order =: { id = '345'
, buyer = 'Clark Evans'
, lines =
[
{ order-id = '345'
, product = 'Bag of rice' }
, quantity = '1'
}
,
{ order-id = '345'
, product = 'Tofo'
, quantity = '3'
}
]
}
Here is a mapping to a simple markup language
(http://www.egroups.com/list/sml-dev/info.html)
<order>
<id>345</id>
<buyer>Clark Evans</buyer>
<order-line-list>
<order-line>
<product>Bag of rice</product>
<quantity>1</quantity>
</order-line>
<order-line>
<product>Tofo</product>
<quantity>3</quantity>
</order-line>
</order-line-list>
</order>
So, if you notice the even levels are maps,
and the odd levels are lists. Kinda cool.
Of course, you can shorten it with attribute notation...
<order id="345" buyer="Clark Evans">
<order-line product="Bag of rice" quantity="1" />
<order-line product="Tofo" quantity="3" />
</order>
(The syntax is more brief, but it only
allows for one list per map)
Anyway, this could allow for some nice automated
conversions in between a database and SML/XML/SGML.
Indeed, I was thinking that a binary version of
of the former syntax would make for a great
interface into/outof the database. Add a simple
text/binary adapter and PostgreSQL would be
XML ready... without the need for any particular
mapping tool.
Best,
Clark
From bouncefilter Sat Jan 8 23:22:17 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA57496
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 23:21:36 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA24653
for <pgsql-hackers@postgreSQL.org>; Sat, 8 Jan 2000 23:21:28 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Regress tests reveal *serious* psql bug
Date: Sat, 08 Jan 2000 23:21:28 -0500
Message-ID: <24650.947391688@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Now that we can run the regress tests using the new psql,
I was dismayed to discover that the arrays regress test
fails with it. The perfectly valid query
SELECT arrtest.a[1:3],
arrtest.b[1:1][1:2][1:2],
arrtest.c[1:2],
arrtest.d[1:1][1:2]
FROM arrtest;
fails with
ERROR: parser: parse error at or near "]"
Turning on postmaster -d reveals that what is arriving at
the backend is
SELECT arrtest.a[1],
arrtest.b[1][1][1],
arrtest.c[1],
arrtest.d[1][1]]
FROM arrtest
Needless to say, this transformation of the query
is several miles to the south of acceptable.
Over to you, Peter...
regards, tom lane
From bouncefilter Sun Jan 9 02:16:19 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA95940
for <pgsql-hackers@postgresql.org>; Sun, 9 Jan 2000 02:16:00 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id DAA23100
for <pgsql-hackers@postgresql.org>; Sun, 9 Jan 2000 03:16:06 -0400 (AST)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 9 Jan 2000 03:16:06 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: VACUUM VERBOSE ...
Message-ID: <Pine.BSF.4.21.0001090314480.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
What exactly does this mean:
NOTICE: Index word_url: Pages 16645; Tuples 5004183. Elapsed 3/9 sec.
I'm curious about the Elapsed ... it took several minutes to before that
pop'd up on the screen, which is why I ask...
Thanks...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 9 03:08:19 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA09700
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 03:08:15 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id DAA09644
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 03:08:14 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: New scheme for managing regress test result files
Date: Sun, 09 Jan 2000 03:08:14 -0500
Message-ID: <9641.947405294@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Since we have to go through the process of regenerating regress test
result files anyway, now seemed like a good time to take care of
something that's been bugging me for a while. I have just committed
changes that allow multiple platforms to share platform-specific
regress test result files.
For example, there are a lot of machines where the int2 regress test
produces
ERROR: pg_atoi: error reading "100000": Result too large
instead of the reference platform's
ERROR: pg_atoi: error reading "100000": Numerical result out of range
We can now have all these platforms share a single result file,
which I've called expected/int2-too-large.out, rather than having
to have duplicate result files for each such platform. There is
a mapping file src/test/regress/resultmap that identifies which file
to use for each platform --- it's a lot like src/template/.similar,
if you've messed around with that.
So far I've only put entries into resultmap for my own platform (HPUX)
but I'm sure many more will get added over the next few weeks.
The parallel regress test script, run_check.sh, doesn't seem to work
with this scheme yet. It *ought* to work but, at least on my machine,
it seems like /bin/sh has problems with nested "while read" loops.
I've run out of steam to work on this for tonight --- perhaps someone
else can see how to fix it.
Also, I updated src/test/regress/README but didn't touch the SGML
doco yet...
regards, tom lane
From bouncefilter Sun Jan 9 03:21:20 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA10868
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 03:20:46 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id EAA23409;
Sun, 9 Jan 2000 04:20:49 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 9 Jan 2000 04:20:48 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New scheme for managing regress test result files
In-Reply-To: <9641.947405294@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001090420130.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 9 Jan 2000, Tom Lane wrote:
Since we have to go through the process of regenerating regress test
result files anyway, now seemed like a good time to take care of
something that's been bugging me for a while. I have just committed
changes that allow multiple platforms to share platform-specific
regress test result files.For example, there are a lot of machines where the int2 regress test
produces
ERROR: pg_atoi: error reading "100000": Result too large
instead of the reference platform's
ERROR: pg_atoi: error reading "100000": Numerical result out of range
We can now have all these platforms share a single result file,
which I've called expected/int2-too-large.out, rather than having
to have duplicate result files for each such platform. There is
a mapping file src/test/regress/resultmap that identifies which file
to use for each platform --- it's a lot like src/template/.similar,
if you've messed around with that.So far I've only put entries into resultmap for my own platform (HPUX)
but I'm sure many more will get added over the next few weeks.
Working on FreeBSD right now...
From bouncefilter Sun Jan 9 03:33:20 2000
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA15100
for <pgsql-hackers@postgresql.org>; Sun, 9 Jan 2000 03:32:51 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.206]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sun, 9 Jan 2000 02:33:18 -0600
Sender: ed
Message-ID: <38784811.3E555463@austin.rr.com>
Date: Sun, 09 Jan 2000 02:34:25 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] "ExecInitIndexScan: both left and right..." meaning?
References: <8764.945633824@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm seeing an old showstopper bug in a new form in 6.5.2:
ExecInitIndexScan: both left and right op's are rel-vars
[I also sorely wish the error message identified the offending part
of the WHERE clause.]
I'm running with PGOPTIONS="-fn" (the previously assumed
brute force prevention), and have partially verified there are no
nested loops occurring (output & details below). Vacuum analyze
no longer helps as it once did.
This was presumed fixed in the coming 7.0, but the latest
manifestation suggests the problem may not be fully understood.
More below...
For the sordid history, see
http://www.deja.com/qs.xp?QRY=ExecInitIndexScan&OP=dnquery.xp&showsort=date
or search Udm for ExecIndexInitScan.
Here's context on where we last left it...
Tom Lane wrote:
[...long explanation of bug and solution deleted...]
I have fixed this in current sources by removing the field in question
from RestrictInfo nodes and storing the information in separate lists.
But it's a pretty major change and I don't want to try to back-patch it.I would suggest, instead, that you work around the problem until 7.0
comes out. I think you could do this by removing your two-column
indexes in favor of single-column indexes, or even just switching the
order of the indexes... However switching the order would be
a bit fragile since it'd depend on which fields you compare to constants
and which ones you use as join keys in your queries. If that doesn't
work, a brute-force solution is to run your application with environment
variable PGOPTIONS="-fn" (forbid nestloop joins), which discourages the
planner from considering nestloop joins at all. The bug will not arise
if a merge or hash join plan is used.
It appears the -fn flag is not preventing the bug.
One detail seems odd (and different from the nested-loop manifestation):
when the offending "rather large" SELECT query is run via Apache/
mod_perl/DBI/DBD::Pg, the error occurs, but when I cut and paste the
query from the logs into psql, it does not trigger the error (it also does not
yield any results).
I'm including the offending query and explain output below...
Cheers,
Ed Loehr
SELECT sum( cet.default_budget_per_unit *
cahrn.hr_count *
cahrn.duration ) AS "amount"
FROM contract_activity_hr_need cahrn,
contract_expense_type cet,
contract_activity_type_expense_type catet,
contract_activity_type cat, activity pa
WHERE cet.contract_id = 1
AND catet.contract_id = 1
AND cahrn.contract_id = 1
AND pa.contract_id = 1
AND cat.contract_id = 1
AND cet.expense_unit_id = 3
AND pa.activity_state_id <> 5
AND pa.activity_state_id <> 4
AND (pa.billable = 0 OR cahrn.billable = 0)
AND pa.activity_type_id = cat.activity_type_id
AND catet.expense_type_id = cet.expense_type_id
AND catet.activity_type_id = cat.activity_type_id
AND cahrn.contract_activity_type_id = cat.id;
20000109.02:13:48.783 [13865] NOTICE: QUERY PLAN:
Aggregate (cost=28.61 rows=6608 width=52)
-> Hash Join (cost=28.61 rows=6608 width=52)
-> Hash Join (cost=14.74 rows=1 width=44)
-> Seq Scan on contract_activity_hr_need cahrn (cost=2.02 rows=3
width=16)
-> Hash (cost=11.58 rows=1 width=28)
-> Merge Join (cost=11.58 rows=1 width=28)
-> Seq Scan (cost=9.34 rows=1 width=20)
-> Sort (cost=9.34 rows=1 width=20)
-> Hash Join (cost=8.34 rows=1 width=20)
-> Index Scan using contract_activi
ty_type_exp_pkey on contract_activity_type_expense_ catet (cost=3.87 rows=38 wi
dth=8)
-> Hash (cost=2.18 rows=1 width=12
)
-> Index Scan using contract_
expense_type_pkey on contract_expense_type cet (cost=2.18 rows=1 width=12)
-> Index Scan using contract_activity_type_pkey on co
ntract_activity_type cat (cost=2.12 rows=3 width=8)
-> Hash (cost=13.84 rows=0 width=8)
-> Index Scan using activity_cid on activity pa (cost=13.84 rows
=0 width=8)
From bouncefilter Sun Jan 9 07:47:22 2000
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 HAA60556
for <pgsql-hackers@postgresql.org>; Sun, 9 Jan 2000 07:46:34 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id VAA26793
for <pgsql-hackers@postgresql.org>; Sun, 9 Jan 2000 21:46:32 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-10 [133.137.84.10])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id VAA03388
for <pgsql-hackers@postgresql.org>; Sun, 9 Jan 2000 21:46:31 +0900
To: pgsql-hackers@postgresql.org
Subject: postmaster.c postgres.c pg_ctl etc. updated
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000109214656R.t-ishii@sra.co.jp>
Date: Sun, 09 Jan 2000 21:46:56 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 17
I have modified following files.
bin/pg_ctl/pg_ctl.sh
include/miscadmin.h
backend/postmaster/poastmaster.c
backend/tcop/postgres.c
backend/utils/init/miscinit.c
The reason for the changes is to prevent starting postmaster if
(standalone) postgres is running and vice versa. Also, to know the pid
in postmaster.pid is postmaster or postgres, I set following
convention:
pid > 0: postmaster
pid < 0: (standalone) postgres
--
Tatsuo Ishii
From bouncefilter Sun Jan 9 10:09:24 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA90885
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 10:09:11 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA23489;
Sun, 9 Jan 2000 07:07:50 -0800 (PST)
Message-Id: <3.0.1.32.20000109070102.0101d7b0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 09 Jan 2000 07:01:02 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] LIBPQ patches ...
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <9125.947370422@sss.pgh.pa.us>
References: <Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
<Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 05:27 PM 1/8/00 -0500, Tom Lane wrote:
I also object strongly to the lack of documentation. Patches that
change public APIs and come without doco updates should be rejected
out of hand, IMNSHO. Keeping the documentation up to date should
not be considered optional --- especially not when you're talking
about something that makes subtle and pervasive changes to library
behavior.
Boy, Tom's really laid it out in excellent style. If the author of
such changes doesn't document them, chances are that the documentation
won't get done. That's very bad.
The automatic rejection of undocumented patches that change the API
or other user-visible behavior shouldn't be controversial. I know
there are some folks who aren't native-english speakers, so perhaps
you don't want to require that the implementor of such patches provide
the final documentation wording. But the information should be there
and spelled out in a form that can be very easily moved to the docs.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sun Jan 9 10:40:24 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA96522
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 10:40:22 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA09934;
Sun, 9 Jan 2000 10:40:20 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] New scheme for managing regress test result files
In-reply-to: <Pine.BSF.4.21.0001090420130.18498-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001090420130.18498-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Sun, 09 Jan 2000 04:20:48 -0400"
Date: Sun, 09 Jan 2000 10:40:19 -0500
Message-ID: <9931.947432419@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
So far I've only put entries into resultmap for my own platform (HPUX)
but I'm sure many more will get added over the next few weeks.
Working on FreeBSD right now...
Cool. BTW, I realized it would probably be a lot easier to write the
map patterns if the platform names could be given as pattern
expressions, not just prefixes --- for example, int2/hppa*hpux10*=...
Will work on fixing that today.
regards, tom lane
From bouncefilter Sun Jan 9 10:51:24 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA97477
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 10:50:31 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA10007;
Sun, 9 Jan 2000 10:50:28 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] LIBPQ patches ...
In-reply-to: <3.0.1.32.20000109070102.0101d7b0@mail.pacifier.com>
References: <Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
<Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
<3.0.1.32.20000109070102.0101d7b0@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Sun, 09 Jan 2000 07:01:02 -0800"
Date: Sun, 09 Jan 2000 10:50:28 -0500
Message-ID: <10004.947433028@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Don Baccus <dhogaza@pacifier.com> writes:
At 05:27 PM 1/8/00 -0500, Tom Lane wrote:
I also object strongly to the lack of documentation.
... I know there are some folks who aren't native-english speakers, so
perhaps you don't want to require that the implementor of such patches
provide the final documentation wording. But the information should
be there and spelled out in a form that can be very easily moved to
the docs.
Oh, absolutely. Thomas, our master of the docs, has always had the
policy of "give me some words, I'll take care of formatting and
editing..."
I was probably too harsh on Alfred last night, since in fact his code
was fairly well commented, and some minimal doco could have been
extracted from the routine headers. But on a change like this, I think
some paragraphs of coherent high-level explanation are needed: what it
does, when and why you'd use it. I didn't see that anywhere...
regards, tom lane
From bouncefilter Sun Jan 9 11:18:25 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA03913
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 11:17:33 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA10187;
Sun, 9 Jan 2000 11:17:31 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] VACUUM VERBOSE ...
In-reply-to: <Pine.BSF.4.21.0001090314480.18498-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001090314480.18498-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Sun, 09 Jan 2000 03:16:06 -0400"
Date: Sun, 09 Jan 2000 11:17:31 -0500
Message-ID: <10184.947434651@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
NOTICE: Index word_url: Pages 16645; Tuples 5004183. Elapsed 3/9 sec.
I'm curious about the Elapsed ... it took several minutes to before that
pop'd up on the screen, which is why I ask...
That'd been bothering me too. A glance at the vacuum code makes it
clear that what's being reported is not elapsed time at all: the numbers
are user and system CPU time. OK, that's cool, but the wording of the
notice message needs to be changed to identify the numbers correctly.
Do we need to have actual wall clock time in there too?
regards, tom lane
From bouncefilter Sun Jan 9 13:05:26 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA44973
for <pgsql-hackers@postgresql.org>; Sun, 9 Jan 2000 13:04:40 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA20014;
Sun, 9 Jan 2000 13:03:36 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001091803.NAA20014@candle.pha.pa.us>
Subject: Re: [HACKERS] LIBPQ patches ...
In-Reply-To: <3.0.1.32.20000109070102.0101d7b0@mail.pacifier.com> from Don
Baccus at "Jan 9, 2000 07:01:02 am"
To: Don Baccus <dhogaza@pacifier.com>
Date: Sun, 9 Jan 2000 13:03:36 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>,
pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
At 05:27 PM 1/8/00 -0500, Tom Lane wrote:
I also object strongly to the lack of documentation. Patches that
change public APIs and come without doco updates should be rejected
out of hand, IMNSHO. Keeping the documentation up to date should
not be considered optional --- especially not when you're talking
about something that makes subtle and pervasive changes to library
behavior.Boy, Tom's really laid it out in excellent style. If the author of
such changes doesn't document them, chances are that the documentation
won't get done. That's very bad.The automatic rejection of undocumented patches that change the API
or other user-visible behavior shouldn't be controversial. I know
there are some folks who aren't native-english speakers, so perhaps
you don't want to require that the implementor of such patches provide
the final documentation wording. But the information should be there
and spelled out in a form that can be very easily moved to the docs.
If it is missing, we get back to them before final release and ask for
doc patches. They get in there one way or another.
--
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 Jan 9 13:53:26 2000
Received: from onestone.elsinore.klever.net (root@onestone.elsinore.klever.net
[207.175.129.2]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA52895
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 13:52:50 -0500 (EST)
(envelope-from sbirch@ironmountainsystems.com)
Received: from ironmountainsystems.com (ppp84.kross.klever.net
[209.203.65.84]) by onestone.elsinore.klever.net (8.8.7/8.8.0)
with ESMTP id LAA16849; Sun, 9 Jan 2000 11:43:00 -0800
Sender: sbirch@onestone.elsinore.klever.net
Message-ID: <3878D740.78479672@ironmountainsystems.com>
Date: Sun, 09 Jan 2000 10:45:20 -0800
From: Stephen Birch <sbirch@ironmountainsystems.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-SMP i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re:HEAP_MOVED_IN during vacuum - test case
References: <Pine.BSF.4.21.0001040915250.18498-100000@thelab.hub.org>
<13280.947001513@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I have now created a test case that demonstrate the HEAP_MOVED_IN during
vacuum problem. Since the tar ball is 182k - I put it on an ftp site
instead of mailing it.
You can grab it from the following location:
http://www.ironmountainsystems.com/heap_moved_in/
The tar ball contains two files - a shell script (show_bug) and a pg_dump
dump. The shell script does the following using the dump file:
1. Create database ntis
2. Create table msg and populate it.
3. Use trim() twice.
4. Vacuum.
The three interesting commands reside at the end of ntis.dmp:
update msg set description = trim(description);
update msg set owner = trim(owner);
vacuum;
when the script "show_bug" is run, we get the following output:
CREATE DATABASE
You are now connected to database ntis.
CREATE
UPDATE 12069
UPDATE 12069
ERROR: HEAP_MOVED_IN was not expected
One interesting point: if either one of the trim operations is omitted,
vacuum does not give the HEAP_MOVED_IN error. I also notice that if you
change ntis.dmp so a vacuum is done between the two, the problem goes away.
Any ideas?
Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
"However, the biggest problem was reported recently, see "HEAP_MOVED_IN
during vacuum" posted on Saturday, no replies" ...Anyone have any comments on that last one?
I replied to it --- not with any useful ideas I'm afraid, just asking
for more info. But if Stephen is claiming he was ignored, then he's
not reading his email...regards, tom lane
************
From bouncefilter Sun Jan 9 14:34:27 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA62474
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 14:33:45 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA31501;
Sun, 9 Jan 2000 15:32:22 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 9 Jan 2000 15:32:21 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] LIBPQ patches ...
In-Reply-To: <3.0.1.32.20000109070102.0101d7b0@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0001091524260.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 9 Jan 2000, Don Baccus wrote:
At 05:27 PM 1/8/00 -0500, Tom Lane wrote:
I also object strongly to the lack of documentation. Patches that
change public APIs and come without doco updates should be rejected
out of hand, IMNSHO. Keeping the documentation up to date should
not be considered optional --- especially not when you're talking
about something that makes subtle and pervasive changes to library
behavior.Boy, Tom's really laid it out in excellent style. If the author of
such changes doesn't document them, chances are that the documentation
won't get done. That's very bad.The automatic rejection of undocumented patches that change the API
or other user-visible behavior shouldn't be controversial. I know
there are some folks who aren't native-english speakers, so perhaps
you don't want to require that the implementor of such patches provide
the final documentation wording. But the information should be there
and spelled out in a form that can be very easily moved to the docs.
These patches were originally submited before Xmas by Alfred, asking for
feedback on them and possibly pointing out errors in implementation...he
wanted to get a feel whether or not it was *worth* him putting further
work into them. They fell on silent ears.
Personally, I wouldn't waste my time on documenting something that, in the
end, I'd be the only one using...I'd get feedback on the usefulness first,
and then deal with building up the documentation after I've found out that
its worth it...
Alfred didn't ask "do I need to add documentation?" ... he knew that ...
he asked whether or not the implementation was appropriate, and was worth
his time to continue working ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 9 14:44:27 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA63449
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 14:44:22 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA31539;
Sun, 9 Jan 2000 15:41:58 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 9 Jan 2000 15:41:58 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] VACUUM VERBOSE ...
In-Reply-To: <10184.947434651@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001091533440.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 9 Jan 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
NOTICE: Index word_url: Pages 16645; Tuples 5004183. Elapsed 3/9 sec.
I'm curious about the Elapsed ... it took several minutes to before that
pop'd up on the screen, which is why I ask...That'd been bothering me too. A glance at the vacuum code makes it
clear that what's being reported is not elapsed time at all: the numbers
are user and system CPU time. OK, that's cool, but the wording of the
notice message needs to be changed to identify the numbers correctly.Do we need to have actual wall clock time in there too?
I don't have what I would consider an "absolutely quiet system", nor is my
system particularly loaded since we moved the news server to a dedicated
machine...so its basically running a web server and database server right
now...3/9sec of user/sys time vs >5min of real time sounds like a major
difference in time...
I don't think we need actual wall clock time in there, since that is easy
to calculate :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 9 16:34:31 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA85046
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 16:33:42 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id QAA28473;
Sun, 9 Jan 2000 16:33:21 -0500 (EST)
To: Stephen Birch <sbirch@ironmountainsystems.com>
cc: The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re:HEAP_MOVED_IN during vacuum - test case
In-reply-to: <3878D740.78479672@ironmountainsystems.com>
References: <Pine.BSF.4.21.0001040915250.18498-100000@thelab.hub.org>
<13280.947001513@sss.pgh.pa.us>
<3878D740.78479672@ironmountainsystems.com>
Comments: In-reply-to Stephen Birch <sbirch@ironmountainsystems.com>
message dated "Sun, 09 Jan 2000 10:45:20 -0800"
Date: Sun, 09 Jan 2000 16:33:21 -0500
Message-ID: <28470.947453601@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Stephen Birch <sbirch@ironmountainsystems.com> writes:
I have now created a test case that demonstrate the HEAP_MOVED_IN during
vacuum problem.
Using this script, I see no failure under either REL6_5_PATCHES or
current branch on HPUX 10.20 --- but I do see it in current sources
on a Linux box! Platform-dependent problem, evidently. Will start
digging.
Stephen, many thanks for creating a small, reproducible example.
I know that's often the hardest part of finding a bug...
regards, tom lane
From bouncefilter Sun Jan 9 22:00:32 2000
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 VAA54627
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 21:59:38 -0500 (EST)
(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 LAA01423; Mon, 10 Jan 2000 11:57:57 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Stephen Birch" <sbirch@ironmountainsystems.com>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>,
"PostgreSQL-development" <pgsql-hackers@postgreSQL.org>,
"The Hermit Hacker" <scrappy@hub.org>
Subject: RE: [HACKERS] Re:HEAP_MOVED_IN during vacuum - test case
Date: Mon, 10 Jan 2000 12:03:23 +0900
Message-ID: <000301bf5b17$41f342a0$2801007e@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: <3878D740.78479672@ironmountainsystems.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Stephen BirchI have now created a test case that demonstrate the HEAP_MOVED_IN during
vacuum problem. Since the tar ball is 182k - I put it on an ftp site
instead of mailing it.You can grab it from the following location:
The following patch seems to fix your case.
However I'm not sure it's a right solution.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
Index: commands/vacuum.c
===================================================================
RCS file: /home/cvs/pgcurrent/backend/commands/vacuum.c,v
retrieving revision 1.18
diff -c -r1.18 vacuum.c
*** commands/vacuum.c 2000/01/05 03:05:35 1.18
--- commands/vacuum.c 2000/01/10 02:39:35
***************
*** 1049,1054 ****
--- 1049,1055 ----
*idcur;
int last_fraged_block,
last_vacuum_block,
+ last_movedin_block,
i = 0;
Size tuple_len;
int num_moved,
***************
*** 1084,1089 ****
--- 1085,1091 ----
vacuumed_pages = vacuum_pages->vpl_num_pages -
vacuum_pages->vpl_empty_end_pages;
last_vacuum_page = vacuum_pages->vpl_pagedesc[vacuumed_pages - 1];
last_vacuum_block = last_vacuum_page->vpd_blkno;
+ last_movedin_block = 0;
Assert(last_vacuum_block >= last_fraged_block);
cur_buffer = InvalidBuffer;
num_moved = 0;
***************
*** 1097,1102 ****
--- 1099,1107 ----
/* if it's reapped page and it was used by me - quit */
if (blkno == last_fraged_block && last_fraged_page->vpd_offsets_used >
0)
break;
+ /* couldn't shrink any more if this block has MOVED_INd tuples - quit */
+ if (blkno == last_movedin_block)
+ break; buf = ReadBuffer(onerel, blkno);
page = BufferGetPage(buf);
***************
*** 1477,1482 ****
--- 1482,1489 ----
newtup.t_datamcxt = NULL;
newtup.t_data = (HeapTupleHeader) PageGetItem(ToPage, newitemid);
ItemPointerSet(&(newtup.t_self), vtmove[ti].vpd->vpd_blkno, newoff);
+ if (vtmove[i].vpd->vpd_blkno > last_movedin_block)
+ last_movedin_block = vtmove[i].vpd->vpd_blkno; /*
* Set t_ctid pointing to itself for last tuple in
***************
*** 1610,1615 ****
--- 1617,1624 ----
newtup.t_data = (HeapTupleHeader) PageGetItem(ToPage, newitemid);
ItemPointerSet(&(newtup.t_data->t_ctid), cur_page->vpd_blkno, newoff);
newtup.t_self = newtup.t_data->t_ctid;
+ if (cur_page->vpd_blkno > last_movedin_block)
+ last_movedin_block = cur_page->vpd_blkno; /*
* Mark old tuple as moved_off by vacuum and store vacuum XID
From bouncefilter Sun Jan 9 23:23:37 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA72309
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 23:23:05 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA07469;
Sun, 9 Jan 2000 23:21:59 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001100421.XAA07469@candle.pha.pa.us>
Subject: Re: Postgres Features for 7.X
In-Reply-To: <001901bf5b16$f558aa20$1401a8c0@MWK.co.nz> from John Huttley at
"Jan 10, 2000 04:01:14 pm"
To: John Huttley <john@mwk.co.nz>
Date: Sun, 9 Jan 2000 23:21:59 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
Hello Bruce,
I've just remembered the other problem with PG that needs to be listed for
fixing.This is the 7 field index limit
If the need is for a index for the purpose of unique-ness enforcing, there
needs to be more than 7 fields.My system needed about 12.
I am working on this now. 7.0 will have a postgres.h parameter that can
be changed. Default is 8.
--
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 Jan 9 23:32:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA74472
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 23:31:52 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA01889;
Sun, 9 Jan 2000 23:31:49 -0500 (EST)
To: Stephen Birch <sbirch@ironmountainsystems.com>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re:HEAP_MOVED_IN during vacuum - test case
In-reply-to: <3878D740.78479672@ironmountainsystems.com>
References: <Pine.BSF.4.21.0001040915250.18498-100000@thelab.hub.org>
<13280.947001513@sss.pgh.pa.us>
<3878D740.78479672@ironmountainsystems.com>
Comments: In-reply-to Stephen Birch <sbirch@ironmountainsystems.com>
message dated "Sun, 09 Jan 2000 10:45:20 -0800"
Date: Sun, 09 Jan 2000 23:31:49 -0500
Message-ID: <1886.947478709@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Stephen Birch <sbirch@ironmountainsystems.com> writes:
I have now created a test case that demonstrate the HEAP_MOVED_IN during
vacuum problem.
OK, I've sussed it. Dunno if you want the details, but briefly: the
code was using the last element of a list of target pages (pages that
had room to insert more tuples) as a sentinel point to know when to
stop trying to move tuples out of source pages. But there was also
an optimization in there to remove target pages from the target list
as soon as they got full (so as not to keep checking them). Sure
enough, with the right data pattern it was possible to remove the
last modified page from the target-page list before the source loop
got to it, and then everything falls over. I'm surprised we haven't
heard more complaints about this, actually --- it doesn't look like
the failure should be all that unlikely.
I have committed what I think is a proper fix into current sources,
but I don't really think it should be trusted until it's been through
a beta test cycle. Instead, attached is a very low-risk patch that
just dikes out the code that tries to remove target pages early.
This will result in some marginal slowdown when vacuuming huge
relations, but I think it should be safe to plug into production
6.5.* servers.
Thanks again for the narrowly focused test case --- I suspect you
put quite a bit of time into developing it...
regards, tom lane
*** src/backend/commands/vacuum.c.orig Tue Jan 4 12:27:26 2000
--- src/backend/commands/vacuum.c Sun Jan 9 23:16:10 2000
***************
*** 1253,1258 ****
--- 1253,1259 ----
{
if (!vc_enough_space(to_vpd, tlen))
{
+ #if 0 /* this code is broken */
if (to_vpd != last_fraged_page &&
!vc_enough_space(to_vpd, vacrelstats->min_tlen))
{
***************
*** 1263,1268 ****
--- 1264,1270 ----
num_fraged_pages--;
Assert(last_fraged_page == fraged_pages->vpl_pagedesc[num_fraged_pages - 1]);
}
+ #endif
for (i = 0; i < num_fraged_pages; i++)
{
if (vc_enough_space(fraged_pages->vpl_pagedesc[i], tlen))
***************
*** 1517,1522 ****
--- 1519,1525 ----
WriteBuffer(cur_buffer);
cur_buffer = InvalidBuffer;+ #if 0 /* this code is broken */
/*
* If no one tuple can't be added to this page -
* remove page from fraged_pages. - vadim 11/27/96
***************
*** 1534,1539 ****
--- 1537,1543 ----
num_fraged_pages--;
Assert(last_fraged_page == fraged_pages->vpl_pagedesc[num_fraged_pages - 1]);
}
+ #endif
}
for (i = 0; i < num_fraged_pages; i++)
{From bouncefilter Sun Jan 9 23:36:33 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA76837
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 23:36:15 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id XAA14659
for pgsql-hackers@postgreSQL.org; Sun, 9 Jan 2000 23:35:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001100435.XAA14659@candle.pha.pa.us>
Subject: Number of index fields configurable
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Sun, 9 Jan 2000 23:35:17 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have moved INDEX_MAX_KEYS to postgres.h, and have removed the
hard-coded limits that it is 8 fields. I hope I got all of them. The
default is still 8.
There were only a few places left that had the 8 hard-coded.
I haven't tested non-8 values but they should work.
--
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 Jan 9 23:49:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA78600
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 23:48:40 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA02022;
Sun, 9 Jan 2000 23:48:32 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Stephen Birch" <sbirch@ironmountainsystems.com>,
"PostgreSQL-development" <pgsql-hackers@postgreSQL.org>,
"The Hermit Hacker" <scrappy@hub.org>
Subject: Re: [HACKERS] Re:HEAP_MOVED_IN during vacuum - test case
In-reply-to: <000301bf5b17$41f342a0$2801007e@tpf.co.jp>
References: <000301bf5b17$41f342a0$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Mon, 10 Jan 2000 12:03:23 +0900"
Date: Sun, 09 Jan 2000 23:48:31 -0500
Message-ID: <2019.947479711@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
The following patch seems to fix your case.
However I'm not sure it's a right solution.
That looks like nearly the same logic that I arrived at, although
what I committed included some additional code cleanups. As I said
in my prior message, I don't fully trust it yet --- but I am glad
you came to the same conclusion.
regards, tom lane
From bouncefilter Sun Jan 9 23:57:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA80111
for <pgsql-hackers@postgreSQL.org>; Sun, 9 Jan 2000 23:56:58 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA02071;
Sun, 9 Jan 2000 23:56:21 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: John Huttley <john@mwk.co.nz>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Postgres Features for 7.X
In-reply-to: <200001100421.XAA07469@candle.pha.pa.us>
References: <200001100421.XAA07469@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sun, 09 Jan 2000 23:21:59 -0500"
Date: Sun, 09 Jan 2000 23:56:21 -0500
Message-ID: <2068.947480181@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I've just remembered the other problem with PG that needs to be listed for
fixing.This is the 7 field index limit
It's 8, not 7, afaik...
I am working on this now. 7.0 will have a postgres.h parameter that can
be changed. Default is 8.
I looked at this a while ago and realized that the fundamental problem
is that pg_index depends on types oid8 and int28 (hardwired 8-element
arrays of oid and int2, respectively). Are you going to rename these
types to oidN and int2N and make the value of N a config parameter?
Seems like a good idea ... but that magic constant 8 is buried in
a depressingly large number of places, a lot of which aren't even
symbolic constants :-(
If you do fix this, I'd suggest bumping the default N up to 16 or so;
seems like that would make a lot of people happier than N=8...
regards, tom lane
From bouncefilter Mon Jan 10 00:04:34 2000
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 AAA84656
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 00:04:16 -0500 (EST) (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 OAA01468; Mon, 10 Jan 2000 14:03:58 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "PostgreSQL-development" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Number of index fields configurable
Date: Mon, 10 Jan 2000 14:09:25 +0900
Message-ID: <000401bf5b28$dd3c4fc0$2801007e@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: <200001100435.XAA14659@candle.pha.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce MomjianI have moved INDEX_MAX_KEYS to postgres.h, and have removed the
hard-coded limits that it is 8 fields. I hope I got all of them. The
default is still 8.There were only a few places left that had the 8 hard-coded.
I haven't tested non-8 values but they should work.
Shouldn't the following catalog be changed ?
CATALOG(pg_index)
{
....
int28 indkey;
^^^^^
oid8 indclass;
^^^^^
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Jan 10 00:17:33 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA86639
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 00:17:31 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA19314;
Mon, 10 Jan 2000 00:16:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001100516.AAA19314@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Postgres Features for 7.X
In-Reply-To: <2068.947480181@sss.pgh.pa.us> from Tom Lane at "Jan 9,
2000 11:56:21 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 10 Jan 2000 00:16:26 -0500 (EST)
CC: John Huttley <john@mwk.co.nz>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I've just remembered the other problem with PG that needs to be listed for
fixing.This is the 7 field index limit
It's 8, not 7, afaik...
Oh, OK.
I am working on this now. 7.0 will have a postgres.h parameter that can
be changed. Default is 8.I looked at this a while ago and realized that the fundamental problem
is that pg_index depends on types oid8 and int28 (hardwired 8-element
arrays of oid and int2, respectively). Are you going to rename these
types to oidN and int2N and make the value of N a config parameter?
Seems like a good idea ... but that magic constant 8 is buried in
a depressingly large number of places, a lot of which aren't even
symbolic constants :-(
I have looked at every 8 in the source tree, and I think I have them
all. I have now moved INDEX_MAX_KEYS to config.h.in, where it belongs.
I have not changed the type names. I am going to keep them called int28
and oid8 until we decide we want them to be 16 and I will change the
type names. They function fine as oid8 even if they are 16 long. :-)
I am not sure how the index code handles this so I am a little scared to
bump it up by default.
There was really only some code in oid8in and int28in that required
recoding because the sscanf was using 8 params. The new code loops
over an sscanf. The other changes were just replacement of 8 with the
define.
If you do fix this, I'd suggest bumping the default N up to 16 or so;
seems like that would make a lot of people happier than N=8...
Oh, OK, just make it 16. That should work, and be a good way to test my
changes. However, I am not sure everything will work so I will keep it
at 8 until we can test it to see what happens. Only very large data
sets with very long indexes is going to trigger the index code.
May as well see if someone _knows_ if the index code will work with >8
indexed fields.
--
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 Jan 10 00:19:33 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA86794
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 00:18:39 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA20027;
Mon, 10 Jan 2000 00:17:49 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001100517.AAA20027@candle.pha.pa.us>
Subject: Re: [HACKERS] Number of index fields configurable
In-Reply-To: <000401bf5b28$dd3c4fc0$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 10, 2000 02:09:25 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 10 Jan 2000 00:17:49 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce MomjianI have moved INDEX_MAX_KEYS to postgres.h, and have removed the
hard-coded limits that it is 8 fields. I hope I got all of them. The
default is still 8.There were only a few places left that had the 8 hard-coded.
I haven't tested non-8 values but they should work.
Shouldn't the following catalog be changed ?
CATALOG(pg_index)
{
....
int28 indkey;
^^^^^
oid8 indclass;
^^^^^
The underlying definitions of the types are now based in the #define
parameter. Not sure if this is going to work so I have not change the
actual type names yet. I have a few more changes to commit now.
Also, what should the new names be? Can't call it int16. Does anyone
outside the source tree rely on those type names?
--
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 Jan 10 00:25:34 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA87857
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 00:24:57 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA21380;
Mon, 10 Jan 2000 00:24:13 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001100524.AAA21380@candle.pha.pa.us>
Subject: oid8in and int28in
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 10 Jan 2000 00:24:13 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
OK, I have fixed int28in and oid8 so they properly skip over the
spaces. Thanks to Tom for the tip.
--
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 Jan 10 00:45:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA93698
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 00:44:40 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA02423;
Mon, 10 Jan 2000 00:44:33 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Number of index fields configurable
In-reply-to: <200001100517.AAA20027@candle.pha.pa.us>
References: <200001100517.AAA20027@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 10 Jan 2000 00:17:49 -0500"
Date: Mon, 10 Jan 2000 00:44:33 -0500
Message-ID: <2420.947483073@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Shouldn't the following catalog be changed ?
CATALOG(pg_index)
{
....
int28 indkey;
^^^^^
oid8 indclass;
^^^^^
The underlying definitions of the types are now based in the #define
parameter. Not sure if this is going to work so I have not change the
actual type names yet. I have a few more changes to commit now.
If we think the parameter works, then we should test it by changing
the value ;-)
Also, what should the new names be? Can't call it int16.
I like oidN and int2N, or oidn and int2n if you object to uppercase
names.
Does anyone outside the source tree rely on those type names?
I was worried about that at first --- we couldn't change the names
if it would break pg_dump files. But the system catalogs themselves
don't get dumped as such, so it shouldn't be a problem. There might
be a few folks out there who are using oid8 or int28 as column types
in user tables, but surely not many. What it comes down to is that
a few people might have to tweak their code or dump files, but not
very many compared to the number of people who will be glad of the
improvement.
But if these types are to have parameterizable sizes, I think it's
critical that oidNin() and int2Nin() be robust about the number of
input values they see. I suggest that they ought to work like this:
* if the number of supplied values is less than the currently configured
value of N, silently fill in zeroes for the extra places.
* if the number of supplied values is more than N, check the extra
values to see if any are not 0. Complain if any are not 0, but
if they are all 0 then silently accept it.
This will allow interoperability of pg_dump files across different
values of N, and raise an error only if there's really a problem.
You have the first behavior but not the second...
regards, tom lane
From bouncefilter Mon Jan 10 01:33:34 2000
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 BAA08188
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 01:33:01 -0500 (EST) (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 PAA01513 for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 15:32:59 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Cache invalidation was changed a little
Date: Mon, 10 Jan 2000 15:38:27 +0900
Message-ID: <000501bf5b35$4d6f5740$2801007e@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 V5.00.2314.1300
Importance: Normal
Hi
I have just committed changes to cache invalidation stuff.
Maybe this would fix the following TODO.
* elog() flushes cache, try invalidating just entries from current xact,
perhaps using invalidation cache
1) In case of abort,catalog cache and relation cache will
be invalidated for system tuples marked by Relation-
Mark4RollbackHeapTuple(). Both heap_insert() and
heap_update() call RelationMark4RollbackHeapTuple().
2) CommandCounterIncrement() calls AtCommit_LocalCache()
instead of AtCommit_Cache(). Registration of cache
invalidation for other backends was postponed until commit.
3) The new function ImmediateSharedRelationCacheInvalidate()
is called from smgrunlink()/smgrtruncate() in order to register
relation cache invalidation immediately.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Jan 10 02:26:35 2000
Received: from onestone.elsinore.klever.net (root@onestone.elsinore.klever.net
[207.175.129.2]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA15633
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 02:25:46 -0500 (EST)
(envelope-from sbirch@ironmountainsystems.com)
Received: from ironmountainsystems.com (ppp34.kross.klever.net
[209.203.65.34]) by onestone.elsinore.klever.net (8.8.7/8.8.0)
with ESMTP id AAA28837; Mon, 10 Jan 2000 00:22:28 -0800
Sender: sbirch@onestone.elsinore.klever.net
Message-ID: <38798939.4D96DAE0@ironmountainsystems.com>
Date: Sun, 09 Jan 2000 23:24:41 -0800
From: Stephen Birch <sbirch@ironmountainsystems.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-SMP i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
The Hermit Hacker <scrappy@hub.org>
Subject: Re: [HACKERS] Re:HEAP_MOVED_IN during vacuum - test case
References: <000301bf5b17$41f342a0$2801007e@tpf.co.jp>
<2019.947479711@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I still can't believe how fast you guys are, but would like to thank
you.
If I understood the vacuum logic, I would check your fixes, but it is
still black magic to me!! I did try the new code against the full
database and found no problems. As far as I can tell, you found it.
Thanks again.
Steve
Tom Lane wrote:
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
The following patch seems to fix your case.
However I'm not sure it's a right solution.That looks like nearly the same logic that I arrived at, although
what I committed included some additional code cleanups. As I said
in my prior message, I don't fully trust it yet --- but I am glad
you came to the same conclusion.regards, tom lane
From bouncefilter Mon Jan 10 04:05:36 2000
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 EAA39240
for <pgsql-hackers@postgresql.org>;
Mon, 10 Jan 2000 04:05:22 -0500 (EST)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 127alM-000GZJ-0C; Mon, 10 Jan 2000 09:05:20 +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 JAA24539;
Mon, 10 Jan 2000 09:55:27 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <CPRD824D>; Mon, 10 Jan 2000 09:04:58 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70C06A@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Allan Huffman'" <huffmana@ppc.pims.org>, pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] make JDBC postgresql.jar error
Date: Mon, 10 Jan 2000 09:04:53 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
the $$ syntax is where make passes $ to the command line. ie it should
pass something like:
`java makeVersion`
Anyhow, you can bypass this, by running one of the jdbc2 or java2 rules
instead of all.
Peter
--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.
-----Original Message-----
From: Allan Huffman [mailto:huffmana@ppc.pims.org]
Sent: Friday, January 07, 2000 4:41 PM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] make JDBC postgresql.jar error
I'm trying to compile the src/interfaces/jdbc postgresql.jar file but I
get a syntax error (pg 6.5.2):
/bin/sh: syntax error at line 1: '(' unexpected
make: *** [all] Error 2
Funny thing is that I'm under the C shell.....using gcc, Solaris 7 on a
Sparc.
I tried to replace $( ) with ' ' per the instructions but there is some
syntax that I am not familiar with: $$($(JAVA) makeVersion). How should
this look after the replacement?
Really appreciate help. I've developed 3k SLOC under Visual Cafe
(managed to rewrite out all Symantec classes). It's running fine in the
Visual Cafe environment. Now I need to field it under the Netscape
Suitespot server.
Thanks
Allan in Belgium
************
From bouncefilter Mon Jan 10 09:12:24 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA31634
for <pgsql-hackers@postgresql.org>;
Mon, 10 Jan 2000 09:11:50 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max05-055.enterprise.net
[194.72.197.55])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id OAA27659
for <pgsql-hackers@postgresql.org>; Mon, 10 Jan 2000 14:11:46 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id OAA21493
for <pgsql-hackers@postgresql.org>; Mon, 10 Jan 2000 14:11:34 GMT
Message-Id: <200001101411.OAA21493@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: pgsql-hackers@postgresql.org
Subject: Shared library version
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 10 Jan 2000 14:11:30 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
There appear to have been changes in the shared library libpq.
The default library from 6.5.3 with psql from current tree gives:
olly@linda$ psql template1
...
psql: error in loading shared libraries: psql: undefined symbol:
createPQExpBuffer
olly@linda$ LD_PRELOAD=/usr/local/pgsql/lib/libpq.so.2.0 psql template1
...
template1=>
Since the library has changed, it needs to have a new version number.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Be patient therefore, brethren, unto the coming of the
Lord...Be patient; strengthen your hearts, for
the coming of the Lord draweth nigh."
James 5:7,8
From bouncefilter Mon Jan 10 09:15:25 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA31880
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 09:14:47 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
JAA06981;
Mon, 10 Jan 2000 09:11:55 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001101411.JAA06981@candle.pha.pa.us>
Subject: Re: [HACKERS] Number of index fields configurable
In-Reply-To: <2420.947483073@sss.pgh.pa.us> from Tom Lane at "Jan 10,
2000 00:44:33 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 10 Jan 2000 09:11:55 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Shouldn't the following catalog be changed ?
CATALOG(pg_index)
{
....
int28 indkey;
^^^^^
oid8 indclass;
^^^^^The underlying definitions of the types are now based in the #define
parameter. Not sure if this is going to work so I have not change the
actual type names yet. I have a few more changes to commit now.If we think the parameter works, then we should test it by changing
the value ;-)Also, what should the new names be? Can't call it int16.
I like oidN and int2N, or oidn and int2n if you object to uppercase
names.
How about oidvector and int2vector. A vector is a 1-dimmensional array.
Calling it an array is too confusing.
Does anyone outside the source tree rely on those type names?
I was worried about that at first --- we couldn't change the names
if it would break pg_dump files. But the system catalogs themselves
don't get dumped as such, so it shouldn't be a problem. There might
be a few folks out there who are using oid8 or int28 as column types
in user tables, but surely not many. What it comes down to is that
a few people might have to tweak their code or dump files, but not
very many compared to the number of people who will be glad of the
improvement.
But if these types are to have parameterizable sizes, I think it's
critical that oidNin() and int2Nin() be robust about the number of
input values they see. I suggest that they ought to work like this:* if the number of supplied values is less than the currently configured
value of N, silently fill in zeroes for the extra places.* if the number of supplied values is more than N, check the extra
values to see if any are not 0. Complain if any are not 0, but
if they are all 0 then silently accept it.This will allow interoperability of pg_dump files across different
values of N, and raise an error only if there's really a problem.
I will tweek the code to properly check for trailing numbers. Right now
multiple spaces cause problems, and trailing numbers are ignored. With
oidn, we can get away with trailing zeros because an oid of 0 is
invalid, but with int2n, a zero is valid, so I think we can't just ignore
extra trailing zeros. We can pad with zeros, however. Comments?
--
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 Jan 10 10:07:25 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA47089
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 10:07:03 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA08934;
Mon, 10 Jan 2000 10:06:05 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001101506.KAA08934@candle.pha.pa.us>
Subject: Re: [HACKERS] Shared library version
In-Reply-To: <200001101411.OAA21493@linda.lfix.co.uk> from Oliver Elphick at
"Jan 10, 2000 02:11:30 pm"
To: Oliver Elphick <olly@lfix.co.uk>
Date: Mon, 10 Jan 2000 10:06:05 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
There appear to have been changes in the shared library libpq.
The default library from 6.5.3 with psql from current tree gives:
olly@linda$ psql template1
...
psql: error in loading shared libraries: psql: undefined symbol:
createPQExpBufferolly@linda$ LD_PRELOAD=/usr/local/pgsql/lib/libpq.so.2.0 psql template1
...
template1=>Since the library has changed, it needs to have a new version number.
Seems I should just kick up every minor version number for 7.0 for all
interfaces. OK?
--
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 Jan 10 10:07:25 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA47133
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 10:07:13 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA03042;
Mon, 10 Jan 2000 10:06:58 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Number of index fields configurable
In-reply-to: <200001101411.JAA06981@candle.pha.pa.us>
References: <200001101411.JAA06981@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 10 Jan 2000 09:11:55 -0500"
Date: Mon, 10 Jan 2000 10:06:58 -0500
Message-ID: <3039.947516818@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I will tweek the code to properly check for trailing numbers. Right now
multiple spaces cause problems, and trailing numbers are ignored. With
oidn, we can get away with trailing zeros because an oid of 0 is
invalid, but with int2n, a zero is valid, so I think we can't just ignore
extra trailing zeros. We can pad with zeros, however. Comments?
For the primary use of these things, which is attribute numbers in
pg_index, padding or dropping zeroes is correct behavior --- unused
positions in the vector will have zero values, same as for the oid
vector. I think it's OK to define the type's behavior suitably for
the system's use, because it's not intended as a general-purpose user
type; users oughta be using int2[]. (Really, the only reason we have
these types at all is that we depend on having compile-time-constant
field sizes in the system catalogs that are accessed via
include/catalog/'s struct declarations...)
regards, tom lane
From bouncefilter Mon Jan 10 10:23:25 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA49261
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 10:22:51 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA03158;
Mon, 10 Jan 2000 10:22:45 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Shared library version
In-reply-to: <200001101411.OAA21493@linda.lfix.co.uk>
References: <200001101411.OAA21493@linda.lfix.co.uk>
Comments: In-reply-to "Oliver Elphick" <olly@lfix.co.uk>
message dated "Mon, 10 Jan 2000 14:11:30 +0000"
Date: Mon, 10 Jan 2000 10:22:44 -0500
Message-ID: <3155.947517764@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Oliver Elphick" <olly@lfix.co.uk> writes:
There appear to have been changes in the shared library libpq.
Since the library has changed, it needs to have a new version number.
You're right, we need to bump the number before release (and I hope we
remember!). Past practice has not been to bump the number during
development cycles, since we'd shortly have ridiculously high version
numbers if we incremented them at every development change.
libpq++ has also had API changes requiring a new version number before
release, I think --- any others?
regards, tom lane
From bouncefilter Mon Jan 10 10:39:26 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA54684
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 10:38:33 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA11409;
Mon, 10 Jan 2000 10:37:32 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001101537.KAA11409@candle.pha.pa.us>
Subject: Re: [HACKERS] Number of index fields configurable
In-Reply-To: <2420.947483073@sss.pgh.pa.us> from Tom Lane at "Jan 10,
2000 00:44:33 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 10 Jan 2000 10:37:32 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
But if these types are to have parameterizable sizes, I think it's
critical that oidNin() and int2Nin() be robust about the number of
input values they see. I suggest that they ought to work like this:* if the number of supplied values is less than the currently configured
value of N, silently fill in zeroes for the extra places.* if the number of supplied values is more than N, check the extra
values to see if any are not 0. Complain if any are not 0, but
if they are all 0 then silently accept it.This will allow interoperability of pg_dump files across different
values of N, and raise an error only if there's really a problem.
OK, different solution. I decided there is no need to be dumping out
zeros to pad the type. New code does the following. This looks very
clean to me:
test=> create table x (y int28);
CREATE
test=> insert into x values ('1 2 3');
INSERT 18697 1
test=> select * from x;
y
-------
1 2 3
(1 row)
test=> insert into x values ('1 2 3 4 5 6 7 8');
INSERT 18699 1
test=> select * from x;
y
-----------------
1 2 3
1 2 3 4 5 6 7 8
(3 rows)
test=> insert into x values ('1 2 3 4 5 6 7 8 9');
ERROR: int28 value has too many values
test=> insert into x values ('1 2 3 4 5 6 7 8 0');
ERROR: int28 value has too many values
Notice the trailing zero is treated as an error. Because we trim
trailing zeros, we can affort do handle things this way.
--
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 Jan 10 10:44:27 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA55323
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 10:44:08 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA03266
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 10:44:07 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Potential vacuum bug?
Date: Mon, 10 Jan 2000 10:44:07 -0500
Message-ID: <3263.947519047@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
While chasing the VACUUM problem reported by Stephen Birch, I noticed
something that looks like a potential trouble spot. Vacuum's initial
scan routine, vc_scanheap, runs through the table to mark tuples as
known committed or known dead, if possible (consulting the transaction
log for tuples not yet so marked). It does the right things as far as
marking committed/dead if it sees a tuple marked HEAP_MOVED_OFF or
HEAP_MOVED_IN, which could only be there if a prior VACUUM failed
partway through. But it doesn't *clear* those bits. Seems to me that
that will screw up the subsequent vc_rpfheap procedure --- in
particular, leaving a HEAP_MOVED_IN flag set will cause vc_rpfheap to
complain (correctly!) about 'HEAP_MOVED_IN not expected', whereas
leaving HEAP_MOVED_OFF set will confuse vc_rpfheap because it will
think it moved the tuple itself.
In short, if we really want to recover from a failed VACUUM then we'd
better clear those bits during vc_scanheap. I am thinking that the
code starting at about line 720 ought to look like
if (!(tuple.t_data->t_infomask & HEAP_XMIN_COMMITTED))
{
if (tuple.t_data->t_infomask & HEAP_XMIN_INVALID)
tupgone = true;
else if (tuple.t_data->t_infomask & HEAP_MOVED_OFF)
{
// mark tuple commited or invalid as appropriate,
// same as before
add >>> tuple.t_data->t_infomask &= ~HEAP_MOVED_OFF;
}
else if (tuple.t_data->t_infomask & HEAP_MOVED_IN)
{
// mark tuple commited or invalid as appropriate,
// same as before
add >>> tuple.t_data->t_infomask &= ~HEAP_MOVED_IN;
}
else
{
// other cases same as before
}
}
add >>> if (tuple.t_data->t_infomask & (HEAP_MOVED_OFF | HEAP_MOVED_IN))
add >>> {
add >>> elog(NOTICE, "Clearing unexpected HEAP_MOVED flag");
add >>> tuple.t_data->t_infomask &= ~(HEAP_MOVED_OFF | HEAP_MOVED_IN);
add >>> pgchanged = true;
add >>> }
Comments anyone?
regards, tom lane
From bouncefilter Mon Jan 10 10:55:26 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA58216
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 10:54:46 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA03337;
Mon, 10 Jan 2000 10:54:32 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Number of index fields configurable
In-reply-to: <200001101537.KAA11409@candle.pha.pa.us>
References: <200001101537.KAA11409@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 10 Jan 2000 10:37:32 -0500"
Date: Mon, 10 Jan 2000 10:54:31 -0500
Message-ID: <3334.947519671@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
OK, different solution. I decided there is no need to be dumping out
zeros to pad the type.
Oh, that's a thought. You haven't really gained anything in generality,
since the code is still treating zero as a special case; but I agree it
looks nicer (and is easier to check for too many values).
Only worry I have is whether it will interoperate comfortably with the
old code. Let's see:
* old dump to new: no problem, unless you've reduced MAX_INDEX_KEYS
below 8 (doesn't seem likely).
* new to old: fails for every case except where there's exactly 8
non zero entries.
The latter is a bit bothersome, but may not be a big deal --- in reality
we don't dump and reload pg_index this way.
BTW, be sure you are only suppressing *trailing* zeroes not *embedded*
zeroes. I know that oid8 has to deal with embedded zeroes (some of
the pg_proc entries look like that); int28 might not, but the code
should probably act the same for both.
regards, tom lane
From bouncefilter Mon Jan 10 11:01:26 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA59556
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 11:00:45 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA14020;
Mon, 10 Jan 2000 10:59:47 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001101559.KAA14020@candle.pha.pa.us>
Subject: Re: [HACKERS] Number of index fields configurable
In-Reply-To: <3334.947519671@sss.pgh.pa.us> from Tom Lane at "Jan 10,
2000 10:54:31 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 10 Jan 2000 10:59:46 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
OK, different solution. I decided there is no need to be dumping out
zeros to pad the type.Oh, that's a thought. You haven't really gained anything in generality,
since the code is still treating zero as a special case; but I agree it
looks nicer (and is easier to check for too many values).Only worry I have is whether it will interoperate comfortably with the
old code. Let's see:* old dump to new: no problem, unless you've reduced MAX_INDEX_KEYS
below 8 (doesn't seem likely).* new to old: fails for every case except where there's exactly 8
non zero entries.
Not sure about this. Old code did sscanf on 8 entries, but if it
returned fewer, it padded with zeros, so new->old should work.
The latter is a bit bothersome, but may not be a big deal --- in reality
we don't dump and reload pg_index this way.BTW, be sure you are only suppressing *trailing* zeroes not *embedded*
zeroes. I know that oid8 has to deal with embedded zeroes (some of
the pg_proc entries look like that); int28 might not, but the code
should probably act the same for both.
Yes, only trailing. New code walks from end to beginning until it finds
a non-zero. If the entry is all zeros, you get a zero-length string
output.
--
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 Jan 10 11:03:26 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA62341
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 11:02:35 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA03410;
Mon, 10 Jan 2000 11:02:27 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Number of index fields configurable
In-reply-to: <200001101559.KAA14020@candle.pha.pa.us>
References: <200001101559.KAA14020@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 10 Jan 2000 10:59:46 -0500"
Date: Mon, 10 Jan 2000 11:02:26 -0500
Message-ID: <3407.947520146@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
* new to old: fails for every case except where there's exactly 8
non zero entries.
Not sure about this. Old code did sscanf on 8 entries, but if it
returned fewer, it padded with zeros, so new->old should work.
Oh, OK. Nevermind then...
regards, tom lane
From bouncefilter Mon Jan 10 11:09:26 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id LAA63123
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 11:09:05 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 13155 invoked by uid 1001); 10 Jan 2000 16:09:06 -0000
Date: Mon, 10 Jan 2000 11:09:06 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: pgsql-hackers@postgreSQL.org
Subject: Simmultanous Connections (fwd)
Message-ID: <Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Can anyone here help?
Vince.
---------- Forwarded message ----------
Date: Mon, 10 Jan 2000 08:52:06 +0000
From: Jude Weaver <exec@shreve.net>
To: webmaster@postgresql.org
Subject: Simmultanous Connections
We are a company that writes academic software . We are converting our
software to use either PostgreSQL or MySQL. We are leaning toward
PostgreSQL, but, I still have several questions.
I hope someone can answer these for me.
1. I have read the Q&A for postgreSQL and would like to know the
difference between a temporary
and a permanant connection. Do you have a connection when you open
the database or only when
the frontend sends a job to the backend? If 32 people are running
a module that opens a database
is that 32 connections or will it vary as users read and write to
the database?
2. I saw in the Q&A that to run more than 32 simmultanous connects could
be a big drain on our re-
sources. Our Linux boxes , in general, are Intel 166 to 500s, 128MG
of RAM and 6.2 to 13 GIG.
Can anyone tell me roughly how much resources per connection does
PostgreSQL use?
3. If I have 90 teachers posting grades at the same time, (the grade
posting program opens 5 dif-
ferent databases) and 25 secretaries and administrators poking
around in assorted databases
looking at information, will postgresql handle that much traffic?
I would appreciate any information you can give me,
Thank you - Jude Weaver.
From bouncefilter Mon Jan 10 11:13:26 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA63772
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 11:13:00 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA15630;
Mon, 10 Jan 2000 11:09:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001101609.LAA15630@candle.pha.pa.us>
Subject: Re: [HACKERS] Number of index fields configurable
In-Reply-To: <3039.947516818@sss.pgh.pa.us> from Tom Lane at "Jan 10,
2000 10:06:58 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 10 Jan 2000 11:09:36 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I will tweek the code to properly check for trailing numbers. Right now
multiple spaces cause problems, and trailing numbers are ignored. With
oidn, we can get away with trailing zeros because an oid of 0 is
invalid, but with int2n, a zero is valid, so I think we can't just ignore
extra trailing zeros. We can pad with zeros, however. Comments?For the primary use of these things, which is attribute numbers in
pg_index, padding or dropping zeroes is correct behavior --- unused
positions in the vector will have zero values, same as for the oid
vector. I think it's OK to define the type's behavior suitably for
the system's use, because it's not intended as a general-purpose user
type; users oughta be using int2[]. (Really, the only reason we have
these types at all is that we depend on having compile-time-constant
field sizes in the system catalogs that are accessed via
include/catalog/'s struct declarations...)
Renamed oid8 ->oidvector and int28->int2vector. initdb everyone. New
type names require 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 Jan 10 11:27:26 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA66110
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 11:26:59 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA16449;
Mon, 10 Jan 2000 11:24:45 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001101624.LAA16449@candle.pha.pa.us>
Subject: oid8/int28
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 10 Jan 2000 11:24:44 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tom, I can't find any cases where 7 or 9 are used to represent the
maximum number of attributes indexed.
--
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 Jan 10 11:47:26 2000
Received: from alert.infoplease.com (range.infoplease.com [208.222.166.25])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA71672
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 11:47:01 -0500 (EST)
(envelope-from kdebisschop@range.infoplease.com)
Received: from skillet.infoplease.com (skillet [10.0.1.212])
by alert.infoplease.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02620;
Mon, 10 Jan 2000 11:46:22 -0500 (EST)
Received: (from kdebisschop@localhost)
by skillet.infoplease.com (8.9.3/8.9.1) id LAA22111;
Mon, 10 Jan 2000 11:46:27 -0500
Date: Mon, 10 Jan 2000 11:46:27 -0500
Message-Id: <200001101646.LAA22111@skillet.infoplease.com>
X-Authentication-Warning: skillet.infoplease.com: kdebisschop set sender to
kdebisschop@spaceheater.infoplease.com using -f
From: Karl DeBisschop <kdebisschop@range.infoplease.com>
To: vev@michvhf.com
CC: pgsql-hackers@postgreSQL.org
In-reply-to: <Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
(message from Vince Vielhaber on Mon, 10 Jan 2000 11:09:06 -0500
(EST))
Subject: Re: [HACKERS] Simmultanous Connections (fwd)
Reply-to: kdebisschop@range.infoplease.com
References: <Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
Can anyone here help?
Vince.
---------- Forwarded message ----------
Date: Mon, 10 Jan 2000 08:52:06 +0000
From: Jude Weaver <exec@shreve.net>
To: webmaster@postgresql.org
Subject: Simmultanous ConnectionsWe are a company that writes academic software . We are converting our
software to use either PostgreSQL or MySQL. We are leaning toward
PostgreSQL, but, I still have several questions.
I hope someone can answer these for me.1. I have read the Q&A for postgreSQL and would like to know the
difference between a temporary
and a permanant connection. Do you have a connection when you open
the database or only when
the frontend sends a job to the backend? If 32 people are running
a module that opens a database
is that 32 connections or will it vary as users read and write to
the database?
Sounds like she may looking at postgres in PHP - at least PHP uses
that temporary and permanant connection concept. My experience is
that PHP persistent connections are not worth it - the time to
establish a new connection is pretty small, and stale connections can
cause problems.
2. I saw in the Q&A that to run more than 32 simmultanous connects could
be a big drain on our re-
sources. Our Linux boxes , in general, are Intel 166 to 500s, 128MG
of RAM and 6.2 to 13 GIG.
Can anyone tell me roughly how much resources per connection does
PostgreSQL use?
If an idle psql connection is left open, we're looking at about 1 MB
RAM plus 4MB swap on my linux box.
As I noted above, I'd generally recommend against persistent
connections when there are more than a few users.
Sounds like the machines have the capacity for what sounds like a
fairly small task. Of course, there would generally be only one
server machine, so I would recommend choosing one of the faster ones.
But it should be stable and usable ath eith end of the spectrum, at
least from my experience.
3. If I have 90 teachers posting grades at the same time, (the grade
posting program opens 5 dif-
ferent databases) and 25 secretaries and administrators poking
around in assorted databases
looking at information, will postgresql handle that much traffic?
Postgres should handle that easily.
Just my $0.02 worth. Hope it's helpful.
--
Karl DeBisschop <kdebisschop@alert.infoplease.com>
617.832.0332 (Fax: 617.956.2696)
Information Please - your source for FREE online reference
http://www.infoplease.com - Your Ultimate Fact Finder
http://kids.infoplease.com - The Great Homework Helper
Netsaint Plugins Development
http://netsaintplug.sourceforge.net
From bouncefilter Mon Jan 10 11:48:26 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA71767
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 11:47:32 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA40276;
Mon, 10 Jan 2000 12:46:46 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 10 Jan 2000 12:46:41 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Vince Vielhaber <vev@michvhf.com>
cc: exec@shreve.net, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Simmultanous Connections (fwd)
In-Reply-To: <Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
Message-ID: <Pine.BSF.4.21.0001101236110.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 10 Jan 2000, Vince Vielhaber wrote:
1. I have read the Q&A for postgreSQL and would like to know the
difference between a temporary and a permanant connection. Do you have
a connection when you open the database or only when the frontend
sends a job to the backend? If 32 people are running a module that
opens a database is that 32 connections or will it vary as users read
and write to the database?
You will have 32 connections open to the backend ...
2. I saw in the Q&A that to run more than 32 simmultanous connects
could be a big drain on our re- sources. Our Linux boxes , in general,
are Intel 166 to 500s, 128MG of RAM and 6.2 to 13 GIG. Can anyone
tell me roughly how much resources per connection does PostgreSQL use?
It depends on what the connections are doing...if someone is doing a
'SELECT...ORDER BY', it will take more resources then if you are doing
something that doesn't involve any sort routines...
3. If I have 90 teachers posting grades at the same time, (the grade
posting program opens 5 dif- ferent databases) and 25 secretaries and
administrators poking around in assorted databases looking at
information, will postgresql handle that much traffic?
5 different databases, vs 5 different tables? 5 different
databases will mean 90 x 5 (450) connections opened up...whereas 5 tables
would be just 90 connections...
... but, either way, will it handle that much traffic? give it
enough RAM, and I personally don't see why not, but I've yet to hit *that*
kind of a load on it. Right now, I have PostgreSQL setup to handle
several databases, and the postmaster processes each take up ~4-5Meg:
hub> ps aux | grep data
pgsql 895 0.0 0.2 4508 1416 d0- S 6:52AM 0:00.98 /home/database/v
pgsql 896 0.0 0.2 3976 1308 d0- I 6:52AM 0:00.02 /home/database/v
When I open up a session/connection to a database, I'm seeing:
pgsql 71041 5.1 0.4 5028 3492 ?? R 11:40AM 0:00.54 /home/database/v
pgsql 71032 0.0 0.4 4992 3148 ?? S 11:40AM 0:00.02 /home/database/v
pgsql 71034 0.0 0.4 4980 2976 ?? S 11:40AM 0:00.02 /home/database/v
Now, I always get this backwards/confused, but...the first value (ie. 4508) is
the binary size, which is mis-informed due to the use of shared libraries...
the important one is the second value (ie. 1416), which, again, if I recall
correctly, is the datasize...for the udmsearch database, just starting up
'psql udmsearch', each database is taking <3.5Meg...depending on the sizes of
your queries and whatnot, figure that I'd need 3.5Meg*450 (~1.5gig) of memory
on this machine to handle it (I have half of that now)...bear in mind that
not all 450 connections would be active, so there is room for some processes
to be swap'd out and whatnot..
My personal opinion is that there isn't anything that PostgreSQL hasn't been
able to handle so far, to the best of my knowledge...my next step for my
system is to go dual-processor, and bring on a full gig of RAM, but my machine
also does alot more then just PostgreSQL :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Jan 10 12:11:27 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA77755
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 12:10:42 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id MAA17654
for pgsql-hackers@postgreSQL.org; Mon, 10 Jan 2000 12:10:00 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001101710.MAA17654@candle.pha.pa.us>
Subject: Number of args to a function configurable
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 10 Jan 2000 12:10:00 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have created a new define FUNC_MAX_ARGS which is has the same value as
INDEX_MAX_KEYS. Currently they are both 8, but I think they can now be
changed to higher values.
I removed two old maxfuncarg defines that were 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 Mon Jan 10 13:12:27 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA93641
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 13:11:35 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id KAA01715;
Mon, 10 Jan 2000 10:11:06 -0800 (PST)
Message-Id: <3.0.1.32.20000110100724.00f4c1e0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 10 Jan 2000 10:07:24 -0800
To: kdebisschop@range.infoplease.com, vev@michvhf.com
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Simmultanous Connections (fwd)
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <200001101646.LAA22111@skillet.infoplease.com>
References: <Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
<Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:46 AM 1/10/00 -0500, Karl DeBisschop wrote:
Sounds like she may looking at postgres in PHP - at least PHP uses
that temporary and permanant connection concept. My experience is
that PHP persistent connections are not worth it - the time to
establish a new connection is pretty small, and stale connections can
cause problems.
Boy, persistent connections in AOLserver sure help a lot (ask Lamar
Owen!). If stale connections cause problems in your PHP environment,
then the PHP persistent connection implementation needs some work.
Forking a new backend is actually considerably more expensive then
just passing back the PID of an existing backend...
On Sun Solaris systems, forking is about 25 times as costly as
starting up a new thread (according to data from Sun). Of course,
returning an existing persistent db connection's even cheaper than
starting a new thread. And that comparative cost will vary between
OS.
But not necessarily in a direction favoring more forking :)
I sent her a private note saying she really probably shouldn't be looking
at MySQL for her application, presumably having a real transaction-based
db is a Good Thing when maintaining a database of student grades. Told
her she should be looking at various real RDBMS solutions and should leave
MySQL out of the picture entirely (while also telling her I thought PG
would work fine for her needs, of course).
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 10 13:36:28 2000
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 NAA02321
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 13:35:58 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id NAA01213;
Mon, 10 Jan 2000 13:35:45 -0500
Message-ID: <387A267A.DC418FCD@wgcr.org>
Date: Mon, 10 Jan 2000 13:35:38 -0500
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: Don Baccus <dhogaza@pacifier.com>
CC: kdebisschop@range.infoplease.com, vev@michvhf.com,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Simmultanous Connections (fwd)
References: <Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
<Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
<3.0.1.32.20000110100724.00f4c1e0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 11:46 AM 1/10/00 -0500, Karl DeBisschop wrote:
Sounds like she may looking at postgres in PHP - at least PHP uses
that temporary and permanant connection concept. My experience is
that PHP persistent connections are not worth it - the time to
establish a new connection is pretty small, and stale connections can
cause problems.
Boy, persistent connections in AOLserver sure help a lot (ask Lamar
Owen!). If stale connections cause problems in your PHP environment,
then the PHP persistent connection implementation needs some work.
Let's work some math.
Under AOLserver, using the pooled connection paradigm that it uses, for
5 databases, you would need to define 5 pools. You then can control how
many instances of each pool can be opened at any given time. So, if all
databases need the same number of connections average, you raise the max
on pool instances until users quit getting busy messages during normal
usage -- which usually , for a small number of users (~25 here), is only
2 or 3 instances.
The persistent pooled model avoids fork() penalties -- after all, there
is overhead there, regardless of how small that overhead may be.
I have gone as far as reducing the instances to 1 here -- it's amazing
how few people actually do simultaneous accesses! I currently am
running with an instance max of 3 -- and users get busy's very rarely.
With 90 users on a single database with 5 tables, an instance max of
10-20 would probably give less than a 10% busy rate. And, as you add
more RAM, you can up your instance max to adjust.
I don't know how close to the AOLserver model PHP is (I think it is
pretty close, as the beta of PHP4 is buildable to run as a module under
AOLserver), but the concept of pooled persistent connections is a sound
one, and eliminates some grief (as long as you watch your transactions
-- don't want two connections that happen to share a pool instance to
share a transaction roolback!). Plus, you can service that required
nnumber of users at varying satisfaction/busy levels depending upon your
current server resources.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Mon Jan 10 13:39:28 2000
Received: from alert.infoplease.com (range.infoplease.com [208.222.166.25])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA02708
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 13:39:17 -0500 (EST)
(envelope-from kdebisschop@range.infoplease.com)
Received: from skillet.infoplease.com (skillet [10.0.1.212])
by alert.infoplease.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04248;
Mon, 10 Jan 2000 13:38:09 -0500 (EST)
Received: (from kdebisschop@localhost)
by skillet.infoplease.com (8.9.3/8.9.1) id NAA27928;
Mon, 10 Jan 2000 13:38:14 -0500
Date: Mon, 10 Jan 2000 13:38:14 -0500
Message-Id: <200001101838.NAA27928@skillet.infoplease.com>
X-Authentication-Warning: skillet.infoplease.com: kdebisschop set sender to
kdebisschop@spaceheater.infoplease.com using -f
From: Karl DeBisschop <kdebisschop@range.infoplease.com>
To: dhogaza@pacifier.com
CC: vev@michvhf.com, pgsql-hackers@postgreSQL.org
In-reply-to: <3.0.1.32.20000110100724.00f4c1e0@mail.pacifier.com> (message
from Don Baccus on Mon, 10 Jan 2000 10:07:24 -0800)
Subject: Re: [HACKERS] Simmultanous Connections (fwd)
Reply-to: kdebisschop@range.infoplease.com
References: <Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
<Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
<3.0.1.32.20000110100724.00f4c1e0@mail.pacifier.com>
Boy, persistent connections in AOLserver sure help a lot (ask Lamar
Owen!). If stale connections cause problems in your PHP environment,
then the PHP persistent connection implementation needs some work.
This isn't really a hackers issue, so I'll try to be brief but also
give a little more info than I originally did. Maybe any further
discussion would be best placed in pgsql-general.
Basically, I think it may depend on the use - for our website, we get
connections from a variety of sources - most of them don't repeat for
a long time, if ever. Which means a bunch sit around at any given
time, never to be reused. If the new connections come fast enough,
this can translate to real problems unless they timeout quickly, which
defeats the purpose.
That being said, maybe the PHP implementaion does need some work, or
maybe there are site parameters we could tune to make it work. But
whenever we use it, we do eventually end up in trouble as a result.
So, personally, I don't recommend it in situations where alot of
different clients will be connecting to the DBMS - at least if low
maintennence is a key goal.
Forking a new backend is actually considerably more expensive then
just passing back the PID of an existing backend...
From the point of view of the server, absolutely. But that connection
time is still a very small part of the user's total trransaction time.
And, although I am making alot of guesses as to the nature of the
planned DB will be, my guess is that overall machine load will not be
so high that the process forking becomes critical. My guess is that
support will be hard to come by in alot of public school environments,
so I'd guess their building for trouble-free operation before speed.
I sent her a private note saying she really probably shouldn't be looking
at MySQL for her application, presumably having a real transaction-based
db is a Good Thing when maintaining a database of student grades. Told
her she should be looking at various real RDBMS solutions and should leave
MySQL out of the picture entirely (while also telling her I thought PG
would work fine for her needs, of course).
That's a good summary of my intended take-home point as well, though
you said it much more clearly. All the rest was just personal
experience that applies to our environment but my not apply to yours
or hers.
Karl
From bouncefilter Mon Jan 10 13:53:28 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA04565
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 13:53:00 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id NAA00581
for pgsql-hackers@postgreSQL.org; Mon, 10 Jan 2000 13:51:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001101851.NAA00581@candle.pha.pa.us>
Subject: Changing oidvector length
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 10 Jan 2000 13:51:17 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
We have the oidvector and int2vector length's set in pg_type.h. Is
there any way to make those values configurable from defines in
config.h?
If not, I will have to move the defines to postgres.h so people can not
change them. Maybe that is a better place for them anyway.
--
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 Jan 10 14:23:28 2000
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 OAA17804
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 14:22:30 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <ZW4G67SS>; Mon, 10 Jan 2000 21:19:14 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C419@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Bruce Momjian '" <pgman@candle.pha.pa.us>, "'Oliver Elphick '"
<olly@lfix.co.uk>
Cc: "'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Shared library version
Date: Mon, 10 Jan 2000 21:07:41 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
Well, this function was introduced, because the query string limit was
removed from the libpq library. However, I don't believe that any other
libraries have been worked on.
MikeA
-----Original Message-----
From: Bruce Momjian
To: Oliver Elphick
Cc: pgsql-hackers@postgreSQL.org
Sent: 00/01/10 05:06
Subject: Re: [HACKERS] Shared library version
There appear to have been changes in the shared library libpq.
The default library from 6.5.3 with psql from current tree gives:
olly@linda$ psql template1
...
psql: error in loading shared libraries: psql: undefined symbol:
createPQExpBufferolly@linda$ LD_PRELOAD=/usr/local/pgsql/lib/libpq.so.2.0 psql
template1
...
template1=>Since the library has changed, it needs to have a new version number.
Seems I should just kick up every minor version number for 7.0 for all
interfaces. OK?
--
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 Jan 10 14:44:28 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA24014
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 14:43:50 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA06252;
Mon, 10 Jan 2000 11:43:07 -0800 (PST)
Message-Id: <3.0.1.32.20000110112345.00f4c1e0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 10 Jan 2000 11:23:45 -0800
To: Lamar Owen <lamar.owen@wgcr.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Simmultanous Connections (fwd)
Cc: kdebisschop@range.infoplease.com, vev@michvhf.com,
pgsql-hackers@postgreSQL.org
In-Reply-To: <387A267A.DC418FCD@wgcr.org>
References: <Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
<Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
<3.0.1.32.20000110100724.00f4c1e0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 01:35 PM 1/10/00 -0500, Lamar Owen wrote:
I don't know how close to the AOLserver model PHP is (I think it is
pretty close, as the beta of PHP4 is buildable to run as a module under
AOLserver), but the concept of pooled persistent connections is a sound
one, and eliminates some grief (as long as you watch your transactions
-- don't want two connections that happen to share a pool instance to
share a transaction roolback!).
Spoken like a long-suffering user of AOLserver's original postgres
driver :)
I've solved this particular problem in the latest version of the driver,
and other problems related to backends crashing and the like. This is
why I suggest that if there are problems with PHPs persistent database
connections and Postgres that the PHP implementation of such connections
needs work. I know from experience that persistent pooled connections
can be implemented in a non-robust fashion (the old postgres driver for
AOLserver) but I also know that they can be made robust, from personal
experience.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 10 14:44:29 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA24001
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 14:43:41 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA06258;
Mon, 10 Jan 2000 11:43:09 -0800 (PST)
Message-Id: <3.0.1.32.20000110114052.00f48af0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 10 Jan 2000 11:40:52 -0800
To: kdebisschop@range.infoplease.com
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Simmultanous Connections (fwd)
Cc: vev@michvhf.com, pgsql-hackers@postgreSQL.org
In-Reply-To: <200001101838.NAA27928@skillet.infoplease.com>
References: <3.0.1.32.20000110100724.00f4c1e0@mail.pacifier.com>
<Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
<Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
<3.0.1.32.20000110100724.00f4c1e0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 01:38 PM 1/10/00 -0500, Karl DeBisschop wrote:
This isn't really a hackers issue, so I'll try to be brief but also
give a little more info than I originally did. Maybe any further
discussion would be best placed in pgsql-general.
Perhaps. I'll give one brief answer here, though. It probably
doesn't hurt the developers to see how their product is used in
real-life scenarios anyway...
Basically, I think it may depend on the use - for our website, we get
connections from a variety of sources - most of them don't repeat for
a long time, if ever. Which means a bunch sit around at any given
time, never to be reused. If the new connections come fast enough,
this can translate to real problems unless they timeout quickly, which
defeats the purpose.
That being said, maybe the PHP implementaion does need some work, or
maybe there are site parameters we could tune to make it work. But
whenever we use it, we do eventually end up in trouble as a result.
My short answer: yes, it does need work if it works as you describe.
The whole point of pooling persistent connections is to allow re-use.
It sounds like either PHP makes it hard/impossible or that (maybe?)
you folks haven't quite figured out how fully exploit their implementation
of pooled connections.
So, personally, I don't recommend it in situations where alot of
different clients will be connecting to the DBMS - at least if low
maintennence is a key goal.
The problem isn't persistent connections, the problem is the particular
implementation you're using. AOLserver's implementation is trouble
free, for Postgres, Sybase, Oracle, and Solid. And totally
transparent to scripts and dynamic pages (other than SQL differences
due to the dbs themselves). The PHP folks are making it available
within AOLserver, as Lamar Owen has pointed out. If they also plug
into the AOLserver implementation of pooled persistent database
connections, then PHP users will also have a platform available which
reliably supports such connections.
Forking a new backend is actually considerably more expensive then
just passing back the PID of an existing backend...From the point of view of the server, absolutely. But that connection
time is still a very small part of the user's total trransaction time.
Depends on how you're using the database. If you're using it to
personalize pages, for instance, you'll be using a lot of simple,
quick selects. If you're only using the database for complicated,
slow queries then perhaps you're right.
Let's put it this way ... folks who have a lot more experience than
me at running very busy database-backed web sites have observed that it
DOES make a large difference in the scalability of a site. These,
though, are sites make heavy use of the database when serving up
pages.
If forking weren't a problem, the Apache folks wouldn't've bothered
building modPerl, for instance...
And, although I am making alot of guesses as to the nature of the
planned DB will be, my guess is that overall machine load will not be
so high that the process forking becomes critical. My guess is that
support will be hard to come by in alot of public school environments,
so I'd guess their building for trouble-free operation before speed.
Nothing to disagree with here, other than the fact that my own
personal experience tells me that persistent connections needn't be a
source of trouble. If they are PHP users, though, and if the
site really is using PHP as you suspect, then they should probably
avoid them if your experience is an accurate reflection of the state
of the implementation of persistent connections available to PHP
users.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 10 15:10:29 2000
Received: from onestone.elsinore.klever.net (root@onestone.elsinore.klever.net
[207.175.129.2]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA31525
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 15:09:58 -0500 (EST)
(envelope-from sbirch@ironmountainsystems.com)
Received: from ironmountainsystems.com (ppp27.kross.klever.net
[209.203.65.27]) by onestone.elsinore.klever.net (8.8.7/8.8.0)
with ESMTP id NAA25093; Mon, 10 Jan 2000 13:06:12 -0800
Sender: sbirch@onestone.elsinore.klever.net
Message-ID: <387A3C41.C5BE5DD3@ironmountainsystems.com>
Date: Mon, 10 Jan 2000 12:08:33 -0800
From: Stephen Birch <sbirch@ironmountainsystems.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-SMP i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Vince Vielhaber <vev@michvhf.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Simmultanous Connections (fwd)
References: <Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
When I was researching PG vs MySQL - the big kicker was transaction support
(mySQL doesn't have it). It looks like MySQL is faster than PG and so is
great for serving data to a web site. But if you also need to perform
updates to multiple tables, you probably will want to use transactions - so
use PostgreSQL.
I chose PostgreSQL for this reason.
The PostgreSQL team is incredible. To try and contribute a little, we
switched our development from the released software to the PG development
software (so we can report, and sometimes fix problems) - any bugs we
discovered but couldn't fix ourselves were fixed within hours. Our own
modifications were checked and entered in their development tree in less
than an hour. Cool.
The code itself is of very high quality.
Steve
Vince Vielhaber wrote:
Can anyone here help?
Vince.
---------- Forwarded message ----------
Date: Mon, 10 Jan 2000 08:52:06 +0000
From: Jude Weaver <exec@shreve.net>
To: webmaster@postgresql.org
Subject: Simmultanous ConnectionsWe are a company that writes academic software . We are converting our
software to use either PostgreSQL or MySQL. We are leaning toward
PostgreSQL, but, I still have several questions.
I hope someone can answer these for me.1. I have read the Q&A for postgreSQL and would like to know the
difference between a temporary
and a permanant connection. Do you have a connection when you open
the database or only when
the frontend sends a job to the backend? If 32 people are running
a module that opens a database
is that 32 connections or will it vary as users read and write to
the database?2. I saw in the Q&A that to run more than 32 simmultanous connects could
be a big drain on our re-
sources. Our Linux boxes , in general, are Intel 166 to 500s, 128MG
of RAM and 6.2 to 13 GIG.
Can anyone tell me roughly how much resources per connection does
PostgreSQL use?3. If I have 90 teachers posting grades at the same time, (the grade
posting program opens 5 dif-
ferent databases) and 25 secretaries and administrators poking
around in assorted databases
looking at information, will postgresql handle that much traffic?I would appreciate any information you can give me,
Thank you - Jude Weaver.************
From bouncefilter Tue Jan 11 03:27:23 2000
Received: from p3E9D3DF5.dip0.t-ipconnect.de
(root@p3E9D3DF5.dip0.t-ipconnect.de [62.157.61.245])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA94793
for <pgsql-hackers@postgresql.org>;
Tue, 11 Jan 2000 03:26:10 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id VAA02221
for pgsql-hackers@postgresql.org; Mon, 10 Jan 2000 21:18:17 +0100
Date: Mon, 10 Jan 2000 21:18:17 +0100
From: Michael Meskes <meskes@postgresql.org>
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Shared library version
Message-ID: <20000110211817.A2212@fam-meskes.de>
Mail-Followup-To: pgsql-hackers@postgresql.org
References: <200001101411.OAA21493@linda.lfix.co.uk>
<3155.947517764@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <3155.947517764@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Mon, Jan 10, 2000 at 10:22:44AM -0500
On Mon, Jan 10, 2000 at 10:22:44AM -0500, Tom Lane wrote:
You're right, we need to bump the number before release (and I hope we
remember!). Past practice has not been to bump the number during
development cycles, since we'd shortly have ridiculously high version
numbers if we incremented them at every development change.
Ehem... I do exactly that with libecpg. For simply changes not involving API
changes I increment just the patch level. That's why libecpg has major
version, minor version and patchlevel.
I find it very difficult to keep track of the changes without changing
version number.
So please, do not change this number upon release.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Mon Jan 10 15:50:29 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA40204
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 15:49:35 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id PAA24868
for pgsql-hackers@postgreSQL.org; Mon, 10 Jan 2000 15:47:47 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001102047.PAA24868@candle.pha.pa.us>
Subject: cvs tree is broken
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 10 Jan 2000 15:47:47 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have tried updating the max arg/index lengths to 16, but initdb is now
failing. Any ideas? I am looking for the cause, but can't find 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 Jan 10 18:12:31 2000
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 SAA73247
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 18:11:40 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id SAA29727
for pgsql-hackers@postgreSQL.org; Mon, 10 Jan 2000 18:08:05 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001102308.SAA29727@candle.pha.pa.us>
Subject: initdb fixed
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 10 Jan 2000 18:08:05 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have found the problem. Fixing now. Current source will work.
--
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 Jan 10 19:30:32 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA88838
for <pgsql-hackers@postgresql.org>;
Mon, 10 Jan 2000 19:30:06 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA07396;
Mon, 10 Jan 2000 19:30:01 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] oid8/int28
In-reply-to: <200001101624.LAA16449@candle.pha.pa.us>
References: <200001101624.LAA16449@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 10 Jan 2000 11:24:44 -0500"
Date: Mon, 10 Jan 2000 19:30:01 -0500
Message-ID: <7393.947550601@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Tom, I can't find any cases where 7 or 9 are used to represent the
maximum number of attributes indexed.
Could be they're all gone; I know I've seen some in the past though.
Some brave soul should try increasing the constant and then using
indexes with > 8 columns... better compile -g and --enable-casserts ;-)
regards, tom lane
From bouncefilter Mon Jan 10 19:36:32 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA92553
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 19:36:18 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA07434;
Mon, 10 Jan 2000 19:35:57 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Changing oidvector length
In-reply-to: <200001101851.NAA00581@candle.pha.pa.us>
References: <200001101851.NAA00581@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 10 Jan 2000 13:51:17 -0500"
Date: Mon, 10 Jan 2000 19:35:57 -0500
Message-ID: <7431.947550957@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
We have the oidvector and int2vector length's set in pg_type.h. Is
there any way to make those values configurable from defines in
config.h?
If not, I will have to move the defines to postgres.h so people can not
change them. Maybe that is a better place for them anyway.
Actually, I suspect they should be in postgres_ext.h, which is where
NAMEDATALEN is. All of these values are potentially visible to code
outside Postgres, so postgres_ext.h seems like the right place.
config.h would be appropriate for something you could tweak without
changing the external API of Postgres...
regards, tom lane
From bouncefilter Mon Jan 10 19:53:32 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA94677
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 19:52:49 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA07561;
Mon, 10 Jan 2000 19:52:46 -0500 (EST)
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Changing oidvector length
In-reply-to: <7431.947550957@sss.pgh.pa.us>
References: <200001101851.NAA00581@candle.pha.pa.us>
<7431.947550957@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
message dated "Mon, 10 Jan 2000 19:35:57 -0500"
Date: Mon, 10 Jan 2000 19:52:46 -0500
Message-ID: <7558.947551966@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
You have:
#define FUNC_MAX_ARGS (INDEX_MAX_KEYS+1)
This is WRONG, I'm pretty sure --- FUNC_MAX_ARGS should be the same
as the length of oidvector.
User-declared functions can definitely only have as many args as there
are slots in oidvector, because that's all the room there is to declare
them in pg_proc.
You may have gotten confused because fmgr.c allowed 9 args to be passed,
even though there's no way to declare such a function; I think this was
a hack to support some special system usage --- possibly selectivity
estimators had 9 args at one time. (They don't now, so the 9th-arg
support was dead code as far as I can tell.) But if we are going to
increase the default MAX_ARGS above 8 then the issue goes away anyway,
and there's no need for fmgr.c to support more args than can normally
be declared.
regards, tom lane
From bouncefilter Mon Jan 10 20:31:32 2000
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 UAA04078
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 20:31:17 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA01288;
Mon, 10 Jan 2000 20:25:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001110125.UAA01288@candle.pha.pa.us>
Subject: Re: [HACKERS] Changing oidvector length
In-Reply-To: <7558.947551966@sss.pgh.pa.us> from Tom Lane at "Jan 10,
2000 07:52:46 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 10 Jan 2000 20:25:14 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
You have:
#define FUNC_MAX_ARGS (INDEX_MAX_KEYS+1)
This is WRONG, I'm pretty sure --- FUNC_MAX_ARGS should be the same
as the length of oidvector.User-declared functions can definitely only have as many args as there
are slots in oidvector, because that's all the room there is to declare
them in pg_proc.
I was going to ask about that. The original value for this was 9, while
oid8 was only 8 long. When I went to 16, FUNC_MAX_ARGS has to 17 or
initdb fails on int4in. No idea why, and want to ask if anyone knows
why this is required. I know it should be 16, but I can't figure out
why it doesn't work at 16, only at 17.
You may have gotten confused because fmgr.c allowed 9 args to be passed,
even though there's no way to declare such a function; I think this was
a hack to support some special system usage --- possibly selectivity
btbuild, I believe.
estimators had 9 args at one time. (They don't now, so the 9th-arg
support was dead code as far as I can tell.) But if we are going to
increase the default MAX_ARGS above 8 then the issue goes away anyway,
and there's no need for fmgr.c to support more args than can normally
be declared.
--
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 Jan 10 20:53:33 2000
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 UAA07241
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 20:53:10 -0500 (EST) (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 KAA01860; Tue, 11 Jan 2000 10:52:58 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Potential vacuum bug?
Date: Tue, 11 Jan 2000 10:58:27 +0900
Message-ID: <000101bf5bd7$5a2a96a0$2801007e@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
In-Reply-To: <3263.947519047@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom LaneWhile chasing the VACUUM problem reported by Stephen Birch, I noticed
something that looks like a potential trouble spot. Vacuum's initial
scan routine, vc_scanheap, runs through the table to mark tuples as
known committed or known dead, if possible (consulting the transaction
log for tuples not yet so marked). It does the right things as far as
marking committed/dead if it sees a tuple marked HEAP_MOVED_OFF or
HEAP_MOVED_IN, which could only be there if a prior VACUUM failed
partway through. But it doesn't *clear* those bits. Seems to me that
that will screw up the subsequent vc_rpfheap procedure --- in
particular, leaving a HEAP_MOVED_IN flag set will cause vc_rpfheap to
complain (correctly!) about 'HEAP_MOVED_IN not expected', whereas
leaving HEAP_MOVED_OFF set will confuse vc_rpfheap because it will
think it moved the tuple itself.
I'm for your change.
Anyway it's not good to hold useless flags unnecessarily.
However I could hardly find the case that would cause a trouble.
It may occur in the following rare cases though I'm not sure.
HEAP_MOVED_OFF and (neither HEAP_XMIN_COMMITTED nor
HEAP_XMIN_INVALID) and the tuple was recently delete/updated.
This means that the previous VACUUM couldn't remove the tuple
because old transactions were running then and moreover the
VACUUM half successed(i.e aborted between internal commit and
external commit). Now VACUUM marks this tuple as tupgone once
but would turn it off later if old transctions are still running.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Jan 10 21:27:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA13590
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 21:26:32 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA14296;
Mon, 10 Jan 2000 21:25:51 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Changing oidvector length
In-reply-to: <200001110125.UAA01288@candle.pha.pa.us>
References: <200001110125.UAA01288@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 10 Jan 2000 20:25:14 -0500"
Date: Mon, 10 Jan 2000 21:25:51 -0500
Message-ID: <14293.947557551@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
You may have gotten confused because fmgr.c allowed 9 args to be passed,
even though there's no way to declare such a function; I think this was
a hack to support some special system usage --- possibly selectivitybtbuild, I believe.
Ah, you are right (it just blew up on me when I tried it at eight ;-)).
But if we are going to
increase the default MAX_ARGS above 8 then the issue goes away anyway,
and there's no need for fmgr.c to support more args than can normally
be declared.
This still holds though --- we will just require INDEX_MAX_ARGS to be
at least 9 from here on out...
regards, tom lane
From bouncefilter Mon Jan 10 21:49:33 2000
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 VAA18903
for <pgsql-hackers@postgreSQL.org>;
Mon, 10 Jan 2000 21:49:08 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA03529;
Mon, 10 Jan 2000 21:34:48 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001110234.VAA03529@candle.pha.pa.us>
Subject: Re: [HACKERS] Changing oidvector length
In-Reply-To: <14293.947557551@sss.pgh.pa.us> from Tom Lane at "Jan 10,
2000 09:25:51 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 10 Jan 2000 21:34:48 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
You may have gotten confused because fmgr.c allowed 9 args to be passed,
even though there's no way to declare such a function; I think this was
a hack to support some special system usage --- possibly selectivitybtbuild, I believe.
Ah, you are right (it just blew up on me when I tried it at eight ;-)).
But if we are going to
increase the default MAX_ARGS above 8 then the issue goes away anyway,
and there's no need for fmgr.c to support more args than can normally
be declared.This still holds though --- we will just require INDEX_MAX_ARGS to be
at least 9 from here on out...
But it bombs on 16.
--
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 Jan 11 00:34:35 2000
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 AAA56382
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 00:33:36 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA20114;
Tue, 11 Jan 2000 00:14:50 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001110514.AAA20114@candle.pha.pa.us>
Subject: zeros in oidvector type
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 11 Jan 2000 00:14:50 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tom, why are the non-trailing zeros in the *vector types as initialized
in the catalog/*.h files.
You mentioned you knew what they meant.
--
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 Jan 11 00:55:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA62538
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 00:55:14 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA27524;
Tue, 11 Jan 2000 00:55:10 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: zeros in oidvector type
In-reply-to: <200001110514.AAA20114@candle.pha.pa.us>
References: <200001110514.AAA20114@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 11 Jan 2000 00:14:50 -0500"
Date: Tue, 11 Jan 2000 00:55:10 -0500
Message-ID: <27521.947570110@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Tom, why are the non-trailing zeros in the *vector types as initialized
in the catalog/*.h files.
You mentioned you knew what they meant.
In pg_proc's proargtypes entries, a zero in a valid argument position
(ie, one of the first 'pronargs' positions) can mean either "any type
is acceptable" or "opaque argument type" (not sure if those are quite
the same thing or not!) or "C string input to a datatype's typinput
conversion routine" (definitely not the same thing).
The entries in pg_proc.h call out these zeroes explicitly even when
they are trailing arguments --- generally, the number of values shown
in the proargtypes column should equal pronargs.
I don't think there's any good way for oidvectorout to duplicate that
string, if that's what you were wondering about; oidvectorout has no
access to the value of pronargs.
Someday I would like to replace these special meanings of "zero type
oid" with definite nonzero type OIDs (this has been discussed before,
at least for the C-string case). Then the issue goes away.
BTW, I just managed to pass the regression tests with INDEX_MAX_KEYS
set to 10. Will commit a couple more fixes momentarily. Next thing
is to see if functions and indexes with >8 args actually work...
regards, tom lane
From bouncefilter Tue Jan 11 01:03:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA66245
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 01:03:23 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA27770
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 01:03:22 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: INDEX_MAX_KEYS = 16 ... it works, too
Date: Tue, 11 Jan 2000 01:03:22 -0500
Message-ID: <27767.947570602@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
At least it passes regress tests --- haven't tried making an index
with more than 8 keys yet.
I just committed config.h.in with default settings of
INDEX_MAX_KEYS = FUNC_MAX_ARGS = 16. This forces initdb!
regards, tom lane
From bouncefilter Tue Jan 11 04:41:38 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA10369
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 04:41:28 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max02-047.enterprise.net
[194.72.195.167])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id JAA02090;
Tue, 11 Jan 2000 09:41:22 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id JAA28524;
Tue, 11 Jan 2000 09:40:56 GMT
Message-Id: <200001110940.JAA28524@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Shared library version
In-Reply-To: Message from Tom Lane <tgl@sss.pgh.pa.us>
of "Mon, 10 Jan 2000 10:22:44 EST." <3155.947517764@sss.pgh.pa.us>
References: <200001101411.OAA21493@linda.lfix.co.uk>
<3155.947517764@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 11 Jan 2000 09:40:56 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Tom Lane wrote:
"Oliver Elphick" <olly@lfix.co.uk> writes:
There appear to have been changes in the shared library libpq.
Since the library has changed, it needs to have a new version number.You're right, we need to bump the number before release (and I hope we
remember!). Past practice has not been to bump the number during
development cycles, since we'd shortly have ridiculously high version
numbers if we incremented them at every development change.
Yes, but it should be bumped the first time it changes; I agree that it
need not be increased during later development of the same release.
A patch would be superfluous. The necessary change is simply to
increment SO_MINOR_VERSION in src/interfaces/libpq/Makefile
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Enter into his gates with thanksgiving, and into his
courts with praise. Be thankful unto him, and bless
his name." Psalms 100:4
From bouncefilter Tue Jan 11 05:47:39 2000
Received: from vulcan.ifnet.com.br (vulcan.ifnet.com.br [200.203.210.18])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA23244
for <pgsql-hackers@postgresql.org>;
Tue, 11 Jan 2000 05:47:05 -0500 (EST)
(envelope-from mateus@ifnet.com.br)
Received: from ifnet.com.br (IDENT:root@async-28.56k-ppp-gw-01.ifnet.com.br
[200.203.210.155])
by vulcan.ifnet.com.br (8.9.3/8.9.3) with ESMTP id IAA14963
for <pgsql-hackers@postgresql.org>; Tue, 11 Jan 2000 08:46:23 -0200
Received: (from mateus@localhost) by ifnet.com.br (8.9.3/8.9.3) id IAA12054;
Tue, 11 Jan 2000 08:45:51 -0200
From: Mateus Cordeiro Inssa <mateus@ifnet.com.br>
Message-ID: <14459.2527.373177.219445@Blaublau.home.br>
Date: Tue, 11 Jan 2000 08:45:51 -0200 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Simmultanous Connections (fwd)
In-Reply-To: <200001101646.LAA22111@skillet.infoplease.com>
References: <Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
<200001101646.LAA22111@skillet.infoplease.com>
X-Mailer: VM 6.71 under 21.1 (patch 4) "Arches" XEmacs Lucid
X-Face: "|YUb*(O#,z=WN#Ez3~WeW{ZQ2w<Y/?6t>t-lKh/"d:#gq~!Bl&q+_,z+|KAB1C'oqyF_;
P O=40^mm!nklMDs:aXGjL4C1EcM\yMJsA8:F[9
Karl DeBisschop writes:
Sounds like she may looking at postgres in PHP - at least PHP uses
that temporary and permanant connection concept. My experience is
that PHP persistent connections are not worth it - the time to
establish a new connection is pretty small, and stale connections can
cause problems.2. I saw in the Q&A that to run more than 32 simmultanous connects could
be a big drain on our re-
sources. Our Linux boxes , in general, are Intel 166 to 500s, 128MG
of RAM and 6.2 to 13 GIG.
Can anyone tell me roughly how much resources per connection does
PostgreSQL use?If an idle psql connection is left open, we're looking at about 1 MB
RAM plus 4MB swap on my linux box.As I noted above, I'd generally recommend against persistent
connections when there are more than a few users.
As an example, I have systems with 2 or 3 hundred simultaneos
connections and besides being short time connections it's impossible to
have 200 or 300 backends running at the same time.
In this case, I had to create a proxy to use few connections. I have
AF_INET and AF_UNIX versions.
[]'s
Mateus Cordeiro Inssa
---------------------
Linux User: 76186 Kernel: 2.3.36
ICQ (Licq): 15243895
---------------------
mateus@ifnet.com.br
mateus@cwb.fnn.net
Tue Jan 11 08:45:00 EDT 2000
From bouncefilter Tue Jan 11 06:41:39 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA41502
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 06:41:28 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
GAA04436;
Tue, 11 Jan 2000 06:36:42 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001111136.GAA04436@candle.pha.pa.us>
Subject: Re: zeros in oidvector type
In-Reply-To: <27521.947570110@sss.pgh.pa.us> from Tom Lane at "Jan 11,
2000 00:55:10 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 11 Jan 2000 06:36:42 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Tom, why are the non-trailing zeros in the *vector types as initialized
in the catalog/*.h files.You mentioned you knew what they meant.
In pg_proc's proargtypes entries, a zero in a valid argument position
(ie, one of the first 'pronargs' positions) can mean either "any type
is acceptable" or "opaque argument type" (not sure if those are quite
the same thing or not!) or "C string input to a datatype's typinput
conversion routine" (definitely not the same thing).The entries in pg_proc.h call out these zeroes explicitly even when
they are trailing arguments --- generally, the number of values shown
in the proargtypes column should equal pronargs.
The reason I ask is that there are some parts of the code that try to
find the number of args by looking for the _first_ non-zero entry in the
list. I changed those to look for the _last_ non-zero entry, but it
sounds like that is still wrong.
--
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
On 2000-01-08, Tom Lane mentioned:
Chris Griffin <cgriffin@websales.com> writes:
# setenv PGDATA2 /web/sites/1.192/db-data
# initlocation PGDATA2
# createdb -D PGDATA2Surely you want $PGDATA2 in the latter two lines?
You might recall me mentioning that the whole alternative location
business doesn't work in the first place. I'll fix that this week; Chris
will have to wait until the next release.
--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 11 08:27:41 2000
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 IAA60672
for <hackers@postgresql.org>; Tue, 11 Jan 2000 08:27:20 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63342 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sSmyH32773>; Tue, 11 Jan 2000 14:26:43 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 1281QY-0001SK-00; Tue, 11 Jan 2000 14:33:38 +0100
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Regression tests
In-Reply-To: <387220DC.91A41302@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0001110136190.7876-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Date: Tue, 11 Jan 2000 14:26:43 +0100
Just as I was thinking about putting in a "compatibility mode". This whole
psql output thing is a really tough issue and I think it won't be
completely resolved until Jan. 31st ...
On 2000-01-04, Thomas Lockhart mentioned:
I've started going through the regression tests and updating for the
new psql output. The first few tests have been committed, and I'll try
working through the others in the next few days.I've also updated the test queries to use the extended SQL92 type
coersion syntax rather than the older, non-standard Postgres "::"
notation. I'll still keep some "::" queries somewhere so that the
syntax continues to be tested...- Thomas
--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 11 08:27:43 2000
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 IAA60675
for <hackers@postgresql.org>; Tue, 11 Jan 2000 08:27:23 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63367 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sSmyI38926>; Tue, 11 Jan 2000 14:26:44 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 1281Qd-0001Sa-00
for hackers@postgresql.org; Tue, 11 Jan 2000 14:33:43 +0100
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: Who fried this?
Message-ID: <Pine.LNX.4.21.0001111425590.5432-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Date: Tue, 11 Jan 2000 14:26:44 +0100
What went wrong here? This is from a freshly updated and compiled source.
peter ~$ pg-install/bin/initdb -D $HOME/pg-install/data
This database system will be initialized with username "peter".
This user will own all the data files and must also own the server
process.
Creating database system directory /home/peter/pg-install/data
Creating database system directory /home/peter/pg-install/data/base
Creating database XLOG directory /home/peter/pg-install/data/pg_xlog
Creating template database in /home/peter/pg-install/data/base/template1
ERROR: TypeCreate: function 'int4in(opaque)' does not exist
ERROR: TypeCreate: function 'int4in(opaque)' does not exist
Creating global relations in /home/peter/pg-install/data/base
Adding template1 database to pg_database
initdb failed.
Removing /home/peter/pg-install/data.
I don't feel like digging this up now, surely someone must have noticed
it.
--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 11 08:27:48 2000
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 IAA60673
for <pgsql-hackers@postgresql.org>;
Tue, 11 Jan 2000 08:27:21 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63377 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sSmyJ40961>; Tue, 11 Jan 2000 14:26:45 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 1281QK-0001RT-00; Tue, 11 Jan 2000 14:33:24 +0100
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Oliver Elphick <olly@lfix.co.uk>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Shared library version
In-Reply-To: <3155.947517764@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001110107120.7876-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Date: Tue, 11 Jan 2000 14:26:45 +0100
On 2000-01-10, Tom Lane mentioned:
"Oliver Elphick" <olly@lfix.co.uk> writes:
There appear to have been changes in the shared library libpq.
Since the library has changed, it needs to have a new version number.You're right, we need to bump the number before release (and I hope we
remember!). Past practice has not been to bump the number during
development cycles, since we'd shortly have ridiculously high version
numbers if we incremented them at every development change.libpq++ has also had API changes requiring a new version number before
release, I think --- any others?
It would at least be fair to bump the minor version number when you do the
branch for a new version, so now we'd be at 2.1. IIRC the dynamic linker
will pick the one with the higher minor version. Since we do not have any
incompatible changes (?) we shouldn't bump the major version.
--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 11 09:22:41 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id JAA84093
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 09:22:39 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 17336 invoked by uid 1001); 11 Jan 2000 14:22:35 -0000
Date: Tue, 11 Jan 2000 09:22:35 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Oliver Elphick <olly@lfix.co.uk>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Shared library version
In-Reply-To: <Pine.LNX.4.21.0001110107120.7876-100000@localhost.localdomain>
Message-ID: <Pine.BSF.4.05.10001110920360.17327-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 11 Jan 2000, Peter Eisentraut wrote:
On 2000-01-10, Tom Lane mentioned:
"Oliver Elphick" <olly@lfix.co.uk> writes:
There appear to have been changes in the shared library libpq.
Since the library has changed, it needs to have a new version number.You're right, we need to bump the number before release (and I hope we
remember!). Past practice has not been to bump the number during
development cycles, since we'd shortly have ridiculously high version
numbers if we incremented them at every development change.libpq++ has also had API changes requiring a new version number before
release, I think --- any others?It would at least be fair to bump the minor version number when you do the
branch for a new version, so now we'd be at 2.1. IIRC the dynamic linker
will pick the one with the higher minor version. Since we do not have any
incompatible changes (?) we shouldn't bump the major version.
libpq++ got a major number bump on my first sweep. This time through
it should only need a minor since I don't forsee any operational changes,
just additional functionality and bug fixes.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Tue Jan 11 17:26:48 2000
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
by hub.org (8.9.3/8.9.3) with SMTP id RAA11989
for <pgsql-hackers@postgresql.org>;
Tue, 11 Jan 2000 17:26:20 -0500 (EST)
(envelope-from aoki@parc.xerox.com)
Received: from louise.parc.xerox.com ([13.2.118.28]) by alpha.xerox.com with
SMTP id <72010(1)>; Tue, 11 Jan 2000 14:26:12 PST
Received: from busytown.parc.xerox.com ([13.2.116.61]) by
louise.parc.xerox.com with SMTP id <359783>;
Tue, 11 Jan 2000 14:25:55 PST
Received: (from aoki@localhost)
by busytown.parc.xerox.com (8.9.3/8.8.7) id OAA19318;
Tue, 11 Jan 2000 14:25:48 -0800
From: "Paul M. Aoki" <aoki@parc.xerox.com>
Message-Id: <200001112225.OAA19318@busytown.parc.xerox.com>
To: ayu@informix.com
Subject: Re: [HACKERS] Historical trivia (was Re: First Major Open Source
Database)
Cc: aoki@parc.xerox.com, jolly@weblogic.com, pgsql-hackers@postgresql.org
Date: Tue, 11 Jan 2000 14:26:10 PST
sorry, i never hit "send" on this.
Andrew Yu <ayu@informix.com> writes:
From: Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: [HACKERS] Historical trivia (was Re: First Major Open Source Database)
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 8 Jan 2000 01:31:40 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>, jolly@weblogic.com,
ayu@informix.comI am CC'ing Jolly and Andrew on this. They may know the answer.
---------------------------------------------------------------------------
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
It did not use any Ingres code, as told to me by Jolly, I
think. My book has Ingres mentioned as an "ancestor" of
Postgres.I suppose we could have figured this out ourselves, since
Postgres was originally written in Lisp, and afaik Ingres was
always C or somesuch traditional compiled-only code. We still
see evidence of this in our code tree with the way lists and
parser nodes are handled.It's clear from both the comments and remnants of coding
conventions that the planner/optimizer was originally Lisp code,
and was hand- translated to C at some point in the dim mists of
prehistory (early 1990s, possibly ;-)). That Lisp heritage is
responsible for some of the better things about the code, and
also some of the worse things.But I'm not sure I believe that *all* of the code was originally
Lisp. I've never heard of a Lisp interface for yacc-generated
parsers, for example. The parts of the executor I've looked at
don't seem nearly as Lispy as the parser/planner/optimizer,
either. So it seems possible that parts of Postgres were
written afresh in Lisp while other parts were lifted from an
older C implementation.</idle speculation>
Does anyone here still recall the origins of Postgres? I'm
curious to know more about the history of this beast.I was under the impression that postgres was all lisp at one point
and that it does not share code with Ingres. Unfortuantely, all this
happen before my time. You must know about this for sure? I guess I
can ask my boss (Zelaine Fong) too. :)
the project started with jeff anton, steven grady and some grad
students. they started from scratch. no code was inherited from
ingres. (later, i ripped off a little bit of code from ingres to
implement one of the numeric types...i think i might have replaced it
with posix calls before pg95.)
from the beginning until late 1989, the system was divided into two
parts: one written in C, the other written in franz lisp. the line
was drawn below the traffic cop, query executor and query optimizer;
hence, the flow of control went back and forth from the lisp "top"
half into the C "bottom" half. the interface was relatively narrow
(parser, system catalogs, access method interface) and used the
essentially undocumented franz lisp equivalent of JNI.
steven wrote and maintained the parser, which was always written using
lex/yacc (i.e., C) but had to generate (in C!) a lisp parse tree.
jeff wrote the traffic cop and (the first version of) a lot of the
rest of the C software. mike hirohama joined early on and wrote stuff
like the first b-tree implementation before becoming chief programmer
in 1988. chinheng hong (an MS student, now at oracle) wrote the query
executor in franz lisp. zelaine fong (an MS student, now at informix)
wrote the query optimizer in franz lisp. lisp/C integration was still
going on when philip chang and i joined the project in late 1986.
in late 1989, jeff goh wrote a postgres-specific lisp->C translator
that automated most of the conversion.
i think the executor looks more C-like for a couple of reasons.
first, people have hacked on the (C version of the) executor a lot
more because it's a lot less mysterious and fragile than the
still-lispy-looking optimizer. chinheng's executor was basically gone
by 1991. second, the executor mostly just walks the query plan and
"does stuff," whereas the optimizer is actually creating nodes and
lists and manipulating those data structures. furthermore, it has
many more such data structures than just the parse tree and query plan
data structures (i.e., the ones for its own internal use). this means
that a larger fraction of the code has to do with getting/setting
these lispy structures.
hope this helps,
-- paul
From bouncefilter Tue Jan 11 09:54:42 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA93211
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 09:53:59 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id JAA04108;
Tue, 11 Jan 2000 09:53:54 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: zeros in oidvector type
In-reply-to: <200001111136.GAA04436@candle.pha.pa.us>
References: <200001111136.GAA04436@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 11 Jan 2000 06:36:42 -0500"
Date: Tue, 11 Jan 2000 09:53:54 -0500
Message-ID: <4105.947602434@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
The reason I ask is that there are some parts of the code that try to
find the number of args by looking for the _first_ non-zero entry in the
list.
Where? This is certainly broken for anything that needs to deal with
an arbitrary pg_proc entry, but it might be OK in limited contexts.
Also, if you are thinking of stuff that looks at *index* definitions
rather than *function* definitions, I think it's OK.
I changed those to look for the _last_ non-zero entry, but it
sounds like that is still wrong.
I'm dubious about changing something like that without fairly close
investigation and/or a known bug to fix. If those bits of code are
wrong, they were wrong before the FUNC_MAX_ARGS change ... and if
they weren't wrong, maybe they are now.
regards, tom lane
From bouncefilter Tue Jan 11 10:06:42 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA98025
for <hackers@postgreSQL.org>; Tue, 11 Jan 2000 10:06:35 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA04236;
Tue, 11 Jan 2000 10:06:10 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Who fried this?
In-reply-to: <Pine.LNX.4.21.0001111425590.5432-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001111425590.5432-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Tue, 11 Jan 2000 14:26:44 +0100"
Date: Tue, 11 Jan 2000 10:06:10 -0500
Message-ID: <4233.947603170@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
What went wrong here? This is from a freshly updated and compiled source.
ERROR: TypeCreate: function 'int4in(opaque)' does not exist
That was one of the intermediate states last night while Bruce and I
were fixing the FUNC_MAX_ARGS code. Update and rebuild (including
configure) and you should be OK.
regards, tom lane
[hackers added to cc: list]
Peter Eisentraut <peter_e@gmx.net> writes:
On 2000-01-08, Tom Lane mentioned:
Chris Griffin <cgriffin@websales.com> writes:
# setenv PGDATA2 /web/sites/1.192/db-data
# initlocation PGDATA2
# createdb -D PGDATA2Surely you want $PGDATA2 in the latter two lines?
You might recall me mentioning that the whole alternative location
business doesn't work in the first place. I'll fix that this week; Chris
will have to wait until the next release.
Fine. BTW, am I the only one who thinks that it's really silly for
initlocation to expect to be given an unexpanded environment variable
name? That's not normal practice (either elsewhere in Postgres, or
anywhere else that I know of). It's confusing because it's not how
an ordinary Unix user would expect a shell command to behave, and it
doesn't buy any functionality that I can see. I'd vote for taking
out the auto-expansion, so that the correct invocation becomes
initlocation $PGDATA2
which is what an average user would expect.
Actually, after looking at what initlocation really does, which is
darn near nothing, I wonder whether we shouldn't dispense with it
altogether...
regards, tom lane
From bouncefilter Tue Jan 11 10:27:42 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA01244
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 10:27:27 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA05123;
Tue, 11 Jan 2000 07:27:00 -0800 (PST)
Message-Id: <3.0.1.32.20000111072143.01023bd0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 11 Jan 2000 07:21:43 -0800
To: Mateus Cordeiro Inssa <mateus@ifnet.com.br>, pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Simmultanous Connections (fwd)
In-Reply-To: <14459.2527.373177.219445@Blaublau.home.br>
References: <200001101646.LAA22111@skillet.infoplease.com>
<Pine.BSF.4.05.10001101108300.13082-100000@paprika.michvhf.com>
<200001101646.LAA22111@skillet.infoplease.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 08:45 AM 1/11/00 -0200, Mateus Cordeiro Inssa wrote:
As an example, I have systems with 2 or 3 hundred simultaneos
connections and besides being short time connections it's impossible to
have 200 or 300 backends running at the same time.
Again, the problem isn't persistent connections but rather an
lousy implementation of pooled persistent connections.
In this case, I had to create a proxy to use few connections.
Another approach is to throttle the number of connections in the
persistent pool manager. This is how AOLserver deals with the
problem. You tell it the max number of connections to fire up
and only that many handles are doled out to threads, the rest
waiting for others to complete. There's another parameter which
places a ceiling on the number of threads allowed to wait for
a pool connection, which allows me to return a "too busy"
message to the user if I so choose. Of course, if a server
starts getting too many of these it's time to upgrade to
something faster, to dig into one's queries looking for
needless inefficiency, or maybe to remember that you forgot
to say "vacuum analyze" (who, me?)
Some folks like to roll their own. I'm lazy and picked a web
server that has already solved such problems for me.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Tue Jan 11 10:31:42 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA04135
for <pgsql-hackers@postgresql.org>;
Tue, 11 Jan 2000 10:31:20 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA04396;
Tue, 11 Jan 2000 10:31:13 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Potential vacuum bug?
In-reply-to: <000101bf5bd7$5a2a96a0$2801007e@tpf.co.jp>
References: <000101bf5bd7$5a2a96a0$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Tue, 11 Jan 2000 10:58:27 +0900"
Date: Tue, 11 Jan 2000 10:31:13 -0500
Message-ID: <4393.947604673@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I'm for your change.
However I could hardly find the case that would cause a trouble.
It may occur in the following rare cases though I'm not sure.
HEAP_MOVED_OFF and (neither HEAP_XMIN_COMMITTED nor
HEAP_XMIN_INVALID) and the tuple was recently delete/updated.
I'm not sure if HEAP_MOVED_OFF is really dangerous, but I am sure
that HEAP_MOVED_IN is dangerous --- vc_rpfheap will error out if
it hits a tuple marked that way. So, if a VACUUM fails partway
through vc_rpfheap (I guess this would have to happen after the
internal commit), it'd be possible that later VACUUMs wouldn't
work anymore.
regards, tom lane
Surely you want $PGDATA2 in the latter two lines?
You might recall me mentioning that the whole alternative location
business doesn't work in the first place.
I'm not recalling the details here; what is the problem? It works for
me (but then I wrote it ;)
Fine. BTW, am I the only one who thinks that it's really silly for
initlocation to expect to be given an unexpanded environment variable
name? That's not normal practice (either elsewhere in Postgres, or
anywhere else that I know of). It's confusing because it's not how
an ordinary Unix user would expect a shell command to behave, and it
doesn't buy any functionality that I can see.
It is not silly at all, unless you want to shoot holes in the basic
premise of the alternate location. This is described in the docs, but
the short form is:
initlocation is used to create the directory structure *with correct
permissions* for an alternate location. It takes an environment
variable because usually the backend should have that same environment
variable defined to ensure consistancy and as a security measure. The
environment variable can be expanded or not; initlocation does the
right thing in either case.
createdb takes a "-D" argument, which specifies the alternate
location. Unless allowed at compile-time, via the
ALLOW_ABSOLUTE_DBPATHS variable, all references to an alternate
location must refer to an environment variable, to give the dbadmin
control over *where* alternate locations will appear. The mechanism is
enforced by the backend, by looking for a directory delimiter in the
datpath field of pg_database, then expanding the first field as an
environment variable. On my system, with one database in an alternate
location, this table looks like:
test=# select * from pg_database;
datname | datdba | encoding | datpath
------------+--------+----------+--------------
template1 | 100 | 0 | template1
postgres | 100 | 0 | postgres
regression | 100 | 0 | regression
test | 100 | 0 | PGDATA2/test
(4 rows)
So, this works:
[postgres@golem parser]$ createdb -D PGDATA2 test2
CREATE DATABASE
But this does not (but can be enabled at compile-time if the sysadmin
wants to allow users to scatter databases everywhere (?!!)):
[postgres@golem regress]$ createdb -D /opt/postgres/data2 test2
ERROR: The path '/opt/postgres/data2/test2' is invalid.
This may be due to a missing environment variable on the server.
createdb: Database creation failed.
I'd vote for taking
out the auto-expansion, so that the correct invocation becomes
initlocation $PGDATA2
which is what an average user would expect.
But the average user does not necessarily have access to the PGDATA2
environment variable! This is usually a sysadmin function.
Actually, after looking at what initlocation really does, which is
darn near nothing, I wonder whether we shouldn't dispense with it
altogether...
?? I hope the explanation above helps...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Jan 11 11:33:43 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA21645
for <hackers@postgreSQL.org>; Tue, 11 Jan 2000 11:33:23 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA10417;
Tue, 11 Jan 2000 11:25:15 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001111625.LAA10417@candle.pha.pa.us>
Subject: Re: [HACKERS] Who fried this?
In-Reply-To: <4233.947603170@sss.pgh.pa.us> from Tom Lane at "Jan 11,
2000 10:06:10 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 11 Jan 2000 11:25:15 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Peter Eisentraut <peter_e@gmx.net> writes:
What went wrong here? This is from a freshly updated and compiled source.
ERROR: TypeCreate: function 'int4in(opaque)' does not existThat was one of the intermediate states last night while Bruce and I
were fixing the FUNC_MAX_ARGS code. Update and rebuild (including
configure) and you should be OK.
And many thanks to Tom for getting me out of this problem I caused.
--
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 Jan 11 11:58:44 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA25602
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 11:58:22 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA04696;
Tue, 11 Jan 2000 11:57:47 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: Regress tests reveal *serious* psql bug
In-reply-to: <24650.947391688@sss.pgh.pa.us>
References: <24650.947391688@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
message dated "Sat, 08 Jan 2000 23:21:28 -0500"
Date: Tue, 11 Jan 2000 11:57:47 -0500
Message-ID: <4693.947609867@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I looked into the cause of the current failure of the array regress
test, enough to realize that there is both a garden-variety code bug
and a serious definitional problem there. The issue is that the new
psql converts
SELECT arrtest.a[1:3],
arrtest.b[1:1][1:2][1:2],
arrtest.c[1:2],
arrtest.d[1:1][1:2]
FROM arrtest;
into
SELECT arrtest.a[1],
arrtest.b[1][1][1],
arrtest.c[1],
arrtest.d[1][1]]
FROM arrtest
--- or at least it tries to do so; on one machine I have handy, psql
actually dumps core while running the array test. (It looks like that
is because line mainloop.c:259 underestimates the amount of memory it
needs to malloc for the changed string, but I haven't worked through the
details. I suspect the extra ']' is the result of an off-by-one kind of
bug in this same block of code.)The reason *why* it is doing this is that it thinks that ":3" and so
forth are variables that it ought to substitute for, and since it has
no definition for them, it happily substitutes empty strings.
After fixing the outright bugs, we could make the array test work by
changing "[1:3]" to "[1\:3]" and so forth, but I think that that is the
wrong way to deal with it. I believe that psql's variable feature needs
to be redefined, instead.
I certainly don't feel that the regress tests are graven on stone
tablets; but when an allegedly unrelated feature change breaks one,
I think we need to treat that as a danger signal. If psql variables
break a regress test, they will likely break existing user applications
as well.
The case at hand is particularly nasty because if psql is allowed to
continue to behave this way, it will silently transform valid queries
into other valid queries with different results. ("array[1:3]" and
"array[1]" don't mean the same thing.) I don't think that's acceptable.
I suggest that psql's variable facility needs to be redefined so that
it is not possible to trigger it accidentally in scripts that don't
even know what psql variables are.
A minimum requirement is that psql should *not* substitute for :x unless
x is the name of a psql variable that the user has explicitly defined.
I would also suggest tightening up the allowed names of variables;
conventional practice is that variable names have to start with a
letter, and I think psql ought to follow that convention. (That
wouldn't in itself stop the array-subscript problem, though, since
an array subscript could be a simple field reference.)
It might even be a good idea to require psql variables to contain only
upper-case letters, so that they'd be less likely to be confused with
SQL field names (which are usually lower case or at least mixed case)
--- but I'm not convinced about that one.regards, tom lane
From bouncefilter Tue Jan 11 12:28:44 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA32912
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 12:28:30 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA18286;
Tue, 11 Jan 2000 12:20:11 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001111720.MAA18286@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
In-Reply-To: <4693.947609867@sss.pgh.pa.us> from Tom Lane at "Jan 11,
2000 11:57:47 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 11 Jan 2000 12:20:11 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
The reason *why* it is doing this is that it thinks that ":3" and so
forth are variables that it ought to substitute for, and since it has
no definition for them, it happily substitutes empty strings.After fixing the outright bugs, we could make the array test work by
changing "[1:3]" to "[1\:3]" and so forth, but I think that that is the
wrong way to deal with it. I believe that psql's variable feature needs
to be redefined, instead.
I know this is the only regression problem you found, and I am glad it
is isolated to psql, and a design problem that can be easily addressed.
I think the requriement that all variables begin with a letter is a good
idea.
We recommended the : in the first place because it is the standard for
embedded SQL variable handling.
I am sure Peter can address this.
I would also suggest tightening up the allowed names of variables;
conventional practice is that variable names have to start with a
letter, and I think psql ought to follow that convention. (That
wouldn't in itself stop the array-subscript problem, though, since
an array subscript could be a simple field reference.)
--
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 Jan 11 12:48:44 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA38534
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 12:48:11 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id SAA155896;
Tue, 11 Jan 2000 18:47:59 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALMQ12>; Tue, 11 Jan 2000 18:48:00 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC1FA@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Don Baccus'" <dhogaza@pacifier.com>,
"'Rod Chamberlin'" <rod@querix.com>,
"'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
Date: Tue, 11 Jan 2000 18:47:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
And, of course, that Oracle, Informix and the rest ought to
get off their
collective asses and support SQL 92. After all, they
undoubtably contributed
to the development of those standards - I can't believe they
didn't fund
representatives to the committees.
Informix does support the full SQL92 outer join syntax since Version 7.31.
Andreas
From bouncefilter Tue Jan 11 12:54:44 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA39284
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 12:54:00 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id SAA60516;
Tue, 11 Jan 2000 18:53:29 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALMQ1W>; Tue, 11 Jan 2000 18:53:30 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC1FB@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Bruce Momjian'" <pgman@candle.pha.pa.us>, "'Rod Chamberlin'"
<rod@querix.com>
Cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
Date: Tue, 11 Jan 2000 18:53:25 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
5/ serial data type
o Serial type must return inserted key valueHow does Informix return the value?
sqlca.sqlerrd[1] in esqlc
Andreas
From bouncefilter Tue Jan 11 13:52:44 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA54162
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 13:52:25 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA21919;
Tue, 11 Jan 2000 13:47:46 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001111847.NAA21919@candle.pha.pa.us>
Subject: Re: AW: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC1FA@sdexcsrv1.f000.d0188.sd.spardat.at>
from Zeugswetter Andreas SB at "Jan 11, 2000 06:47:52 pm"
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
Date: Tue, 11 Jan 2000 13:47:46 -0500 (EST)
CC: "'Don Baccus'" <dhogaza@pacifier.com>,
"'Rod Chamberlin'" <rod@querix.com>,
"'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
And, of course, that Oracle, Informix and the rest ought to
get off their
collective asses and support SQL 92. After all, they
undoubtably contributed
to the development of those standards - I can't believe they
didn't fund
representatives to the committees.Informix does support the full SQL92 outer join syntax since Version 7.31.
7.31 is a fairly new release, in the past year or two.
--
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 Jan 11 17:29:47 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA12484
for <pgsql-hackers@postgresql.org>;
Tue, 11 Jan 2000 17:29:31 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max03-085.enterprise.net
[194.72.196.85])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id WAA23618
for <pgsql-hackers@postgresql.org>; Tue, 11 Jan 2000 22:29:29 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id WAA13417
for <pgsql-hackers@postgresql.org>; Tue, 11 Jan 2000 22:29:28 GMT
Message-Id: <200001112229.WAA13417@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: pgsql-hackers@postgresql.org
Subject: CREATE TABLE ... PRIMARY KEY kills backend
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 11 Jan 2000 22:29:28 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Using the cvs version updated this morning, this query kills the backend,
with no explanation in the log (-d 3):
create table junk (id char(4) primary key, name text not null)
If the primary key constraint is omitted, it is OK.
This worked yesterday. Is this a solved problem, or do I need to trace it?
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Enter into his gates with thanksgiving, and into his
courts with praise. Be thankful unto him, and bless
his name." Psalms 100:4
From bouncefilter Tue Jan 11 18:35:48 2000
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA30738
for <pgsql-hackers@postgresql.org>;
Tue, 11 Jan 2000 18:35:25 -0500 (EST)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
QAA00351;
Tue, 11 Jan 2000 16:35:24 -0700 (MST)
Date: Tue, 11 Jan 2000 16:35:24 -0700 (MST)
Message-Id: <200001112335.QAA00351@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: pgsql-hackers@postgresql.org
Subject: psql -f inconsistency with "copy from stdin"
Today I ran into an inconsistency between two versions of postgresql
in how psql handles copies from stdin. At this point I am not sure
how the rewrite of psql does things, but thought I'd mention the
problem in case someone with it installed can check.
The issue is how the command
psql -f test.sql db < test.dat
is treated, given the following files:
-- test.sql
drop table test;
create table test (name text);
copy test from stdin;
select * from test;
and
test.dat
a
b
Specifically v6.4.2 and v6.5.2 differ in the outcome, with v6.4.2
producing what I would expect and v6.5.2 producing anomalous output.
Note that performing the copy as
psql -c "copy test from stdin" db < test.dat
works fine in either case.
v6.4.2 output: The contents of test.dat are read into the table as
one might expect having redirected that file to stdin and copying from
stdin.
v6.5.2 output: The contents of test.dat are not read into the table at
all. Instead, the remainder of the test.sql file (i.e., select * ...)
are read into the table.
How does the current version behave when performing these copies? If
it still behaves like 6.5.2, I suspect there is some bug in handling
the copy command.
Cheers,
Brook
From bouncefilter Tue Jan 11 19:04:48 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA37579
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 19:04:31 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA04995;
Tue, 11 Jan 2000 19:01:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001120001.TAA04995@candle.pha.pa.us>
Subject: Re: [HACKERS] CREATE TABLE ... PRIMARY KEY kills backend
In-Reply-To: <200001112229.WAA13417@linda.lfix.co.uk> from Oliver Elphick at
"Jan 11, 2000 10:29:28 pm"
To: Oliver Elphick <olly@lfix.co.uk>
Date: Tue, 11 Jan 2000 19:01:17 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Using the cvs version updated this morning, this query kills the backend,
with no explanation in the log (-d 3):create table junk (id char(4) primary key, name text not null)
If the primary key constraint is omitted, it is OK.
This worked yesterday. Is this a solved problem, or do I need to trace it?
Works for me on current sources:
test=> create table junk (id char(4) primary key, name text not null);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'junk_pkey'
for table 'junk'
CREATE
--
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 Jan 11 19:01:05 2000
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 SAA33515
for <pgsql-hackers@postgresql.org>;
Tue, 11 Jan 2000 18:59:54 -0500 (EST) (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 IAA00390; Wed, 12 Jan 2000 08:59:02 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] Potential vacuum bug?
Date: Wed, 12 Jan 2000 09:04:31 +0900
Message-ID: <000001bf5c90$99983b80$2801007e@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
In-Reply-To: <4393.947604673@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I'm for your change.
However I could hardly find the case that would cause a trouble.
It may occur in the following rare cases though I'm not sure.HEAP_MOVED_OFF and (neither HEAP_XMIN_COMMITTED nor
HEAP_XMIN_INVALID) and the tuple was recently delete/updated.I'm not sure if HEAP_MOVED_OFF is really dangerous, but I am sure
that HEAP_MOVED_IN is dangerous --- vc_rpfheap will error out if
it hits a tuple marked that way. So, if a VACUUM fails partway
through vc_rpfheap (I guess this would have to happen after the
internal commit), it'd be possible that later VACUUMs wouldn't
work anymore.
IIRC,there's no HEAP_MOVED_INd and not HEAP_XMIN_COMMITTED
tuples when vc_rpfheap() is called because such tuples has already
been marked unsued in vc_scanheap().
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Tue Jan 11 19:09:48 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA38427
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 19:09:09 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA07846;
Tue, 11 Jan 2000 19:09:01 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] CREATE TABLE ... PRIMARY KEY kills backend
In-reply-to: <200001112229.WAA13417@linda.lfix.co.uk>
References: <200001112229.WAA13417@linda.lfix.co.uk>
Comments: In-reply-to "Oliver Elphick" <olly@lfix.co.uk>
message dated "Tue, 11 Jan 2000 22:29:28 +0000"
Date: Tue, 11 Jan 2000 19:09:00 -0500
Message-ID: <7843.947635740@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Oliver Elphick" <olly@lfix.co.uk> writes:
Using the cvs version updated this morning, this query kills the backend,
with no explanation in the log (-d 3):create table junk (id char(4) primary key, name text not null)
Works for me:
regression=# create table junk (id char(4) primary key, name text not null);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'junk_pkey' for table 'junk'
CREATE
Are you sure you have a complete update of the INDEX_MAX_KEYS changes?
I committed the last of them about 1am EST (6am GMT) this morning, and
it was a change to config.h.in ---- you would need to do a *full*
configure, build, initdb cycle to be sure you have working code.
If that doesn't do it for you, there may be a platform-dependent bug
still lurking; can you provide a debugger backtrace of the crashed
backend?
I'd also suggest running the regress tests ... they pass here, with
the exception of the 'array' test ...
regards, tom lane
From bouncefilter Tue Jan 11 21:36:26 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA05876
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 21:36:14 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id VAA00276
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 21:19:11 -0500 (EST)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id SAA00299
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 18:17:37 -0800 (PST)
Message-Id: <3.0.1.32.20000111181539.01034e10@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 11 Jan 2000 18:15:39 -0800
To: pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: bug in 6.5.3...
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
I looked in the "TODO" list and didn't find any mention of
avg() or relevant items regarding aggregates so here's my
bug du jour:
acs=> create table foo(p numeric(9,2));
CREATE
acs=> select avg(p) from foo;
ERROR: overflow on numeric ABS(value) >= 10^-1 for field with precision 0
scale 1723
acs=>
acs=> insert into foo values(3);
INSERT 1014409 1
acs=> select avg(p) from foo;
ERROR: overflow on numeric ABS(value) >= 10^-1 for field with precision 0
scale 1723
acs=> select p from foo;
p
----
3.00
(1 row)
acs=> select max(p) from foo;
max
----
3.00
(1 row)
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Tue Jan 11 22:06:30 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA19511
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 22:06:09 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: from candle.pha.pa.us (s5-03.ppp.op.net [209.152.195.67])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id VAA01483
for <pgsql-hackers@postgreSQL.org>;
Tue, 11 Jan 2000 21:49:58 -0500 (EST)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA07730;
Tue, 11 Jan 2000 21:44:33 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001120244.VAA07730@candle.pha.pa.us>
Subject: patch re-added
To: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Date: Tue, 11 Jan 2000 21:44:33 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tom, I see you found the case where the array was being written past the
end, or so I thought. I now see I was wrong:
/*
* Need to make these arrays large enough to be sure there is a
* terminating 0 at the end of each one.
*/
info->classlist = (Oid *) palloc(sizeof(Oid) * (INDEX_MAX_KEYS+1));
info->indexkeys = (int *) palloc(sizeof(int) * (INDEX_MAX_KEYS+1));
info->ordering = (Oid *) palloc(sizeof(Oid) * (INDEX_MAX_KEYS+1));
...
for (i = 0; i < INDEX_MAX_KEYS; i++)
info->indexkeys[i] = index->indkey[i];
+ info->indexkeys[INDEX_MAX_KEYS] = 0;
for (i = 0; i < INDEX_MAX_KEYS; i++)
info->classlist[i] = index->indclass[i];
+ info->classlist[INDEX_MAX_KEYS] = (Oid) 0;Thanks again, Tom.
Vadim used to bail me out of the jams I get into. Tom, looks like
you're my new savior.
--
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 Jan 11 22:31:58 2000
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 WAA23629
for <pgsql-hackers@postgresql.org>;
Tue, 11 Jan 2000 22:31:00 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64212 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sSzJF126993>; Wed, 12 Jan 2000 04:30:25 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128Eb2-0002m6-00; Wed, 12 Jan 2000 04:37:20 +0100
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: [SQL] createdb -D xxxx not working
In-Reply-To: <387B52D5.17CB18EA@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0001120312180.3735-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Date: Wed, 12 Jan 2000 04:30:25 +0100
On 2000-01-11, Thomas Lockhart mentioned:
Surely you want $PGDATA2 in the latter two lines?
You might recall me mentioning that the whole alternative location
business doesn't work in the first place.I'm not recalling the details here; what is the problem? It works for
me (but then I wrote it ;)
Darn, now I already rewrote the thing to where I considered it working. We
had several on-and-off discussions (mostly Tom and I) about it during the
last two months at least, including users complaining.
The sort of scheme I came up with scraps the environment variable stuff
(since it's not quite safe either and has several bugs in the code that
create a bunch of problems along the way) and lets the following
happen (example paths):
CREATE DATABASE foo; --> /usr/local/pgsql/data/base/foo/pg_class
CREATE DATABASE foo WITH LOCATION 'bar';
--> /usr/local/pgsql/data/base/bar/pg_class
CREATE DATABASE foo WITH LOCATION '/some/where';
--> /some/where/pg_class
CREATE DATABASE foo WITH LOCATION 'foo/bar';
is disabled. I suppose I could stick the
environment variable deal back in so that users don't have to remember any
complicated paths, but this is the dbadmin's job anyway, so he should be
able to remember it.
Anyway, in order for a path to be allowed it has to be listed in
PG_ALTLOC, which is a colon-delimited, marginally wildcard enabled list of
allowed locations. In some future life this could be included in a
configuration file.
initlocation is used to create the directory structure *with correct
permissions* for an alternate location. It takes an environment
I think one of the problems was actually that the path initlocation
assumed and the one createdb worked with were different.
variable because usually the backend should have that same environment
variable defined to ensure consistancy and as a security measure. The
environment variable can be expanded or not; initlocation does the
right thing in either case.
It's false security though, since for complete security the dbadmin would
have to delete all other environment variables altogether.
I'd vote for taking
out the auto-expansion, so that the correct invocation becomes
initlocation $PGDATA2
which is what an average user would expect.But the average user does not necessarily have access to the PGDATA2
environment variable! This is usually a sysadmin function.
The average user doesn't even have access to the machine the database is
running on, so he can't do any initlocation either way. Then again the
average user doesn't create databases either. But there is no real point
for initlocation since a mere mkdir() call in createdb() will do the job.
Now I just got done with that coding 10 minutes ago but now that someone
actually spoke up in defence of this mechanism I'm going to wait and see
what you think about the revised (or any) scheme.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 11 22:31:56 2000
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 WAA23616
for <pgsql-hackers@postgresql.org>;
Tue, 11 Jan 2000 22:30:59 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64213 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sSzJG129027>; Wed, 12 Jan 2000 04:30:26 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128Eb8-0002m8-00; Wed, 12 Jan 2000 04:37:26 +0100
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: Regress tests reveal *serious* psql bug
In-Reply-To: <4693.947609867@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001120333181.3735-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Date: Wed, 12 Jan 2000 04:30:26 +0100
Wow that sucks. Shame on me.
On 2000-01-11, Tom Lane mentioned:
psql converts
SELECT arrtest.a[1:3],
...
into
...
SELECT arrtest.a[1],
In some earlier developmental stage I had the variable delimiter runtime
definable since it became clear that the traditional $ wouldn't work.
Later on someone pointed out that the SQL syntax for this is the colon
deal. (And you were in that discussion, if I am not completely off.)
Actually the colon deal only applies to embedded SQL, so ecpg should have
the same problem, but I'm not familiar with it, so I don't know how it
copes.
The fact is that (besides the garden-variety bugs) this is indeed a
problem of definition. I'm not sure if the following is valid by any
standard or even makes sense, but how do you interpret something like
this:
SELECT arrtest.biggest_value_pos, arrtest.a[1:biggest_value_pos] ... ;
There's no way you can disambiguate this unless you redefine everything.
A minimum requirement is that psql should *not* substitute for :x unless
x is the name of a psql variable that the user has explicitly defined.
Then psql becomes no better than csh, and that's certainly one of the
worse things one could do.
Putting blame on other people's shoulders I would suggest changing the
array syntax to arr[1][2] like everyone else has, but that would be short
sighted.
The best idea I have to get this working _now_ would be to once again make
the variable delimiter run-time configurable so that you can set it to
: or $ or # or whatever your query doesn't use, completely off by default
If I'm going to hack around in that code, one related question: what
should the deal be regarding variable interpolation into quoted
strings? Yes/No/Maybe?
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 11 22:31:30 2000
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 WAA23617
for <pgsql-hackers@postgresql.org>;
Tue, 11 Jan 2000 22:31:00 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64246 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sSzJO112650>; Wed, 12 Jan 2000 04:30:34 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128EbF-0002mA-00; Wed, 12 Jan 2000 04:37:33 +0100
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
In-Reply-To: <200001111720.MAA18286@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0001120349530.3735-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Date: Wed, 12 Jan 2000 04:30:34 +0100
On 2000-01-11, Bruce Momjian mentioned:
I think the requriement that all variables begin with a letter is a good
idea.
But it doesn't fix anything really. I left those open to be used for some
special purpose like addressing the fields of the last query of
something. Perhaps I should take them out for now though.
We recommended the : in the first place because it is the standard for
embedded SQL variable handling.
So the array syntax should be changed?
I am sure Peter can address this.
Addressed it will be ... ;)
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 11 22:31:48 2000
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 WAA24338
for <pgsql-hackers@postgresql.org>;
Tue, 11 Jan 2000 22:31:19 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64268 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sSzJX118792>; Wed, 12 Jan 2000 04:30:43 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128EbJ-0002mC-00; Wed, 12 Jan 2000 04:37:37 +0100
From: Peter Eisentraut <peter_e@gmx.net>
To: Brook Milligan <brook@biology.nmsu.edu>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql -f inconsistency with "copy from stdin"
In-Reply-To: <200001112335.QAA00351@biology.nmsu.edu>
Message-ID: <Pine.LNX.4.21.0001120359290.3735-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Date: Wed, 12 Jan 2000 04:30:43 +0100
7.0 behaves like 6.5.* in this regard because the code is pretty much the
same. Thanks for pointing this out.
On 2000-01-12, Brook Milligan mentioned:
Today I ran into an inconsistency between two versions of postgresql
in how psql handles copies from stdin. At this point I am not sure
how the rewrite of psql does things, but thought I'd mention the
problem in case someone with it installed can check.The issue is how the command
psql -f test.sql db < test.dat
is treated, given the following files:
-- test.sql
drop table test;
create table test (name text);
copy test from stdin;
select * from test;and
test.dat
a
bSpecifically v6.4.2 and v6.5.2 differ in the outcome, with v6.4.2
producing what I would expect and v6.5.2 producing anomalous output.
Note that performing the copy aspsql -c "copy test from stdin" db < test.dat
works fine in either case.
v6.4.2 output: The contents of test.dat are read into the table as
one might expect having redirected that file to stdin and copying from
stdin.v6.5.2 output: The contents of test.dat are not read into the table at
all. Instead, the remainder of the test.sql file (i.e., select * ...)
are read into the table.How does the current version behave when performing these copies? If
it still behaves like 6.5.2, I suspect there is some bug in handling
the copy command.Cheers,
Brook************
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Jan 12 00:43:32 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA87167
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 00:42:40 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA08891;
Wed, 12 Jan 2000 00:42:30 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
In-reply-to: <Pine.LNX.4.21.0001120349530.3735-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001120349530.3735-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Wed, 12 Jan 2000 04:30:32 +0100"
Date: Wed, 12 Jan 2000 00:42:30 -0500
Message-ID: <8888.947655750@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
We recommended the : in the first place because it is the standard for
embedded SQL variable handling.
So the array syntax should be changed?
Bzzt, wrong answer.
I'm open to alternative answers on this, but breaking existing
application scripts is not one of the acceptable alternatives.
*Especially* not if there's no obvious failure report, as there
will not be if we don't change psql's behavior.
regards, tom lane
From bouncefilter Wed Jan 12 00:57:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA88494
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 00:56:32 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA11692;
Wed, 12 Jan 2000 00:53:13 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001120553.AAA11692@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
In-Reply-To: <8888.947655750@sss.pgh.pa.us> from Tom Lane at "Jan 12,
2000 00:42:30 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 12 Jan 2000 00:53:13 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Peter Eisentraut <peter_e@gmx.net> writes:
We recommended the : in the first place because it is the standard for
embedded SQL variable handling.So the array syntax should be changed?
Bzzt, wrong answer.
I'm open to alternative answers on this, but breaking existing
application scripts is not one of the acceptable alternatives.*Especially* not if there's no obvious failure report, as there
will not be if we don't change psql's behavior.
I think we can live with requiring a variable name to start with an
alphabetic or underscore.
SELECT a[1:2]
is clear and
SELECT a[1:myvar]
expands to SELECT a[1]. I think we can live with this since having a
variable as an array element was never possible before 7.0. We could
get fancy and not expand variables inside brackets. Of course, quoted
strings have to be skipped.
In fact, I think it should be an error to reference a variable that is
not defined. This will catch accidental references too. If you
reference a variable that does not exist like :myvar, it passes the
literal :myvar to the backend.
--
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 Jan 12 01:15:32 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA93687
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 01:15:05 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA08949;
Wed, 12 Jan 2000 01:15:00 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: Regress tests reveal *serious* psql bug
In-reply-to: <Pine.LNX.4.21.0001120333181.3735-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001120333181.3735-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Wed, 12 Jan 2000 04:30:23 +0100"
Date: Wed, 12 Jan 2000 01:15:00 -0500
Message-ID: <8945.947657700@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
In some earlier developmental stage I had the variable delimiter runtime
definable since it became clear that the traditional $ wouldn't work.
Later on someone pointed out that the SQL syntax for this is the colon
deal. (And you were in that discussion, if I am not completely off.)
Yah. I think at the time we were only thinking of colon as a user-
definable operator (well, it's also a predefined operator, but not a
very essential one). I plead guilty to forgetfulness in not remembering
that it was also an essential component of the array grammar. Still,
there it is. I think this raises the bar to the point where we must
have a transparent backward-compatible approach to psql variables.
I was not all that thrilled about blowing off colon as an operator,
and blowing off array subscripts *too* is just too far above my
threshold of pain.
Actually the colon deal only applies to embedded SQL, so ecpg should have
the same problem, but I'm not familiar with it, so I don't know how it
copes.
Good question. Michael?
The fact is that (besides the garden-variety bugs) this is indeed a
problem of definition. I'm not sure if the following is valid by any
standard or even makes sense, but how do you interpret something like
this:
SELECT arrtest.biggest_value_pos, arrtest.a[1:biggest_value_pos] ... ;
There's no way you can disambiguate this unless you redefine everything.
Huh? There was nothing in the least ambiguous about it, until you
redefined psql. It's still not ambiguous in any other pgsql interface,
except possibly ecpg...
A minimum requirement is that psql should *not* substitute for :x unless
x is the name of a psql variable that the user has explicitly defined.
Then psql becomes no better than csh, and that's certainly one of the
worse things one could do.
csh isn't one of my favorite programming languages either, but failure
to detect undefined substitution variables is a pretty venial sin
compared to silently transforming *valid* queries into wrong queries.
The former will not bring villagers with pitchforks to your doorstep,
but the latter will.
Furthermore, if you are trying to help the substitution-variable
programmer detect his mistakes, then silently substituting (wrong)
empty values is not my idea of helpfulness. You could maybe make a
defensible case for rejecting the whole query with ":x is not defined".
What you have chosen is the worst of all possible worlds, because it
breaks existing scripts that are ignorant of the new feature without
doing anything particularly helpful for people who *are* using the new
feature.
Finally, if the would-be user of psql variables misspells :foo as
:fop, I think he's much more likely to realize he's made a mistake if
psql passes :fop as-is to the backend rather than quietly discarding it.
Putting blame on other people's shoulders I would suggest changing the
array syntax to arr[1][2] like everyone else has,
Say what? That's the syntax for a 2-D array, not the syntax for
an array slice.
The best idea I have to get this working _now_ would be to once again make
the variable delimiter run-time configurable so that you can set it to
: or $ or # or whatever your query doesn't use, completely off by default
If it's off by default, that would eliminate the backwards-compatibility
problem --- but I still think the potential dual use of whatever
character you happen to pick would just be a gotcha waiting to bite
anyone who uses the feature. We still ought to think about tightening
up the substitution rules so they are less likely to trap the unwary.
If I'm going to hack around in that code, one related question: what
should the deal be regarding variable interpolation into quoted
strings? Yes/No/Maybe?
No bloody way, IMHO --- that increases the odds of unwanted
substitutions by many orders of magnitude. If you want to allow
substitutions into quoted strings, there should be a very special
syntax for it, perhaps along the lines of
'a quoted ':foo' string'
which could translate to 'a quoted foobar string' if :foo expands
to foobar.
regards, tom lane
From bouncefilter Wed Jan 12 01:23:32 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA94402
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 01:22:43 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA08981;
Wed, 12 Jan 2000 01:22:33 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
In-reply-to: <200001120553.AAA11692@candle.pha.pa.us>
References: <200001120553.AAA11692@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Wed, 12 Jan 2000 00:53:13 -0500"
Date: Wed, 12 Jan 2000 01:22:33 -0500
Message-ID: <8978.947658153@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I think we can live with requiring a variable name to start with an
alphabetic or underscore.
SELECT a[1:2]
is clear and
SELECT a[1:myvar]
expands to SELECT a[1].
No go --- SELECT a[1:b] where b is a field name is a valid query
currently.
I don't really see exactly what the benefit is of assuming that
:foo should expand to nothing rather than :foo, in the absence
of an actual definition for :foo. My feeling is that a safe solution
would be
(a) psql doesn't do variables at all without an explicitly enabling
command line switch; and
(b) if psql sees :foo where foo is not defined, it spits out an
error message.
Accepting undeclared variables went out with Basic and Fortran;
why are we intent on re-inventing a concept that's so obviously
dangerous?
In fact, I think it should be an error to reference a variable that is
not defined. This will catch accidental references too. If you
reference a variable that does not exist like :myvar, it passes the
literal :myvar to the backend.
That's two different answers, not one... but I could live with either
one of them...
regards, tom lane
From bouncefilter Wed Jan 12 01:33:32 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA98701
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 01:33:23 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA09041;
Wed, 12 Jan 2000 01:33:01 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] bug in 6.5.3...
In-reply-to: <3.0.1.32.20000111181539.01034e10@mail.pacifier.com>
References: <3.0.1.32.20000111181539.01034e10@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Tue, 11 Jan 2000 18:15:39 -0800"
Date: Wed, 12 Jan 2000 01:33:01 -0500
Message-ID: <9038.947658781@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Don Baccus <dhogaza@pacifier.com> writes:
I looked in the "TODO" list and didn't find any mention of
avg() or relevant items regarding aggregates so here's my
bug du jour:
acs=> create table foo(p numeric(9,2));
CREATE
acs=> select avg(p) from foo;
ERROR: overflow on numeric ABS(value) >= 10^-1 for field with precision 0
scale 1723
acs=>
acs=> insert into foo values(3);
INSERT 1014409 1
acs=> select avg(p) from foo;
ERROR: overflow on numeric ABS(value) >= 10^-1 for field with precision 0
scale 1723
That's a known bug I believe (Jan, are you paying attention?). It seems
to be platform-dependent --- in current sources, I see no failure on an
HPUX box, but a Linux box fails with
ERROR: overflow on numeric ABS(value) >= 10^-1 for field with precision 2077 scale 22808
Maybe a big-vs-little-endian kind of problem?
regards, tom lane
From bouncefilter Wed Jan 12 01:43:40 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA99618
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 01:43:16 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA09072;
Wed, 12 Jan 2000 01:42:57 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Brook Milligan <brook@biology.nmsu.edu>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql -f inconsistency with "copy from stdin"
In-reply-to: <Pine.LNX.4.21.0001120359290.3735-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001120359290.3735-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Wed, 12 Jan 2000 04:30:43 +0100"
Date: Wed, 12 Jan 2000 01:42:56 -0500
Message-ID: <9069.947659376@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
7.0 behaves like 6.5.* in this regard because the code is pretty much the
same. Thanks for pointing this out.
Of course, the question is which way is right...
I can see the potential usefulness of doing
psql -f driving.script <data.file
but on the other hand, it bothers me a good deal that a script
containing
COPY table FROM STDIN;
... data here ...
\.
(as generated by such unheard-of, seldom-used utilities as pg_dump)
would work when sourced by psql <pgdump.script and *fail* when sourced
by psql -f pgdump.script. But that's what will happen if we change
it back.
I suspect the change in behavior from 6.4 to 6.5 may have been a
deliberate change to avoid this failure mode. It'd be worth checking
the archives to see if you can find any discussion about it.
It seems to me that we ought to provide both behaviors, but make sure
that the one that supports data-in-the-script is the one invoked by
COPY FROM STDIN (since that's what pg_dump uses). Perhaps psql's \copy
command can be set up to support the other alternative.
regards, tom lane
From bouncefilter Wed Jan 12 02:02:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA05092
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 02:02:09 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA09128
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 02:01:58 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Re: INDEX_MAX_KEYS = 16 ... it works, too
In-reply-to: <27767.947570602@sss.pgh.pa.us>
References: <27767.947570602@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
message dated "Tue, 11 Jan 2000 01:03:22 -0500"
Date: Wed, 12 Jan 2000 02:01:58 -0500
Message-ID: <9125.947660518@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
BTW, I have done quick-and-dirty tests of indexes with up to 16 keys
and SQL functions with up to 16 arguments, and both seem to work.
Did not try plpgsql or pltcl functions --- perhaps someone who's
handier than I am with those languages can check them.
I also committed a patch to ensure that index declarations with
more than INDEX_MAX_KEYS will be rejected; this oversight was
noted by Hiroshi a while ago.
regards, tom lane
From bouncefilter Wed Jan 12 02:50:33 2000
Received: from cap-ferrat.albourne.com (cap-ferrat.albourne.com
[195.89.178.227]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA11943
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 02:50:20 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (bishop-rock.albourne.com [195.89.178.230])
by cap-ferrat.albourne.com (8.9.3/8.9.3/Albourne/UKS/2.9/MAPS) with
ESMTP id HAA08066
for <pgsql-hackers@postgresql.org>; Wed, 12 Jan 2000 07:50:06 GMT
Sender: a.joubert@albourne.com
Message-ID: <387C3232.85F1E291@albourne.com>
Date: Wed, 12 Jan 2000 07:50:10 +0000
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: BlowAwayRelationBuffers
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hmmm, I got the following this morning on version 6.5.2 on DEC Alpha
during a vacuum verbose analyze. Ended up with duplicate rows of
everything.
NOTICE: --Relation tasksids--
NOTICE: Pages 1356: Changed 349, Reapped 875, Empty 0, New 0; Tup
88946: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 123921, MinLen 41, MaxLen
41; Re-using: Free/Avail. Space 5965708/5965708; EndEmpty/Avail. Pages
0/875. Elapsed 0/0 sec.
NOTICE: Rel tasksids: Pages: 1356 --> 567; Tuple(s) moved: 31746.
Elapsed 0/0 sec.
NOTICE: BlowawayRelationBuffers(tasksids, 567): block 764 is referenced
(private 0, last 0, global 1)
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.
According to the mailing list archive
http://www.postgresql.org/mhonarc/pgsql-hackers/1999-02/msg00052.html
a bug in this area was fixed in 6.4. I seem to remember that somebody is
looking at vacuum at the moment, so this may be something to keep in
mind.
Adriaan
From bouncefilter Wed Jan 12 03:26:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA24731
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 03:25:35 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id DAA09215;
Wed, 12 Jan 2000 03:24:42 -0500 (EST)
To: Adriaan Joubert <a.joubert@albourne.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] BlowAwayRelationBuffers
In-reply-to: <387C3232.85F1E291@albourne.com>
References: <387C3232.85F1E291@albourne.com>
Comments: In-reply-to Adriaan Joubert <a.joubert@albourne.com>
message dated "Wed, 12 Jan 2000 07:50:10 +0000"
Date: Wed, 12 Jan 2000 03:24:42 -0500
Message-ID: <9212.947665482@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Adriaan Joubert <a.joubert@albourne.com> writes:
Hmmm, I got the following this morning on version 6.5.2 on DEC Alpha
during a vacuum verbose analyze. Ended up with duplicate rows of
everything.
Really!? The referencecount failure doesn't surprise me a whole lot,
given the refcount bugs that I fixed a couple months ago (no, those
fixes are not in 6.5.* :-(). But VACUUM is supposed to be guaranteed
proof against generating duplicate tuples by design --- that's what
all the HEAP_MOVED_OFF and HEAP_MOVED_IN foofaraw is about.
Perhaps there is a glitch in the tuple validity checking logic for
HEAP_MOVED_OFF/HEAP_MOVED_IN? Anyone see it?
Given that this was on an Alpha, it could be a 64-bit-platform-
dependency kind of bug...
regards, tom lane
From bouncefilter Wed Jan 12 03:33:34 2000
Received: from cap-ferrat.albourne.com (cap-ferrat.albourne.com
[195.89.178.227]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA28814
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 03:33:06 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (bishop-rock.albourne.com [195.89.178.230])
by cap-ferrat.albourne.com (8.9.3/8.9.3/Albourne/UKS/2.9/MAPS) with
ESMTP id IAA09825; Wed, 12 Jan 2000 08:26:29 GMT
Sender: a.joubert@albourne.com
Message-ID: <387C3ABA.BC071D19@albourne.com>
Date: Wed, 12 Jan 2000 08:26:34 +0000
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
References: <200001120553.AAA11692@candle.pha.pa.us>
<8978.947658153@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I think we can live with requiring a variable name to start with an
alphabetic or underscore.SELECT a[1:2]
is clear and
SELECT a[1:myvar]
expands to SELECT a[1].
No go --- SELECT a[1:b] where b is a field name is a valid query
currently.
The colon in array syntax is quite a special case. It should be relatively
easy to figure out whether you are in a construct of the form
[<token>:<token>]. And then there should be no problem in figuring out that
in
[1:b] b refers to a column and in [1::b] ':b' is a variable. Do colons
apear anywhere else?
Btw, i agree that variables should start with a letter and by default
variables have to be declared.
Adriaan
From bouncefilter Wed Jan 12 03:43:34 2000
Received: from cap-ferrat.albourne.com (cap-ferrat.albourne.com
[195.89.178.227]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA29871
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 03:42:32 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (bishop-rock.albourne.com [195.89.178.230])
by cap-ferrat.albourne.com (8.9.3/8.9.3/Albourne/UKS/2.9/MAPS) with
ESMTP id IAA10072; Wed, 12 Jan 2000 08:42:28 GMT
Sender: a.joubert@albourne.com
Message-ID: <387C3E78.CEA09236@albourne.com>
Date: Wed, 12 Jan 2000 08:42:32 +0000
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] BlowAwayRelationBuffers
References: <387C3232.85F1E291@albourne.com> <9212.947665482@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:
Hmmm, I got the following this morning on version 6.5.2 on DEC Alpha
during a vacuum verbose analyze. Ended up with duplicate rows of
everything.Really!? The referencecount failure doesn't surprise me a whole lot,
given the refcount bugs that I fixed a couple months ago (no, those
fixes are not in 6.5.* :-(). But VACUUM is supposed to be guaranteed
proof against generating duplicate tuples by design --- that's what
all the HEAP_MOVED_OFF and HEAP_MOVED_IN foofaraw is about.Perhaps there is a glitch in the tuple validity checking logic for
HEAP_MOVED_OFF/HEAP_MOVED_IN? Anyone see it?Given that this was on an Alpha, it could be a 64-bit-platform-
dependency kind of bug...
This is not the first time that I've ended up with duplicate tuples: I
even have a standard mechanism to deal with them :-(! Initially I thought
this was due to tables getting corrupted by having index entries that
were too large, but that has been fixed (and has caused no problems since
the fix you sent -- thanks again!), and this still happens. It seems to
happen most frequently when there have been a very large number of
changes to the tables between vacuums.
Adriaan
From bouncefilter Wed Jan 12 04:23:34 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA61422;
Wed, 12 Jan 2000 04:22:54 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id EAA99540;
Wed, 12 Jan 2000 04:02:12 -0500 (EST) (envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: "Netra systems" <julien@netra-systems.com>
X-Newsgroups: comp.databases.postgresql, comp.databases.postgresql.admin,
comp.databases.postgresql.hackers,
comp.databases.postgresql.questions, linux.act.postgres
Subject: postgresql installation
Date: Wed, 12 Jan 2000 09:52:06 +0100
Lines: 9
X-Newsreader: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Message-ID: <387c40b0@feednews.internext.fr>
X-Trace: 12 Jan 2000 09:52:00 +0100, intx165.alternext.net
To:
pgsql-hackers@postgresql.org.pgsql-admin@postgresql.org.pgsql-questions@postgresql.org
hello,
i have pb with the postgre sql installation :
i compile all .. ok
but when i want to run postmaster or anything else it say : no db dir :
data/../template1 ...
i have no data dir in my postgre dinstalled dir ....
how can i have this dir with all into ?
From bouncefilter Wed Jan 12 03:58:34 2000
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 DAA56137
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 03:58:31 -0500 (EST) (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 RAA00738; Wed, 12 Jan 2000 17:57:02 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Adriaan Joubert" <a.joubert@albourne.com>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] BlowAwayRelationBuffers
Date: Wed, 12 Jan 2000 18:02:33 +0900
Message-ID: <000201bf5cdb$c31fd620$2801007e@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
In-Reply-To: <9212.947665482@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom LaneAdriaan Joubert <a.joubert@albourne.com> writes:
Hmmm, I got the following this morning on version 6.5.2 on DEC Alpha
during a vacuum verbose analyze. Ended up with duplicate rows of
everything.Really!? The referencecount failure doesn't surprise me a whole lot,
given the refcount bugs that I fixed a couple months ago (no, those
fixes are not in 6.5.* :-(). But VACUUM is supposed to be guaranteed
proof against generating duplicate tuples by design --- that's what
all the HEAP_MOVED_OFF and HEAP_MOVED_IN foofaraw is about.Perhaps there is a glitch in the tuple validity checking logic for
HEAP_MOVED_OFF/HEAP_MOVED_IN? Anyone see it?
I commited the following change to REL tree after 6.5.2.
It might be late for Adriaan.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
*** xact.c.orig Wed Jan 12 17:53:19 2000
--- xact.c Tue Oct 19 11:54:39 1999
***************
*** 733,741 ****
/*
* Have the transaction access methods record the status of
* this transaction id in the pg_log relation. We skip it
! * if no one shared buffer was changed by this transaction.
*/
! if (SharedBufferChanged)
TransactionIdAbort(xid); ResetBufferPool();
--- 733,742 ----
/*
* Have the transaction access methods record the status of
* this transaction id in the pg_log relation. We skip it
! * if no one shared buffer was changed by this transaction
! * or this transaction has been committed already.
*/
! if (SharedBufferChanged && !TransactionIdDidCommit(xid))
TransactionIdAbort(xid);ResetBufferPool();
From bouncefilter Wed Jan 12 05:32:35 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA78262
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 05:31:53 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max04-052.enterprise.net
[194.72.196.172])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id KAA08290;
Wed, 12 Jan 2000 10:31:50 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id KAA02056;
Wed, 12 Jan 2000 10:31:44 GMT
Message-Id: <200001121031.KAA02056@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: "Oliver Elphick" <olly@lfix.co.uk>, pgsql-hackers@postgreSQL.org,
olly@linda.lfix.co.uk
Subject: Re: [HACKERS] CREATE TABLE ... PRIMARY KEY kills backend
In-Reply-To: Message from Tom Lane <tgl@sss.pgh.pa.us>
of "Tue, 11 Jan 2000 19:09:00 EST." <7843.947635740@sss.pgh.pa.us>
References: <200001112229.WAA13417@linda.lfix.co.uk>
<7843.947635740@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 12 Jan 2000 10:31:43 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Tom Lane wrote:
"Oliver Elphick" <olly@lfix.co.uk> writes:
Using the cvs version updated this morning, this query kills the backend,
with no explanation in the log (-d 3):create table junk (id char(4) primary key, name text not null)
Works for me:
regression=# create table junk (id char(4) primary key, name text not null);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'junk_pkey' for
table 'junk'
CREATEAre you sure you have a complete update of the INDEX_MAX_KEYS changes?
I committed the last of them about 1am EST (6am GMT) this morning, and
it was a change to config.h.in ---- you would need to do a *full*
configure, build, initdb cycle to be sure you have working code.
./configure --with-tcl --with-mb=UNICODE --with-odbc --enable-locale
--with-maxbackends=64 --with-pgport=5431 --program-prefix=pg7.
(The program-prefix doesn't seem to do anything.)
Database destoyed and initdb run...
If that doesn't do it for you, there may be a platform-dependent bug
still lurking; can you provide a debugger backtrace of the crashed
backend?
Segmentation fault (in the end):
#0 0x400f068d in _IO_default_xsputn () from /lib/libc.so.6
#1 0x400e0126 in vfprintf () from /lib/libc.so.6
#2 0x400edf23 in vsnprintf () from /lib/libc.so.6
#3 0x80a8e82 in appendStringInfo ()
#4 0x80c244d in _outTypeName ()
#5 0x80c43da in _outNode ()
#6 0x80c2391 in _outColumnDef ()
...
#157128 0x80c23f6 in _outColumnDef ()
#157129 0x80c43ca in _outNode ()
#157130 0x80c407c in _outNode ()
#157131 0x80c3f7a in _outConstraint ()
#157132 0x80c475a in _outNode ()
#157133 0x80c407c in _outNode ()
#157134 0x80c23f6 in _outColumnDef ()
#157135 0x80c43ca in _outNode ()
#157136 0x80c407c in _outNode ()
#157137 0x80c219c in _outCreateStmt ()
#157138 0x80c43aa in _outNode ()
#157139 0x80c2578 in _outQuery ()
#157140 0x80c43fa in _outNode ()
#157141 0x80c47fd in nodeToString ()
#157142 0x80ed791 in pg_parse_and_plan ()
#157143 0x80eda46 in pg_exec_query_dest ()
#157144 0x80eda01 in pg_exec_query ()
#157145 0x80eeb82 in PostgresMain ()
#157146 0x80d7ee7 in DoBackend ()
#157147 0x80d7abe in BackendStartup ()
#157148 0x80d6cc9 in ServerLoop ()
#157149 0x80d66ae in PostmasterMain ()
#157150 0x80ae2cb in main ()
#157151 0x400bc7e2 in __libc_start_main () from /lib/libc.so.6
I don't have any line number info, so I'll have to rebuild in order to
do more detailed tracing.
I'd also suggest running the regress tests ... they pass here, with
the exception of the 'array' test ...
The regression test doesn't seem to work at all with multibyte enabled:
=============== creating new regression database... =================
createdb: "UNICODE" is not a valid encoding name.
createdb failed
ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out
The reason is that regress.sh uses createdb; createdb has a bad test for
the encoding value (I have sent a patch separately). So I assume no-one
has run regression tests with multibyte-encoding enabled?
I fixed the createdb bug and ran the regression test. The constraints
test failed when trying to create a table with a primary key. Every
test thereafter failed immediately [pqReadData() -- backend closed the
channel unexpectedly]; it appears that the primary key error messes up
the postmaster in some way.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"For the LORD is good; his mercy is everlasting; and
his truth endureth to all generations."
Psalms 100:5
From bouncefilter Wed Jan 12 05:51:35 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA80874
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 05:51:00 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id DAA10247;
Wed, 12 Jan 2000 03:13:08 -0800 (PST)
Date: Wed, 12 Jan 2000 03:13:08 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Adriaan Joubert <a.joubert@albourne.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] BlowAwayRelationBuffers
Message-ID: <20000112031308.S9397@fw.wintelcom.net>
References: <387C3232.85F1E291@albourne.com> <9212.947665482@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <9212.947665482@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Wed, Jan 12, 2000 at 03:24:42AM -0500
* Tom Lane <tgl@sss.pgh.pa.us> [000112 00:56] wrote:
Adriaan Joubert <a.joubert@albourne.com> writes:
Hmmm, I got the following this morning on version 6.5.2 on DEC Alpha
during a vacuum verbose analyze. Ended up with duplicate rows of
everything.Really!? The referencecount failure doesn't surprise me a whole lot,
given the refcount bugs that I fixed a couple months ago (no, those
fixes are not in 6.5.* :-(). But VACUUM is supposed to be guaranteed
proof against generating duplicate tuples by design --- that's what
all the HEAP_MOVED_OFF and HEAP_MOVED_IN foofaraw is about.Perhaps there is a glitch in the tuple validity checking logic for
HEAP_MOVED_OFF/HEAP_MOVED_IN? Anyone see it?Given that this was on an Alpha, it could be a 64-bit-platform-
dependency kind of bug...
We've seen this on postgresql 6.5.3 on i386+FreeBSD 4.0, the only
way I was able to fix it was by dumping the entire table, running
sort on it and re-importing it.
Btw, I'd be interested in your opinion on the issues I recently
brought up with libpq when you have the time.
-Alfred
regards, tom lane
From bouncefilter Wed Jan 12 06:20:37 2000
Received: from cap-ferrat.albourne.com (cap-ferrat.albourne.com
[195.89.178.227]) by hub.org (8.9.3/8.9.3) with ESMTP id GAA87310
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 06:20:31 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (bishop-rock.albourne.com [195.89.178.230])
by cap-ferrat.albourne.com (8.9.3/8.9.3/Albourne/UKS/2.9/MAPS) with
ESMTP id LAA10106; Wed, 12 Jan 2000 11:20:09 GMT
Sender: a.joubert@albourne.com
Message-ID: <387C636F.B7B16CFD@albourne.com>
Date: Wed, 12 Jan 2000 11:20:15 +0000
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] BlowAwayRelationBuffers
References: <000201bf5cdb$c31fd620$2801007e@tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thanks Hiroshi, I will patch my database and see whether that helps. Guess
i really ought to upgrade to 6.5.3, but I had some compile problems on
Alpha which I haven't looked at closely yet.
thanks again,
Adriaan
From bouncefilter Wed Jan 12 07:24:36 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA02212
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 07:24:27 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max06-010.enterprise.net
[194.72.197.70])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id MAA10313;
Wed, 12 Jan 2000 12:24:25 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id MAA06987;
Wed, 12 Jan 2000 12:24:15 GMT
Message-Id: <200001121224.MAA06987@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] CREATE TABLE ... PRIMARY KEY kills backend
In-Reply-To: Message from "Oliver Elphick" <olly@lfix.co.uk> of "Wed,
12 Jan 2000 10:31:43 GMT." <200001121031.KAA02056@linda.lfix.co.uk>
References: <200001112229.WAA13417@linda.lfix.co.uk>
<7843.947635740@sss.pgh.pa.us> <200001121031.KAA02056@linda.lfix.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 12 Jan 2000 12:24:14 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
"Oliver Elphick" wrote:
I don't have any line number info, so I'll have to rebuild in order to
do more detailed tracing.
QUERY: create table oljunk (id char(2) primary key, name text);
(gdb) n
134 _outNode(str, node->raw_default);
(gdb) p *str
$25 = {
data = 0x81dd788 "{ QUERY :command 5 :create oljunk { CREATE :relname oljunk :istemp false \t:columns ({ COLUMNDEF :colname id :typename { TYPENAME :name bpchar :timezone false :setof false typmod 6 :arrayBounds :arr"..., len = 263,
maxlen = 512}
(gdb) n
135 appendStringInfo(str, " :cooked_default %s :constraints ",
(gdb) n
137 _outNode(str, node->constraints);
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0x400f068a in _IO_default_xsputn () from /lib/libc.so.6
This is the backtrace before calling _outNode() at 137:
#0 _outColumnDef (str=0xbfffe8cc, node=0x81dd610) at outfuncs.c:137
str = 0xbfffe8cc
node = (ColumnDef *) 0x81dd610
#1 0x80c43da in _outNode (str=0xbfffe8cc, obj=0x81dd610) at outfuncs.c:1355
str = 0xbfffe8cc
obj = (void *) 0x81dd610
#2 0x80c408c in _outNode (str=0xbfffe8cc, obj=0x81dd970) at outfuncs.c:1336
l = (List *) 0x81dd970
str = 0xbfffe8cc
obj = (void *) 0x81dd970
#3 0x80c21ac in _outCreateStmt (str=0xbfffe8cc, node=0x81dd7b8)
at outfuncs.c:74
str = 0xbfffe8cc
node = (CreateStmt *) 0x81dd7b8
#4 0x80c43ba in _outNode (str=0xbfffe8cc, obj=0x81dd7b8) at outfuncs.c:1348
str = 0xbfffe8cc
obj = (void *) 0x81dd7b8
#5 0x80c2588 in _outQuery (str=0xbfffe8cc, node=0x81dd8e8) at outfuncs.c:185
str = 0xbfffe8cc
node = (Query *) 0x81dd8e8
#6 0x80c440a in _outNode (str=0xbfffe8cc, obj=0x81dd8e8) at outfuncs.c:1364
str = 0xbfffe8cc
obj = (void *) 0x81dd8e8
#7 0x80c480d in nodeToString (obj=0x81dd8e8) at outfuncs.c:1570
obj = (void *) 0x81dd8e8
str = {
data = 0x81ddc20 "{ QUERY :command 5 :create oljunk { CREATE :relname oljunk :istemp false \t:columns ({ COLUMNDEF :colname id :typename { TYPENAME :name bpchar :timezone false :setof false typmod 6 :arrayBounds :arr"..., len = 298,
maxlen = 512}
#8 0x80ed7a1 in pg_parse_and_plan (
query_string=0x8184da0 "create table oljunk (id char(2) primary key, name text)", typev=0x0, nargs=0, queryListP=0xbfffe97c, dest=Remote,
aclOverride=0 '\000') at postgres.c:435
query_string = 0x81dd8e8 "X\002"
aclOverride = 0 '\000'
querytree_list = (List *) 0x81dd8e8
plan_list = (List *) 0x0
querytree_list_item = (List *) 0x81dda60
querytree = (Query *) 0x81dd8e8
plan = (Plan *) 0x81dd8e8
new_list = (List *) 0x0
rewritten = (List *) 0xf5
Now we run on a bit, and we go into a recursive loop inside _outNode:
_outNode (str=0xbfffe8cc, obj=0x81dd9a0) at outfuncs.c:1323
1323 if (obj == NULL)
(gdb) p *str
$21 = {
data = 0x81dde28 "{ QUERY :command 5 :create oljunk { CREATE :relname oljunk :istemp false \t:columns ({ COLUMNDEF :colname id :typename { TYPENAME :name bpchar :timezone false :setof false typmod 6 :arrayBounds :arrayBounds <>} :is_not_null true :is_sequence false :raw_default <> :cooked_default <> :constraints ({ oljunk_pkey :type PRIMARY KEY ({ COLUMNDEF :colname id :typename { TYPENAME :name bpchar :timezone false :setof false typmod 6 :arrayBounds :arrayBounds <>} :is_not_null true :is_sequence false :raw_default <> :cooked_default <> :constraints ({ oljunk_pkey :type PRIMARY KEY ({ COLUMNDEF :colname id :typename { TYPENAME :name bpchar :timezone false :setof false typmod 6 :arrayBounds :arrayBounds <>} :is_not_null true :is_sequence false :raw_default <> :cooked_default <> :constraints ({ oljunk_pkey :type PRIMARY KEY ", len = 823, maxlen = 1024}
(gdb)
(gdb) bt
#0 _outNode (str=0xbfffe8cc, obj=0x81dd9a0) at outfuncs.c:1323
#1 0x80c3f8a in _outConstraint (str=0xbfffe8cc, node=0x81dd5e8)
at outfuncs.c:1283
#2 0x80c476a in _outNode (str=0xbfffe8cc, obj=0x81dd5e8) at outfuncs.c:1528
#3 0x80c408c in _outNode (str=0xbfffe8cc, obj=0x81dd660) at outfuncs.c:1336
#4 0x80c2406 in _outColumnDef (str=0xbfffe8cc, node=0x81dd610)
at outfuncs.c:137
#5 0x80c43da in _outNode (str=0xbfffe8cc, obj=0x81dd610) at outfuncs.c:1355
#6 0x80c408c in _outNode (str=0xbfffe8cc, obj=0x81dd9a0) at outfuncs.c:1336
#7 0x80c3f8a in _outConstraint (str=0xbfffe8cc, node=0x81dd5e8)
at outfuncs.c:1283
#8 0x80c476a in _outNode (str=0xbfffe8cc, obj=0x81dd5e8) at outfuncs.c:1528
#9 0x80c408c in _outNode (str=0xbfffe8cc, obj=0x81dd660) at outfuncs.c:1336
#10 0x80c2406 in _outColumnDef (str=0xbfffe8cc, node=0x81dd610)
at outfuncs.c:137
#11 0x80c43da in _outNode (str=0xbfffe8cc, obj=0x81dd610) at outfuncs.c:1355
#12 0x80c408c in _outNode (str=0xbfffe8cc, obj=0x81dd9a0) at outfuncs.c:1336
#13 0x80c3f8a in _outConstraint (str=0xbfffe8cc, node=0x81dd5e8)
at outfuncs.c:1283
#14 0x80c476a in _outNode (str=0xbfffe8cc, obj=0x81dd5e8) at outfuncs.c:1528
#15 0x80c408c in _outNode (str=0xbfffe8cc, obj=0x81dd660) at outfuncs.c:1336
#16 0x80c2406 in _outColumnDef (str=0xbfffe8cc, node=0x81dd610)
at outfuncs.c:137
#17 0x80c43da in _outNode (str=0xbfffe8cc, obj=0x81dd610) at outfuncs.c:1355
#18 0x80c408c in _outNode (str=0xbfffe8cc, obj=0x81dd970) at outfuncs.c:1336
#19 0x80c21ac in _outCreateStmt (str=0xbfffe8cc, node=0x81dd7b8)
at outfuncs.c:74
#20 0x80c43ba in _outNode (str=0xbfffe8cc, obj=0x81dd7b8) at outfuncs.c:1348
#21 0x80c2588 in _outQuery (str=0xbfffe8cc, node=0x81dd8e8) at outfuncs.c:185
#22 0x80c440a in _outNode (str=0xbfffe8cc, obj=0x81dd8e8) at outfuncs.c:1364
#23 0x80c480d in nodeToString (obj=0x81dd8e8) at outfuncs.c:1570
#24 0x80ed7a1 in pg_parse_and_plan (
query_string=0x8184da0 "create table oljunk (id char(2) primary key, name text)", typev=0x0, nargs=0, queryListP=0xbfffe97c, dest=Remote,
aclOverride=0 '\000') at postgres.c:435
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"For the LORD is good; his mercy is everlasting; and
his truth endureth to all generations."
Psalms 100:5
From bouncefilter Wed Jan 12 08:13:36 2000
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 IAA21001
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 08:13:14 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id WAA25084;
Wed, 12 Jan 2000 22:13:11 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-10 [133.137.84.10])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id WAA02424;
Wed, 12 Jan 2000 22:13:08 +0900
To: olly@lfix.co.uk
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org, olly@linda.lfix.co.uk
Subject: Re: [HACKERS] CREATE TABLE ... PRIMARY KEY kills backend
In-Reply-To: <200001121031.KAA02056@linda.lfix.co.uk>
References: <7843.947635740@sss.pgh.pa.us> <tgl@sss.pgh.pa.us>
<200001121031.KAA02056@linda.lfix.co.uk>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000112221401C.t-ishii@sra.co.jp>
Date: Wed, 12 Jan 2000 22:14:01 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 17
./configure --with-tcl --with-mb=UNICODE --with-odbc --enable-locale
--with-maxbackends=64 --with-pgport=5431 --program-prefix=pg7.
I didn't see your problem here. My configuratuion is:
./configure --with-mb=EUC_JP
The reason is that regress.sh uses createdb; createdb has a bad test for
the encoding value (I have sent a patch separately). So I assume no-one
has run regression tests with multibyte-encoding enabled?
Thank you for the fix. I have just committed your changes.
I already have fixed that too with my private working files, but
forgot to commit.
--
Tatsuo Ishii
From bouncefilter Wed Jan 12 08:20:37 2000
Received: from spam.sch.bme.hu (spam.sch.bme.hu [152.66.226.210])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA21817
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 08:19:50 -0500 (EST)
(envelope-from dlux@spam.sch.bme.hu)
Received: from dlux by spam.sch.bme.hu with local (Exim 3.11 #1)
id 128NgH-0003q3-00
for pgsql-hackers@postgreSQL.org; Wed, 12 Jan 2000 14:19:21 +0100
Date: Wed, 12 Jan 2000 14:19:21 +0100
From: dLux <dlux@dlux.hu>
To: pgsql-hackers@postgresql.org
Subject: PostgreSQL performance problems: heavy load
Message-ID: <20000112141921.A14707@dlux.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
Sender: dLux <dlux@spam.sch.bme.hu>
Hello!
We have been starting a project 3 months ago with postgresql. It
is a portal site.
Now we have 12000 users, and every page hit generates an update to
this table. This makes it _very_ fragmented after one day (60000
update/day), so we run vacuum hourly (only for this table) and daily
(for the whole database), and once a week a full backup-restore
session in made. The server has 256M memory, and a raid5 disk in it.
I thought the once-an-hour vacuum would be good, but it is not.
Normally the "vaccumdb --table users dbname" is finished in 10
seconds, but in heavy load this can took 5-6 minutes, and the web is
unusable in this period! This is a very big problem. We have the
usual performance inprovements added (-o -F, more buffers, etc), but
it seems that sometimes the VACUUM doesn't work properly.
When vaccum is active, the other postgres processes eats up my cpu
time, and _this_ makes the situation wronger!
We are using postgersql 6.5.2 on a Pentium II 450 machine (RedHat
Linux 6.0 with security patches).
The database contains a word-index table which have about 2
million entries. It is not so often updated, so this is not required
to be vacuumed more frequent than one days.
If we fail to make vacuum in the scheduled period (e.g pg_vlock
stucked in a crash), the postgres processes usually takes more up
CPU time than usual.
Sometimes I see this in my top:
PID USER PRI NI SIZE SWAP RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
31944 postgres 7 0 3916 0 3916 3232 R 0 6.0 1.5 0:00
/opt/postgres/bin/postgres localhost www kapu idle
31600 postgres 0 0 3928 0 3928 3232 S 0 5.2 1.5 0:46
/opt/postgres/bin/postgres localhost www kapu idle
31982 postgres 0 0 3752 0 3752 3176 S 0 3.4 1.4 0:01
/opt/postgres/bin/postgres localhost www kapu idle
Why idle processes eats 6% CPU time? Is it normal?
Do you have any performance-improvement-ideas? We don't want to
spend lotsa money for a commercial dbms (e.g.Adabas D) only because
of the vacuum problem. Postgresql has many users, testers, and
that's why the support is cannot be compared to any commercial
product (maybe for Oracle, but it is too expensive).
I am not in the list, so please reply to my personal address also.
Thanks for the help in advance.
dLux
--
"There are two kinds of people, those who do the work and those who
take the credit. Try to be in the first group; there is less
competiton there."
From bouncefilter Wed Jan 12 10:14:38 2000
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA48630
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 10:14:32 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9D3E76.dip0.t-ipconnect.de
(root@p3E9D3E76.dip0.t-ipconnect.de [62.157.62.118])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id QAA63058
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 16:14:56 +0100 (CET)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id QAA00343
for pgsql-hackers@postgresql.org; Wed, 12 Jan 2000 16:12:16 +0100
Date: Wed, 12 Jan 2000 16:12:16 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: FETCH without FROM/IN
Message-ID: <20000112161216.A334@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
I've been send a patch to the parser that changes the FETCH statement to not
accept an empty portal name anymore and and allows FETCH without IN/FROM.
First of all I really like to add this to ECPG since the different FETCH
syntax is a major compatibility problem. But I do not like to have ECPG's
parser accept the statement while the backend does not. Since this is not a
standard feature I wonder what others think about it.
My point of view is that I'd like to have as much compatibility as possible.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Wed Jan 12 10:19:38 2000
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA49212
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 10:19:26 -0500 (EST)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
IAA03451;
Wed, 12 Jan 2000 08:19:23 -0700 (MST)
Date: Wed, 12 Jan 2000 08:19:23 -0700 (MST)
Message-Id: <200001121519.IAA03451@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: tgl@sss.pgh.pa.us
CC: peter_e@gmx.net, pgsql-hackers@postgreSQL.org
In-reply-to: <9069.947659376@sss.pgh.pa.us> (message from Tom Lane on Wed, 12
Jan 2000 01:42:56 -0500)
Subject: Re: [HACKERS] psql -f inconsistency with "copy from stdin"
References: <Pine.LNX.4.21.0001120359290.3735-100000@localhost.localdomain>
<9069.947659376@sss.pgh.pa.us>
Of course, the question is which way is right...
I can see the potential usefulness of doing
psql -f driving.script <data.file
but on the other hand, it bothers me a good deal that a script
containing
COPY table FROM STDIN;
... data here ...
\.
(as generated by such unheard-of, seldom-used utilities as pg_dump)
would work when sourced by psql <pgdump.script and *fail* when sourced
by psql -f pgdump.script. But that's what will happen if we change
it back.
I suspect the change in behavior from 6.4 to 6.5 may have been a
deliberate change to avoid this failure mode. It'd be worth checking
the archives to see if you can find any discussion about it.
It seems to me that we ought to provide both behaviors, but make sure
that the one that supports data-in-the-script is the one invoked by
COPY FROM STDIN (since that's what pg_dump uses). Perhaps psql's \copy
command can be set up to support the other alternative.
But isn't there a greater difference between copy and \copy than this?
Doesn't one act on the frontend and one on the backend? There needs
to be a mechanism for copying data in through the front end without
special permissions.
Also, it seems unfortunate from a semantics point of view to have COPY
FROM STDIN not actually refer to the stdin file of the process.
Perhaps that is necessary to preserve compatability with old pg_dump
(new versions could be changed in this regard of course), but it is
not what I would naturally expect STDIN to mean in the context of 30
years of Unix development. Further, this use of STDIN clearly
conflicts with the meaning of STDOUT in the analogous copy out command
which doesn't insert the output into the script file but rather
directs it to the stdout file.
In order to maintain some compatability with these broader uses of the
terms STDIN/STDOUT (while still supporting previous pg_dump scripts,
at least for awhile), I think it is worth exploring some options. A
few ideas are:
- Introduce a new syntax for the 6.5.2 here-doc semantics.
Possibilities might include COPY FROM HERE (copy ends at EOF or \.)
or COPY UNTIL <tag> (copy ends at matching <tag>, like shell
here-docs). pg_dump would have to be changed to correspond.
- Introduce a new flag to psql to differentiate the interpretation of
COPY FROM STDIN. This seems confusing to users, but might be
worthwhile (but become deprecated after a few releases) if the
syntax is changed and old pg_dump scripts need supporting. New
scripts and new pg_dump needn't worry about this if they use the new
syntax.
Cheers,
Brook
From bouncefilter Wed Jan 12 10:31:46 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA52833
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 10:31:37 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA09706;
Wed, 12 Jan 2000 10:31:30 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] CREATE TABLE ... PRIMARY KEY kills backend
In-reply-to: <200001121031.KAA02056@linda.lfix.co.uk>
References: <200001112229.WAA13417@linda.lfix.co.uk>
<7843.947635740@sss.pgh.pa.us>
<200001121031.KAA02056@linda.lfix.co.uk>
Comments: In-reply-to "Oliver Elphick" <olly@lfix.co.uk>
message dated "Wed, 12 Jan 2000 10:31:43 +0000"
Date: Wed, 12 Jan 2000 10:31:29 -0500
Message-ID: <9703.947691089@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Oliver Elphick" <olly@lfix.co.uk> writes:
Segmentation fault (in the end):
#0 0x400f068d in _IO_default_xsputn () from /lib/libc.so.6
#1 0x400e0126 in vfprintf () from /lib/libc.so.6
#2 0x400edf23 in vsnprintf () from /lib/libc.so.6
#3 0x80a8e82 in appendStringInfo ()
#4 0x80c244d in _outTypeName ()
#5 0x80c43da in _outNode ()
#6 0x80c2391 in _outColumnDef ()
...
#157128 0x80c23f6 in _outColumnDef ()
#157129 0x80c43ca in _outNode ()
#157130 0x80c407c in _outNode ()
^^^^^^
Hmm, I take it this is a stack-growth-limit-exceeded failure, although
your system isn't reporting it that way.
This is a known bug that's been there for quite a while: PRIMARY KEY
generates a parse tree with circular references, so if you have parse
tree dumping turned on, you get an infinite recursion in the dumper
code. It needs to be fixed, but hasn't gotten to the top of anyone's
to-do list (and a clean way to fix it isn't obvious).
I fixed the createdb bug and ran the regression test. The constraints
test failed when trying to create a table with a primary key.
If you had -d set high enough, it would...
Every
test thereafter failed immediately [pqReadData() -- backend closed the
channel unexpectedly]; it appears that the primary key error messes up
the postmaster in some way.
The WAL postmaster takes a few seconds to recover before it will allow
new connections (I have a proposal on the table that it should just
delay accepting the connections, instead of rejecting 'em, but there
hasn't been any discussion about that). I usually see that the next
three or four regression tests fail after a crash, but if your machine
is fast enough it might be that they all do.
I have noticed that recent versions of libpq fail to display the
connection-refused error message that I assume the postmaster is
returning. That useta work ... someone broke it ...
regards, tom lane
From bouncefilter Wed Jan 12 10:47:38 2000
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 KAA56678
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 10:47:24 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id KAA02308
for pgsql-hackers@postgreSQL.org; Wed, 12 Jan 2000 10:41:53 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001121541.KAA02308@candle.pha.pa.us>
Subject: TODO list updated
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Wed, 12 Jan 2000 10:41:53 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have updated the TODO list to mark all the items that are completed
for 7.0.
Are there any additional ones? Are there some names I have forgotten to
attribute to items?
Let me know.
--
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 Jan 12 10:50:40 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA57147
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 10:49:47 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA09820;
Wed, 12 Jan 2000 10:49:34 -0500 (EST)
To: Brook Milligan <brook@biology.nmsu.edu>
cc: peter_e@gmx.net, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql -f inconsistency with "copy from stdin"
In-reply-to: <200001121519.IAA03451@biology.nmsu.edu>
References: <Pine.LNX.4.21.0001120359290.3735-100000@localhost.localdomain>
<9069.947659376@sss.pgh.pa.us>
<200001121519.IAA03451@biology.nmsu.edu>
Comments: In-reply-to Brook Milligan <brook@biology.nmsu.edu>
message dated "Wed, 12 Jan 2000 08:19:23 -0700"
Date: Wed, 12 Jan 2000 10:49:34 -0500
Message-ID: <9817.947692174@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Brook Milligan <brook@biology.nmsu.edu> writes:
It seems to me that we ought to provide both behaviors, but make sure
that the one that supports data-in-the-script is the one invoked by
COPY FROM STDIN (since that's what pg_dump uses). Perhaps psql's \copy
command can be set up to support the other alternative.
But isn't there a greater difference between copy and \copy than this?
Doesn't one act on the frontend and one on the backend?
Not when it's COPY FROM STDIN or TO STDOUT --- from the backend's point of
view, that means transfer data from or to the frontend. What psql
does with it is psql's concern.
(Actually, \copy is implemented by sending a COPY FROM STDIN/TO STDOUT
command to the backend; the backend can't tell the difference between
the two cases, and has no way to know where the data is really coming
from or going to on the client side.)
- Introduce a new syntax for the 6.5.2 here-doc semantics.
Possibilities might include COPY FROM HERE (copy ends at EOF or \.)
Changing the SQL command is the wrong thing to think about, because
the parameter would only be known at the backend which is not where
it needs to be known to change psql's behavior. Furthermore, from
the backend's point of view it *is* sending to or from the only
"user interface" it's got. So I don't think there's anything wrong
with the definition of the SQL COPY command. You should be thinking
about adding options to psql's \copy, instead, if you want more
flexibility in controlling where psql gets or puts data.
pg_dump would have to be changed to correspond.
IMHO any proposal that requires changing pg_dump is a non-starter,
because it will fail when people try to load 6.5 or earlier dumps
into 7.0. But fortunately, pg_dump doesn't use \copy ...
regards, tom lane
From bouncefilter Wed Jan 12 10:42:38 2000
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 KAA55754
for <hackers@postgresql.org>; Wed, 12 Jan 2000 10:41:54 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA05158;
Wed, 12 Jan 2000 15:50:19 GMT
Sender: lockhart@hub.org
Message-ID: <387CA2BB.566B01D9@alumni.caltech.edu>
Date: Wed, 12 Jan 2000 15:50: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: bdboy@samsung.co.kr, Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [Fwd: Help Me]
References: <387C06C7.4B6BAF23@jpl.nasa.gov>
Content-Type: multipart/mixed; boundary="------------9DAD992243FD2598C1B2DC7F"
This is a multi-part message in MIME format.
--------------9DAD992243FD2598C1B2DC7F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm Korean. and I can't speak English well.
I want to know PostgreSQL 6.5.3 's int8(array)
My System is Redhat 6.1, Pentium.
and I make array int8 data type.
so I make int8 by ./contrib/int8 package.
int8 is now a built-in type, but...
create table lr(val int8[][][]);
ERROR: Unable to locate type name '_int8' in catalog
Why ERROR: Unable to locate type name '_int8' in catalog
but Not use array ---> Ok.
It looks like you have uncovered a bug in Postgres; there is no
catalog entry for the int8 array type. It should be fixed in the next
release.
I am sending you a patch, but my Postgres installation is torn apart
at the moment so it is not tested!! Perhaps one of the other
developers will be able to test and commit a patch to fix this problem
sooner than I.
Thanks for the report, and sorry that it currently does not work for
you.
The patch should be applied to the source code as follows:
1) cd src/include/catalog
2) patch < pg_type.h.patch
3) cd ../.. # (to src directory)
4) make clean
5) make install
6) rm -rf ../data # or wherever your postgres data directory is
7) initdb
8) restart postmaster
Good luck.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
--------------9DAD992243FD2598C1B2DC7F
Content-Type: text/plain; charset=us-ascii;
name="pg_type.h.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="pg_type.h.patch"
*** pg_type.h.orig Mon Jan 3 08:27:36 2000
--- pg_type.h Wed Jan 12 15:40:40 2000
***************
*** 328,333 ****
--- 328,334 ----
DATA(insert OID = 1013 ( _oid8 PGUID -1 -1 f b t \054 0 30 array_in array_out array_in array_out i _null_ ));
DATA(insert OID = 1014 ( _bpchar PGUID -1 -1 f b t \054 0 1042 array_in array_out array_in array_out i _null_ ));
DATA(insert OID = 1015 ( _varchar PGUID -1 -1 f b t \054 0 1043 array_in array_out array_in array_out i _null_ ));
+ DATA(insert OID = 1016 ( _int8 PGUID -1 -1 f b t \054 0 20 array_in array_out array_in array_out d _null_ ));
DATA(insert OID = 1017 ( _point PGUID -1 -1 f b t \054 0 600 array_in array_out array_in array_out d _null_ ));
DATA(insert OID = 1018 ( _lseg PGUID -1 -1 f b t \054 0 601 array_in array_out array_in array_out d _null_ ));
DATA(insert OID = 1019 ( _path PGUID -1 -1 f b t \054 0 602 array_in array_out array_in array_out d _null_ ));--------------9DAD992243FD2598C1B2DC7F--
From bouncefilter Wed Jan 12 11:09:39 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA63634;
Wed, 12 Jan 2000 11:09:20 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA09920;
Wed, 12 Jan 2000 11:09:11 -0500 (EST)
To: Michael Meskes <meskes@postgreSQL.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FETCH without FROM/IN
In-reply-to: <20000112161216.A334@fam-meskes.de>
References: <20000112161216.A334@fam-meskes.de>
Comments: In-reply-to Michael Meskes <meskes@postgreSQL.org>
message dated "Wed, 12 Jan 2000 16:12:16 +0100"
Date: Wed, 12 Jan 2000 11:09:11 -0500
Message-ID: <9917.947693351@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Meskes <meskes@postgreSQL.org> writes:
I've been send a patch to the parser that changes the FETCH statement to not
accept an empty portal name anymore and and allows FETCH without IN/FROM.
First of all I really like to add this to ECPG since the different FETCH
syntax is a major compatibility problem. But I do not like to have ECPG's
parser accept the statement while the backend does not. Since this is not a
standard feature I wonder what others think about it.
It looks to me like the backend grammar *does* accept FETCH without
IN/FROM cursor. Which seems pretty bizarre --- I don't understand how
it makes sense to omit a cursor name from FETCH.
Looking at the SQL92 spec, it seems we are mighty far away from any
defensible reading of the spec :-(. The spec says
<fetch statement> ::=
FETCH [ [ <fetch orientation> ] FROM ]
<cursor name> INTO <fetch target list>
<fetch orientation> ::=
NEXT
| PRIOR
| FIRST
| LAST
| { ABSOLUTE | RELATIVE } <simple value specification>
<fetch target list> ::=
<target specification> [ { <comma> <target specification> }... ]
whereas gram.y has
FetchStmt: FETCH opt_direction fetch_how_many opt_portal_name
| MOVE opt_direction fetch_how_many opt_portal_name
;
opt_direction: FORWARD
| BACKWARD
| RELATIVE
| ABSOLUTE
| /*EMPTY*/
;
fetch_how_many: Iconst
| '-' Iconst
| ALL
| NEXT
| PRIOR
| /*EMPTY*/
;
opt_portal_name: IN name
| FROM name
| /*EMPTY*/
;
Are we compatible with anything at all???
regards, tom lane
From bouncefilter Wed Jan 12 11:21:39 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA65405
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 11:21:11 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA64581;
Wed, 12 Jan 2000 12:20:00 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 12 Jan 2000 12:19:59 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Brook Milligan <brook@biology.nmsu.edu>, peter_e@gmx.net,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql -f inconsistency with "copy from stdin"
In-Reply-To: <9817.947692174@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001121218080.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 12 Jan 2000, Tom Lane wrote:
pg_dump would have to be changed to correspond.
IMHO any proposal that requires changing pg_dump is a non-starter,
because it will fail when people try to load 6.5 or earlier dumps
into 7.0. But fortunately, pg_dump doesn't use \copy ...
I'm confused here...why would "any proposal that requires changing pg_dump
is a non-starter"? How does changing pg_dump in v7.0 affect pg_dump in
v6.5?
As long as I can reload my v6.5 data into a v7.0 database using the
pg_dump from v6.5, confused as to why v7.0s pg_dump matters...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Jan 12 11:53:40 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA74552;
Wed, 12 Jan 2000 11:52:55 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id LAA29511;
Wed, 12 Jan 2000 11:23:39 -0500 (EST) (envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
Sender: ckempf@singularity.enigami.com
X-Newsgroups: comp.databases.postgresql, comp.databases.postgresql.admin,
comp.databases.postgresql.hackers,
comp.databases.postgresql.questions, linux.act.postgres
Subject: Re: postgresql installation
References: <387c40b0@feednews.internext.fr>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Cory Kempf <ckempf@enigami.com>
Message-ID: <5faembw96k.fsf@singularity.enigami.com>
Lines: 30
X-Newsreader: Gnus v5.6.45/XEmacs 21.1 - "Big Bend"
X-Trace: tw11.nn.bcandid.com 947694214 216.204.32.42 (Wed,
12 Jan 2000 09:23:34 MST)
Organization: bCandid - Powering the world's discussions - http://bCandid.com
Date: Wed, 12 Jan 2000 16:23:35 GMT
To:
pgsql-hackers@postgresql.org.pgsql-admin@postgresql.org.pgsql-questions@postgresql.org
"Netra systems" <julien@netra-systems.com> writes:
hello,
i have pb with the postgre sql installation :
i compile all .. ok
but when i want to run postmaster or anything else it say : no db dir :
data/../template1 ...
i have no data dir in my postgre dinstalled dir ....
how can i have this dir with all into ?
Have you run initdb? My guess is no.
Also, when you run initdb, the data directory it uses (I use /var/lib/pgsql,
which I set up by having my .zshrc file export PGDATA=/var/lib/pgsql
for my postgres account) needs to be the same as that passed to postmaster
via the -D option.
Oh, initdb really should be run as the postgres user. Definately not as
root! Make sure your permissions are set up ahead of time!
+C
--
Have you signed up to be a bone marrow doner? All it takes is a simple
blood test, and it can save a life. <http://www.marrow.org>
Cory Kempf Macintosh / Unix Consulting & Software Development
ckempf@enigami.com <http://www.enigami.com/~ckempf/>
From bouncefilter Wed Jan 12 11:21:45 2000
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 LAA65391
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 11:20:54 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA05228;
Wed, 12 Jan 2000 16:26:05 GMT
Sender: lockhart@hub.org
Message-ID: <387CAB1D.57B20461@alumni.caltech.edu>
Date: Wed, 12 Jan 2000 16:26:05 +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: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: [SQL] createdb -D xxxx not working
References: <Pine.LNX.4.21.0001120312180.3735-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Darn, now I already rewrote the thing to where I considered it working. We
had several on-and-off discussions (mostly Tom and I) about it during the
last two months at least, including users complaining.
afaik I've been on the hackers list most of the time, and don't recall
significant discussion.
The sort of scheme I came up with scraps the environment variable stuff
(since it's not quite safe either and has several bugs in the code that
create a bunch of problems along the way) and lets the following
happen (example paths):CREATE DATABASE foo; --> /usr/local/pgsql/data/base/foo/pg_class
CREATE DATABASE foo WITH LOCATION 'bar';
--> /usr/local/pgsql/data/base/bar/pg_class
CREATE DATABASE foo WITH LOCATION '/some/where';
--> /some/where/pg_class
CREATE DATABASE foo WITH LOCATION 'foo/bar';
is disabled. I suppose I could stick the
environment variable deal back in so that users don't have to remember any
complicated paths, but this is the dbadmin's job anyway, so he should be
able to remember it.
Huh? The "environment variable deal" is intended to provide security
and easier operation. The examples above which allow specifying
absolute paths (e.g. "/some/where/pg_class") are specifically
disallowed by default, for a reason. If there were bugs in that, let's
talk about it, but I'm *very* uncomfortable making wholesale changes
without a discussion. And what exactly were "several bugs in the
code"?? Better be specific; that's my code we're talking about :/
It sounds like you and Tom Lane have had discussions on this, but I'm
not certain it was with a clear understanding of what the environment
variables provided. Before killing the capability, I'd like to make
sure that we understand what it did.
otoh, you have a new proposal (the first I've heard of it afaik)...
Anyway, in order for a path to be allowed it has to be listed in
PG_ALTLOC, which is a colon-delimited, marginally wildcard enabled list of
allowed locations. In some future life this could be included in a
configuration file.
That sounds like a good capability. There is no reason (yet) why the
environment variable mechanism can not use this too; e.g.
setenv PG_ALTLOC PGDATA2:/home/peter/unsafe/unprotected/open/path
(just had to put that last one in :)))
initlocation is used to create the directory structure *with correct
permissions* for an alternate location. It takes an environmentI think one of the problems was actually that the path initlocation
assumed and the one createdb worked with were different.
I'm not sure to what you are referring. To the fact that there is an
implicit "/base" in the actual path? e.g.
initlocation PGDATA2
createdb -D PGDATA2 test
gives an actual path $PGDATA2/base/pg_class ? That's a
security/integrity benefit since:
1) there is not likely to be a random environment variable which
happens to point to a valid directory which *also* has a subdirectory
called "base".
2) it reduces the chance that a user/dbadmin will not use initlocation
to create the database area, hence reducing the chance that a
user/dbadmin has not set the permissions correctly.
variable because usually the backend should have that same environment
variable defined to ensure consistancy and as a security measure. The
environment variable can be expanded or not; initlocation does the
right thing in either case.It's false security though, since for complete security the dbadmin would
have to delete all other environment variables altogether.
Theoretically true (though low-risk per above discussion), but this
would be addressed by your PG_ALTLOC augmentation, which I like btw.
I'd vote for taking
out the auto-expansion, so that the correct invocation becomes
initlocation $PGDATA2
which is what an average user would expect.But the average user does not necessarily have access to the PGDATA2
environment variable! This is usually a sysadmin function.The average user doesn't even have access to the machine the database is
running on, so he can't do any initlocation either way. Then again the
average user doesn't create databases either. But there is no real point
for initlocation since a mere mkdir() call in createdb() will do the job.
Hmm. Until I see what you are actually doing, I can't comment on
whether this is indeed adequate. But decoupling the location creation
from database creation give the dbadmin control over how permissions
are set and where databases can be created. I'm not sure that is the
case if it is all done within the backend at database creation time.
Now I just got done with that coding 10 minutes ago but now that someone
actually spoke up in defence of this mechanism I'm going to wait and see
what you think about the revised (or any) scheme.
PG_ALTLOC seems to be a great feature. But afaict the environment
variable feature is useful, safe (as much or more so than absolute
paths, anyway), can coexist, and is a convenience.
I'd like to continue the discussion until I'm convinced, or least
beaten into submission ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Jan 12 11:36:40 2000
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 LAA71236;
Wed, 12 Jan 2000 11:36:12 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA05256;
Wed, 12 Jan 2000 16:43:07 GMT
Sender: lockhart@hub.org
Message-ID: <387CAF1B.A4F9466B@alumni.caltech.edu>
Date: Wed, 12 Jan 2000 16:43:07 +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: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FETCH without FROM/IN
References: <20000112161216.A334@fam-meskes.de> <9917.947693351@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Looking at the SQL92 spec, it seems we are mighty far away from any
defensible reading of the spec :-(...
Are we compatible with anything at all???
Although not rigorously compatible, it appears that we do allow
compatible syntax:
FETCH 4 FROM t1;
FETCH NEXT FROM t1;
But afaik our cursor behavior does not currently allow supporting
FETCH FIRST FROM t1; -- cursor can't be positioned to first/last
FETCH ABSOLUTE 4 FROM t1; -- not sure about this one...
FETCH RELATIVE 4 FROM t1; -- this could be a MOVE/FETCH combination?
so we, uh, don't support it (yet).
I'd suggest definitely supporting all SQL92 syntax that the cursor can
manage, and also supporting the existing Postgres behaviors (which may
only be a simple subset). If we have just *alternate* syntax for the
same thing, then v7.0 would be a good time to straighten it up.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Jan 12 14:12:41 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id OAA17454
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 14:12:34 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 24850 invoked from network); 12 Jan 2000 19:12:32 -0000
Received: from h-62.96.160.208.host.de.colt.net (root@62.96.160.208)
by pille.addcom.de with SMTP; 12 Jan 2000 19:12:32 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id RAA02384
for pgsql-hackers@postgreSQL.org; Wed, 12 Jan 2000 17:53:26 +0100
Date: Wed, 12 Jan 2000 17:53:26 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FETCH without FROM/IN
Message-ID: <20000112175326.A2376@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000112161216.A334@fam-meskes.de> <9917.947693351@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <9917.947693351@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Wed, Jan 12, 2000 at 11:09:11AM -0500
On Wed, Jan 12, 2000 at 11:09:11AM -0500, Tom Lane wrote:
It looks to me like the backend grammar *does* accept FETCH without
IN/FROM cursor. Which seems pretty bizarre --- I don't understand how
it makes sense to omit a cursor name from FETCH.
Yes, it does accept if NO portal name is given. This is corrected by the
patch. But what I wanted to talk about is the IN/FROM keyword.
<fetch statement> ::=
FETCH [ [ <fetch orientation> ] FROM ]
<cursor name> INTO <fetch target list>
To me this seems to say that FROM is just optional. Okay, if I make it
optional in our parser?
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Wed Jan 12 14:12:41 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id OAA17458
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 14:12:37 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 24844 invoked from network); 12 Jan 2000 19:12:31 -0000
Received: from h-62.96.160.208.host.de.colt.net (root@62.96.160.208)
by pille.addcom.de with SMTP; 12 Jan 2000 19:12:31 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id RAA02395
for pgsql-hackers@postgreSQL.org; Wed, 12 Jan 2000 17:56:37 +0100
Date: Wed, 12 Jan 2000 17:56:37 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FETCH without FROM/IN
Message-ID: <20000112175637.B2376@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000112161216.A334@fam-meskes.de> <9917.947693351@sss.pgh.pa.us>
<387CAF1B.A4F9466B@alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <387CAF1B.A4F9466B@alumni.caltech.edu>;
from lockhart@alumni.caltech.edu on Wed, Jan 12, 2000 at
04:43:07PM +0000
On Wed, Jan 12, 2000 at 04:43:07PM +0000, Thomas Lockhart wrote:
FETCH RELATIVE 4 FROM t1; -- this could be a MOVE/FETCH combination?
so we, uh, don't support it (yet).
How about
FETCH t1;?
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Wed Jan 12 12:21:40 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA82415
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 12:20:57 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id SAA235736;
Wed, 12 Jan 2000 18:20:49 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALMW58>; Wed, 12 Jan 2000 18:20:49 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC1FC@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'The Hermit Hacker'" <scrappy@hub.org>
Cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
Date: Wed, 12 Jan 2000 18:20:46 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
It would be:
SELECT *
FROM tab1, OUTER tab2
WHERE tab1.col1 = tab2.col2What about >2 table joins? Wish I had my book here, but I though tyou
could do multiple OUTER joins, no?
select * from tab1, OUTER tab2, OUTER (tab3, tab4), tab5,
OUTER tab6, OUTER (tab7, OUTER tab8) where ......
imho understandable syntax.
Andreas
From bouncefilter Wed Jan 12 13:21:40 2000
Received: from netrinsics.com (robinson@[202.106.4.45])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA00958
for <pgsql-hackers@hub.org>; Wed, 12 Jan 2000 13:20:54 -0500 (EST)
(envelope-from robinson@netrinsics.com)
Received: (from robinson@localhost)
by netrinsics.com (8.9.3/8.9.3) id CAA76248;
Thu, 13 Jan 2000 02:21:15 +0800 (CST) (envelope-from robinson)
Date: Thu, 13 Jan 2000 02:21:15 +0800 (CST)
From: Michael Robinson <robinson@netrinsics.com>
Message-Id: <200001121821.CAA76248@netrinsics.com>
To: pgsql-hackers@hub.org
Subject: Copy from/to asymmetry
I set my time zone to GMT+8 today (because the "official" timezone prescribed
by the FreeBSD timezone database for my location is "CST", which was causing
all sorts of other problems elsewhere).
Tonight, when I did my nightly data transfer (consisting of "copy to" a
bunch of tables and concatenating them together into a "pg_dump" type of
script file, copying the file over, and then loading with psql), the
backend was very unhappy.
Every "copy from" block that contained a date crashed. This was particularly
unpleasant, because the script is bracketed within a single transaction block,
and each table is emptied ("delete from") before new data is copied in. As
a result of the crashes, the transaction aborted, but psql kept on processing
away, emptying tables, crashing, and repeat.
This was on a soon-to-be production e-commerce server.
I was able to recover in a few minutes by manually editing the script file
to replace all "GMT+8" with "+0800". Had this happened during an automated
transfer on a live system, however, the problem could have been severe.
I assume that my backups are similarly corrupted.
I looked through dt.c, and ParseDateTime appears to assume that timezones
are either strictly alphabetic or of the form "+0000". EncodeDateTime,
on the other hand, blindly spits out whatever the operating system gives it
from localtime().
It seems to me there are two separate problems:
1. x == datetime_in(datetime_out(x)) should always be true for all valid x.
2. psql should exit with an error status if it receives a fatal error
from the backend and isatty(0) is false.
-Michael Robinson
From bouncefilter Wed Jan 12 14:24:41 2000
Received: from ara.ayu.ics.keio.ac.jp (ara.ayu.ics.keio.ac.jp [131.113.45.43])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA19446
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 14:23:45 -0500 (EST)
(envelope-from kawasima@ayu.ics.keio.ac.jp)
Received: (from kawasima@localhost)
by ara.ayu.ics.keio.ac.jp (8.9.3+3.2W/3.7W) id EAA28410
for pgsql-hackers@postgresql.org; Thu, 13 Jan 2000 04:23:35 +0900 (JST)
Date: Thu, 13 Jan 2000 04:23:35 +0900 (JST)
From: Hideyuki Kawashima <kawasima@ayu.ics.keio.ac.jp>
Message-Id: <200001121923.EAA28410@ara.ayu.ics.keio.ac.jp>
Content-Type: text
To: undisclosed-recipients:;
subscribe
From bouncefilter Wed Jan 12 14:32:44 2000
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 OAA23770
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 14:32:07 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62347 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S202759AbQALTbe>;
Wed, 12 Jan 2000 20:31:34 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128Tb2-0000tc-00; Wed, 12 Jan 2000 20:38:20 +0100
Date: Wed, 12 Jan 2000 20:38:20 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] dubious improvement in new psql
In-Reply-To: <14820.946172131@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001121346410.1646-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Okay, I looked at the code again and I can't see anything wrong
conceptually. It follows libpq semantics which I remember to have grabbed
from the documentation:
results = PQexec(pset->db, query);
/* do something with result */
if (PQstatus(pset->db) == CONNECTION_BAD)
{
fputs("The connection to the server was lost. Attempting reset: ", stderr);
PQreset(pset->db);
if (PQstatus(pset->db) == CONNECTION_BAD)
{
fputs("Failed.\n", stderr);
PQfinish(pset->db);
PQclear(results);
pset->db = NULL;
return false;
}
else
fputs("Succeeded.\n", stderr);
}
If you can still reproduce this somehow, I'd like to know where it hangs
and/or what the output was.
On 1999-12-25, Tom Lane mentioned:
The new psql automatically tries to reconnect if the backend disconnects
unexpectedly. This feature strikes me as ill-conceived; furthermore
it appears to be buggy.It's ill-conceived because:
(1) under WAL, following a backend crash the postmaster is going to be
spending a few seconds reinitializing; an immediate reconnect attempt
is almost guaranteed to fail.
Then rip out PQreset. It's not psql's job to make these kinds of
decisions.
(2) if I'm running an SQL script, I think it's extremely foolhardy
to press on with executing the script as though nothing had happened.
A backend crash is not an event to be lightly ignored.
Then rip out PQreset. To quote from the docs:
"This function will close the connection to the backend and attempt to
reestablish a new connection to the same postmaster, using all the same
parameters previously used. This may be useful for error recovery if a
working connection is lost."
I don't know all the possible ways a backend can go down, but one of them
might be a short network failure. In that case attempting a reset might be
the reasonable thing to do. Again, this should be addressed at the libpq
level.
It's buggy because: it doesn't work reliably. While poking at the
backend's problems with oversize btree index entries, I saw psql claim
it had successfully reconnected, and then go into a catatonic state.
Look at the above code; seems like a libpq problem.
It wouldn't give me a new command prompt (not even with ^C), wouldn't
exit with ^D, and had to be killed from another shell window.This behavior doesn't seem to happen for every crash, but I'm not
really interested in trying to debug it. I think the "feature"
I am. :)
ought to be ripped out.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Jan 12 14:32:43 2000
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 OAA23769
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 14:32:02 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62346 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S194578AbQALTbd>;
Wed, 12 Jan 2000 20:31:33 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128TbB-0000te-00; Wed, 12 Jan 2000 20:38:29 +0100
Date: Wed, 12 Jan 2000 20:38:29 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Brook Milligan <brook@biology.nmsu.edu>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql -f inconsistency with "copy from stdin"
In-Reply-To: <200001112335.QAA00351@biology.nmsu.edu>
Message-ID: <Pine.LNX.4.21.0001121812260.1646-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
After further contemplation I am not completely sure which way is the
correct behaviour. Consider me doing this:
--test.sql
COPY foo FROM stdin;
data data
data data
SELECT * FROM foo;
and running psql -f test.sql < (anything) on it. Then I would expect it
to behave the other way.
The -f option is just another way of saying "get the input from there". If
you use both -f and stdin you're in essence saying "get the input from
there and there", and that feature does not exist in psql and would be
hard to extend to the general case.
On 2000-01-12, Brook Milligan mentioned:
Today I ran into an inconsistency between two versions of postgresql
in how psql handles copies from stdin. At this point I am not sure
how the rewrite of psql does things, but thought I'd mention the
problem in case someone with it installed can check.The issue is how the command
psql -f test.sql db < test.dat
is treated, given the following files:
-- test.sql
drop table test;
create table test (name text);
copy test from stdin;
select * from test;and
test.dat
a
bSpecifically v6.4.2 and v6.5.2 differ in the outcome, with v6.4.2
producing what I would expect and v6.5.2 producing anomalous output.
Note that performing the copy aspsql -c "copy test from stdin" db < test.dat
works fine in either case.
v6.4.2 output: The contents of test.dat are read into the table as
one might expect having redirected that file to stdin and copying from
stdin.v6.5.2 output: The contents of test.dat are not read into the table at
all. Instead, the remainder of the test.sql file (i.e., select * ...)
are read into the table.How does the current version behave when performing these copies? If
it still behaves like 6.5.2, I suspect there is some bug in handling
the copy command.Cheers,
Brook************
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Jan 12 14:38:41 2000
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 OAA24638
for <hackers@postgresql.org>; Wed, 12 Jan 2000 14:38:02 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64669 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S73742AbQALThV>;
Wed, 12 Jan 2000 20:37:21 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128Tgv-0000tu-00
for hackers@postgresql.org; Wed, 12 Jan 2000 20:44:25 +0100
Date: Wed, 12 Jan 2000 20:44:25 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: psql updates
Message-ID: <Pine.LNX.4.21.0001122022550.1646-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
I hope to have fixed all psql bugs that came up in the last month of my
absence. (The array syntax issue itself is not included.) I'd particularly
be interested whether the readline related compilation problem is gone,
since by readline's CHANGELOG I cannot decode when or where the problem
was introduced or removed. In addition, the frequent end user problem "I
did \dt and all my tables were gone" has been eliminated.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Jan 12 15:54:42 2000
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 PAA84891
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 15:53:43 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id PAA13303
for pgsql-hackers@postgreSQL.org; Wed, 12 Jan 2000 15:39:25 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001122039.PAA13303@candle.pha.pa.us>
Subject: Informix and OUTER join syntax
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Wed, 12 Jan 2000 15:38:10 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Looking in the Informix manuals, I now see how they handle complex outer
joins:
SELECT *
FROM tab1, OUTER(tab2, tab3)
WHERE tab1.col1 = tab2.col1 AND
tab2.col1 = tab3.col1
It does the tab2, tab3 join first, then _outer_ joins to tab1.
Interesting.
--
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 Jan 12 15:54:42 2000
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 PAA84906
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 15:53:48 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id PAA13564
for pgsql-hackers@postgreSQL.org; Wed, 12 Jan 2000 15:44:25 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001122044.PAA13564@candle.pha.pa.us>
Subject: Re: Informix and OUTER join syntax
In-Reply-To: From "(env:" "pgman)" at "Jan 12, 2000 03:38:10 pm"
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Wed, 12 Jan 2000 15:43:10 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Looking in the Informix manuals, I now see how they handle complex outer
joins:SELECT *
FROM tab1, OUTER(tab2, tab3)
WHERE tab1.col1 = tab2.col1 AND
tab2.col1 = tab3.col1It does the tab2, tab3 join first, then _outer_ joins to tab1.
Interesting.
Here is another example that does a double outer join:
SELECT *
FROM tab1, OUTER(tab2, OUTER tab3)
WHERE tab1.col1 = tab2.col1 AND
tab2.col1 = tab3.col1
It does the tab2, tab3 as an _outer_ join first, then _outer_ joins to
tab1. Even more interesting.
Can someone show me this in ANSI syntax?
--
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 Jan 12 15:54:47 2000
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA85047
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 15:54:30 -0500 (EST)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
NAA04232;
Wed, 12 Jan 2000 13:54:20 -0700 (MST)
Date: Wed, 12 Jan 2000 13:54:20 -0700 (MST)
Message-Id: <200001122054.NAA04232@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: peter_e@gmx.net
CC: pgsql-hackers@postgreSQL.org
In-reply-to: <Pine.LNX.4.21.0001121812260.1646-100000@localhost.localdomain>
(message from Peter Eisentraut on Wed, 12 Jan 2000 20:38:29 +0100
(CET))
Subject: Re: [HACKERS] psql -f inconsistency with "copy from stdin"
References: <Pine.LNX.4.21.0001121812260.1646-100000@localhost.localdomain>
The -f option is just another way of saying "get the input from there". If
you use both -f and stdin you're in essence saying "get the input from
there and there", and that feature does not exist in psql and would be
hard to extend to the general case.
But there are specifically two kinds of input involved here [*]:
- input of SQL commands and such to psql
- input of data to a COPY command
To me these are conceptually very distinct (in much the same way you
have distinguished already between various output streams; in fact,
I'm not sure how you have matched those with the output stream from
COPY, but it might be relevant to think about that in light of this
discussion). Thus, to me it makes sense to say "take input from there
and there," as long as it is clear that one "there" refers to one
input stream and the other to the other one. For example, -f
naturally refers to the first one above, while the STDIN naturally
refers to the second.
Saying that -f should override all other sources of input is
inconsistent in its own way; after all, that doesn't override a COPY
FROM "filename" command, does it? In that case, you maintain a
distinction between two different input streams. It seems that
dropping that distinction for the special case of "filename" == STDIN
is introducing unnecessary confusion into the semantics of commands.
In short, I'm not really convinced that it is unreasonable to expect a
command like COPY (or \copy) to be able to associate itself with an
input (or output) stream that is different from that implied by -f,
given that the nature of the various I/O streams is so different and
clearly defined.
Cheers,
Brook
[*] I'm not sure what you mean by the "general case," but I can't
think of any other commands, at least SQL commands, that are naturally
associated with more than one input stream, namely the source of the
command itself which may include embedded data. Unless I'm missing
something here, I suspect the "general case" is just fine and doesn't
interact with the problem I raised. What is problematical is the
special case of a command (perhaps there are others?) that inherently
involves more than one input stream: the source of the command itself
and the source of data upon which the command operates.
From bouncefilter Wed Jan 12 16:05:42 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA90146
for <hackers@postgreSQL.org>; Wed, 12 Jan 2000 16:05:40 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA14740;
Wed, 12 Jan 2000 16:02:03 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001122102.QAA14740@candle.pha.pa.us>
Subject: Re: [HACKERS] psql updates
In-Reply-To: <Pine.LNX.4.21.0001122022550.1646-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 12, 2000 08:44:25 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Wed, 12 Jan 2000 16:02:03 -0500 (EST)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
was introduced or removed. In addition, the frequent end user problem "I
did \dt and all my tables were gone" has been eliminated.
Huge fix for us. Great.
--
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 Jan 12 16:16:42 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA92130
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 16:16:21 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id NAA03675;
Wed, 12 Jan 2000 13:15:05 -0800 (PST)
Message-Id: <3.0.1.32.20000112131308.01051970@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 12 Jan 2000 13:13:08 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: Informix and OUTER join syntax
In-Reply-To: <200001122044.PAA13564@candle.pha.pa.us>
References: <From "(env:" "pgman)" at "Jan 12, 2000 03:38:10 pm">
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 03:43 PM 1/12/00 -0500, Bruce Momjian wrote:
SELECT *
FROM tab1, OUTER(tab2, OUTER tab3)
WHERE tab1.col1 = tab2.col1 AND
tab2.col1 = tab3.col1It does the tab2, tab3 as an _outer_ join first, then _outer_ joins to
tab1. Even more interesting.Can someone show me this in ANSI syntax?
Along the lines of
SELECT *
FROM tab1 RIGHT JOIN (tab2 RIGHT JOIN tab3 on col1) on col1
more or less. No where clause is needed, of course.
I left my copy of Date's book back in Boston so can't be
precise, guess I'll have to go visit my girlfriend ASAP!
Thomas will probably make it clear I'm all wet here, but by
trying to generate SQL-92 queries myself I'm hoping I'll learn
something.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Wed Jan 12 17:44:43 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA26520
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 17:44:27 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id RAA18423
for pgsql-hackers@postgreSQL.org; Wed, 12 Jan 2000 17:41:13 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001122241.RAA18423@candle.pha.pa.us>
Subject: Status request for 7.0
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Wed, 12 Jan 2000 17:41:13 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
We are about 3 weeks from the scheduled 7.0 beta.
I am interested in hearing a status on our open items:
foreign keys/activity queue - Jan
long tuples/TOAST - Jan
outer joins - Thomas
Date/Time types - Thomas
Postponed:
WAL - Vadim
Function args - Tom
If people need more time, let us know.
--
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 Jan 12 18:24:00 2000
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 SAA40501
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 18:22:52 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64274 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S190483AbQALXWX>;
Thu, 13 Jan 2000 00:22:23 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128XCf-0001HQ-00; Thu, 13 Jan 2000 00:29:25 +0100
Date: Thu, 13 Jan 2000 00:29:25 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgresql.org
Subject: proposal -- Re: [HACKERS] Re: [SQL] createdb -D xxxx not working
In-Reply-To: <387CAB1D.57B20461@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0001122124450.1646-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-12, Thomas Lockhart mentioned:
Huh? The "environment variable deal" is intended to provide security
and easier operation. The examples above which allow specifying
absolute paths (e.g. "/some/where/pg_class") are specifically
disallowed by default, for a reason. If there were bugs in that, let's
talk about it, but I'm *very* uncomfortable making wholesale changes
without a discussion. And what exactly were "several bugs in the
code"?? Better be specific; that's my code we're talking about :/
The starting point for my investigation was actually the issue of
arbitrary characters in database names, which lead me to fix up the
createdb and dropdb code to make it more error proof, which led me to all
kinds of areas of the code that looked ages old, with comments not
matching the code, dead code, etc. The location issue was just one of
those. (Especially those /* this is work arround only !!! */ sections from
more than 5 years ago concern me a little ...) It's my idea of a learning
experience.
initlocation is used to create the directory structure *with correct
permissions* for an alternate location. It takes an environment
If I create a database with a normal name, the code makes a directory
/usr/local/pgsql/data/base/testdb with the proper permissions. There's no
reason why it wouldn't be able to do the same somewhere else. It's
redundant.
1) there is not likely to be a random environment variable which
happens to point to a valid directory which *also* has a subdirectory
called "base".
Forgive me, but "not likely" means zero security to me. If you want to
make it secure, be for real. Perhaps I'm a little envvar-phobic in
general. I got my reasons, but that shouldn't stand in other's ways.
2) it reduces the chance that a user/dbadmin will not use initlocation
to create the database area, hence reducing the chance that a
user/dbadmin has not set the permissions correctly.
The prototype code I got lying around insists on creating the directory
itself, so the chances of using an insecure directory are zero. But there
are also other ways to ensure this rather than another utility.
Okay, now to the "formal" proposal:
* A database name can contain any character (up to NAMEDATALEN)
* By default, the database name is appended to DataDir/base/ to form the
file system location of the database.
* There are certain characters that will not be allowed in database paths
because they are potentially "shell'ishly dangerous". In my current layout
this includes everything from 1 to 31 ascii as well as single-quote
(') and dot (.). If you choose to name a database this way, you need to
override the path to something else.
* If you override the path to a name not containing a slash, the name will
in the same fashion be appended to DataDir/base/. Any future attempts to
use the same path will fail.
* If you override the path to a name including a slash but not at the
start, the part up to the first slash will be interpreted as an
environment variable. The database directory will be the immediate
directory specified and will be created by createdb() (which must have
permission to do so). If it already exists, it will attempt to fix the
permissions.
* If you specify an absolute path then it will use that very path and it
will create the directory as above.
* Either way, in order to use a path outside DataDir, it must be listed in
some configuration option (such as PG_ALTLOC). Environment variable based
paths can be included in the natural way, e.g., to allow a path
'PGDATA2/foo' write PG_ALTLOC=$PGDATA/foo, to allow anything under
PGDATA2, write PG_ALTLOC=$PGDATA/*.
In practice that would mean:
1. If you don't use this feature, nothing changes.
2. If you want to use this feature to "recode" funny characters, you
may. (e.g., CREATE DATABASE "bbb'''..." WITH LOCATON = 'bbb______';)
3. If you want to stick one particular database somewhere else, create the
directory (or at least the directory above it), include it in PG_ALTLOC
and go ahead.
4. If you want to provide users the option of storing databases at several
alternative locations, set up mnemonic environment variables, create the
directories corresponding to them, and put something like
PGDATA2/*:PGDATA3/*:... in PG_ALTLOC.
Are there other circumstances where this would be used?
What could be discussed it the exact interpretation of a path such as
LOCATION = '/mnt/somewhere/foo' with regards to whether 'base' should be
appended or not or the name of the database should be appended to it or
not or how one could otherwise do the name "recoding" in that
circumstance.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Jan 12 18:23:44 2000
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 SAA40520
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 18:23:01 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64432 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S213013AbQALXWb>;
Thu, 13 Jan 2000 00:22:31 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128XCl-0001Hj-00; Thu, 13 Jan 2000 00:29:31 +0100
Date: Thu, 13 Jan 2000 00:29:31 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Brook Milligan <brook@biology.nmsu.edu>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql -f inconsistency with "copy from stdin"
In-Reply-To: <9069.947659376@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001122057120.1646-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-12, Tom Lane mentioned:
It seems to me that we ought to provide both behaviors, but make sure
that the one that supports data-in-the-script is the one invoked by
COPY FROM STDIN (since that's what pg_dump uses). Perhaps psql's \copy
command can be set up to support the other alternative.
\copy from stdin is not used yet. That would work. There might be issues
I'm overlooking now, but anything else that came up in this thread will
most likely not work in the general case.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Jan 12 18:23:53 2000
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 SAA40576
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 18:23:13 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64487 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S198677AbQALXWf>;
Thu, 13 Jan 2000 00:22:35 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128XCq-0001Hz-00; Thu, 13 Jan 2000 00:29:36 +0100
Date: Thu, 13 Jan 2000 00:29:36 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: Regress tests reveal *serious* psql bug
In-Reply-To: <8945.947657700@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001122112130.1646-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-12, Tom Lane mentioned:
I think this raises the bar to the point where we must
have a transparent backward-compatible approach to psql variables.
I was not all that thrilled about blowing off colon as an operator,
and blowing off array subscripts *too* is just too far above my
threshold of pain.
To clear something out here: I'm with you all the way. I didn't make up
that syntax, and I too was forgetful about the array issue. If y'all think
that a variable must be defined to be substituted and that that will fix
things to a reasonable state, thus it shall be. My concern was more that
this would only work around this particular problem, while being short
sighted. Just want to make sure we have a consensus.
If I'm going to hack around in that code, one related question: what
should the deal be regarding variable interpolation into quoted
strings? Yes/No/Maybe?No bloody way, IMHO --- that increases the odds of unwanted
I'll take that as a No. ;)
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Jan 12 18:23:44 2000
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 SAA40580
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 18:23:14 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64610 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S221205AbQALXWk>;
Thu, 13 Jan 2000 00:22:40 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128XCv-0001IM-00; Thu, 13 Jan 2000 00:29:41 +0100
Date: Thu, 13 Jan 2000 00:29:41 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
In-Reply-To: <8978.947658153@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001122120540.1646-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-12, Tom Lane mentioned:
Accepting undeclared variables went out with Basic and Fortran;
why are we intent on re-inventing a concept that's so obviously
dangerous?
They came back with Perl, Python, Tcl, what-have-you. But okay, I'm beaten
into submission.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Jan 12 18:23:47 2000
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 SAA40601
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 18:23:24 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64675 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S239625AbQALXWn>;
Thu, 13 Jan 2000 00:22:43 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128XCz-0001Ic-00; Thu, 13 Jan 2000 00:29:45 +0100
Date: Thu, 13 Jan 2000 00:29:45 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <200001121541.KAA02308@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0001122050520.1646-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-12, Bruce Momjian mentioned:
I have updated the TODO list to mark all the items that are completed
for 7.0.
Wow, we're at 32% done!
Are there any additional ones? Are there some names I have forgotten to
attribute to items?
* Better interface for adding to pg_group
It's de facto done.
* Make postgres user have a password by default
There's an initdb switch.
* User who can create databases can modify pg_database table
is on the hit list. I believe the reason this had to be allowed is
createdb() using an actual insert statement to do its thing, which it
won't do any longer once I get all my code together. Some please correct
me if I'm wrong, otherwise I'll yank that code. (Yes, there is code that
specifically _allows_ this.)
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Jan 12 18:53:44 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA49775
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 18:53:28 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA21120;
Wed, 12 Jan 2000 18:50:09 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001122350.SAA21120@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.LNX.4.21.0001122050520.1646-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 13, 2000 00:29:45 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Wed, 12 Jan 2000 18:50:09 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-01-12, Bruce Momjian mentioned:
I have updated the TODO list to mark all the items that are completed
for 7.0.Wow, we're at 32% done!
Actually, there are tons of _done_ items on the list. I mentioned only
the big undone ones.
Are there any additional ones? Are there some names I have forgotten to
attribute to items?* Better interface for adding to pg_group
It's de facto done.
Great.
* Make postgres user have a password by default
There's an initdb switch.
OK, now we have to decide if we are going to require this be done as
part of initdb. I am inclined to say the user _has_ to be _prompted_ in
a secure matter for the password as part of initdb. Have a command-line
switch for the password is not secure, IMHO, though it is better than
nothing.
Let's get people's opinions on this, and we can mark it as done.
* User who can create databases can modify pg_database table
is on the hit list. I believe the reason this had to be allowed is
createdb() using an actual insert statement to do its thing, which it
won't do any longer once I get all my code together. Some please correct
me if I'm wrong, otherwise I'll yank that code. (Yes, there is code that
specifically _allows_ this.)
Great. Also dropping a database required this 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 Wed Jan 12 18:58:44 2000
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 SAA50556
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 18:58:09 -0500 (EST) (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 IAA01020; Thu, 13 Jan 2000 08:57:47 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: <a.joubert@albourne.com>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] BlowAwayRelationBuffers
Date: Thu, 13 Jan 2000 09:03:06 +0900
Message-ID: <000101bf5d59$91536f20$2801007e@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: <387C636F.B7B16CFD@albourne.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
-----Original Message-----
From: a.joubert@albourne.com [mailto:a.joubert@albourne.com]Thanks Hiroshi, I will patch my database and see whether that helps. Guess
i really ought to upgrade to 6.5.3, but I had some compile problems on
Alpha which I haven't looked at closely yet.
Unfortunately the patch could neither recover your current status
nor prevent the occurrence of BlowAwayRelationBuffers.
It may only prevent the occurrence of inconsistency after
the error.
BlowAwayRelationBuffers is called immediately before truncation of
the target relation file in VACUUM. Without applying my patch,
HEAP_MOVED_OFF tuples would revive after BlowAwayRelationBuffers
error.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Jan 12 19:20:44 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA57593
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 19:20:13 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA11022;
Wed, 12 Jan 2000 19:20:04 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: Brook Milligan <brook@biology.nmsu.edu>, peter_e@gmx.net,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql -f inconsistency with "copy from stdin"
In-reply-to: <Pine.BSF.4.21.0001121218080.46499-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001121218080.46499-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Wed, 12 Jan 2000 12:19:59 -0400"
Date: Wed, 12 Jan 2000 19:20:04 -0500
Message-ID: <11019.947722804@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
On Wed, 12 Jan 2000, Tom Lane wrote:
IMHO any proposal that requires changing pg_dump is a non-starter,
because it will fail when people try to load 6.5 or earlier dumps
into 7.0. But fortunately, pg_dump doesn't use \copy ...
I'm confused here...why would "any proposal that requires changing pg_dump
is a non-starter"? How does changing pg_dump in v7.0 affect pg_dump in
v6.5?
Because people will be using 6.5 pg_dump to make dump scripts that they
will then try to load into 7.0 with 7.0's psql. If we change the way
that COPY FROM STDIN is interpreted, we risk trouble with those scripts.
I like Peter's suggestion of defining "\copy from stdin" to mean
"read from psql's stdin". That would leave the SQL command COPY FROM
STDIN for the other case where the data is in-line in the script.
regards, tom lane
From bouncefilter Wed Jan 12 19:52:54 2000
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 TAA65564
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 19:52:46 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA21906;
Wed, 12 Jan 2000 19:41:59 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001130041.TAA21906@candle.pha.pa.us>
Subject: Re: [HACKERS] BlowAwayRelationBuffers]
In-Reply-To: <000101bf5d59$91536f20$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 13, 2000 09:03:06 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Wed, 12 Jan 2000 19:41:59 -0500 (EST)
CC: a.joubert@albourne.com, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
-----Original Message-----
From: a.joubert@albourne.com [mailto:a.joubert@albourne.com]Thanks Hiroshi, I will patch my database and see whether that helps. Guess
i really ought to upgrade to 6.5.3, but I had some compile problems on
Alpha which I haven't looked at closely yet.Unfortunately the patch could neither recover your current status
nor prevent the occurrence of BlowAwayRelationBuffers.
It may only prevent the occurrence of inconsistency after
the error.BlowAwayRelationBuffers is called immediately before truncation of
the target relation file in VACUUM. Without applying my patch,
HEAP_MOVED_OFF tuples would revive after BlowAwayRelationBuffers
error.
Wow, our team is really getting good at understanding this low-level code.
--
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 Jan 12 20:03:53 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA70551
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 20:02:57 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA69829;
Wed, 12 Jan 2000 21:02:39 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 12 Jan 2000 21:02:38 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <200001122350.SAA21120@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001122057340.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 12 Jan 2000, Bruce Momjian wrote:
OK, now we have to decide if we are going to require this be done as
part of initdb. I am inclined to say the user _has_ to be _prompted_ in
a secure matter for the password as part of initdb. Have a command-line
switch for the password is not secure, IMHO, though it is better than
nothing.
If we do a 'CREATE USER <user> WITH PASSWORD <pass>', its no more secure
then using a command line switch for password ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Jan 12 20:16:48 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA73243
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 20:16:24 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA23888;
Wed, 12 Jan 2000 20:12:54 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001130112.UAA23888@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.BSF.4.21.0001122057340.46499-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 12, 2000 09:02:38 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Wed, 12 Jan 2000 20:12:54 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Wed, 12 Jan 2000, Bruce Momjian wrote:
OK, now we have to decide if we are going to require this be done as
part of initdb. I am inclined to say the user _has_ to be _prompted_ in
a secure matter for the password as part of initdb. Have a command-line
switch for the password is not secure, IMHO, though it is better than
nothing.If we do a 'CREATE USER <user> WITH PASSWORD <pass>', its no more secure
then using a command line switch for password ...
Why is that? ps shows command args, righ?
--
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 Jan 12 20:14:08 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA72583;
Wed, 12 Jan 2000 20:13:03 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA11244;
Wed, 12 Jan 2000 20:13:02 -0500 (EST)
To: Michael Meskes <meskes@postgreSQL.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FETCH without FROM/IN
In-reply-to: <20000112175326.A2376@fam-meskes.de>
References: <20000112161216.A334@fam-meskes.de> <9917.947693351@sss.pgh.pa.us>
<20000112175326.A2376@fam-meskes.de>
Comments: In-reply-to Michael Meskes <meskes@postgreSQL.org>
message dated "Wed, 12 Jan 2000 17:53:26 +0100"
Date: Wed, 12 Jan 2000 20:13:02 -0500
Message-ID: <11241.947725982@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Meskes <meskes@postgreSQL.org> writes:
<fetch statement> ::=
FETCH [ [ <fetch orientation> ] FROM ]
<cursor name> INTO <fetch target list>
To me this seems to say that FROM is just optional. Okay, if I make it
optional in our parser?
Careful --- notice that FROM is only optional if you *also* omit all the
preceding optional clauses. Otherwise there will be a reduce conflict
that you could only resolve by removing all of FETCH's secondary
keywords from the ColId list. I don't think that would be an acceptable
tradeoff.
I think, though, that you could make our syntax work like
FETCH [ opt_direction fetch_how_many FROM/IN ] portal_name
without conflicts. That'd be good since it'd be more like SQL92.
regards, tom lane
From bouncefilter Wed Jan 12 20:11:55 2000
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 UAA72212
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 20:11:04 -0500 (EST) (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 KAA01064; Thu, 13 Jan 2000 10:10:44 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "PostgreSQL-development" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] TODO list updated
Date: Thu, 13 Jan 2000 10:16:15 +0900
Message-ID: <000201bf5d63$c9c8f8c0$2801007e@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: <200001121541.KAA02308@candle.pha.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce Momjian
I have updated the TODO list to mark all the items that are completed
for 7.0.Are there any additional ones? Are there some names I have forgotten to
attribute to items?Let me know.
Hmmm,who solved ????
* -spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr
And I have felt that the followings are almost same.
* Allow LIMIT ability on single-table queries that have no ORDER BY to use
a matching index [limit]
* Improve LIMIT processing by using index to limit rows processed [limit]
* Have optimizer take LIMIT into account when considering index scans
[limit]
And Isn't it preferable to omit 'in ORDER BY' from
* Use indexes in ORDER BY for restrictive data sets, min(), max()
?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Jan 12 20:27:52 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA75130
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 20:27:18 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA11297;
Wed, 12 Jan 2000 20:26:54 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-reply-to: <Pine.BSF.4.21.0001122057340.46499-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001122057340.46499-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Wed, 12 Jan 2000 21:02:38 -0400"
Date: Wed, 12 Jan 2000 20:26:54 -0500
Message-ID: <11294.947726814@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
On Wed, 12 Jan 2000, Bruce Momjian wrote:
OK, now we have to decide if we are going to require this be done as
part of initdb. I am inclined to say the user _has_ to be _prompted_ in
a secure matter for the password as part of initdb. Have a command-line
switch for the password is not secure, IMHO, though it is better than
nothing.
If we do a 'CREATE USER <user> WITH PASSWORD <pass>', its no more secure
then using a command line switch for password ...
Yes it is --- if you have a shell script that is invoked by
initdb --password pgsqlPassword ...
then anyone else on the same machine who happens to be doing a "ps"
meanwhile will see your password.
Note that if initdb is a shell script, then it still has to be very
careful what it does with the password; put it in any command line
for a program invoked by the script, and the leak is back with you.
A C-program version of initdb would be a lot safer. But in theory you
can pass the password to the backend without exposing it in any command
line (put it in a data file instead, say).
regards, tom lane
From bouncefilter Wed Jan 12 20:56:13 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA81786
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 20:55:47 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA25362;
Wed, 12 Jan 2000 20:52:22 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001130152.UAA25362@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <000201bf5d63$c9c8f8c0$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 13, 2000 10:16:15 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Wed, 12 Jan 2000 20:52:22 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hmmm,who solved ????
* -spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr
I thought you or Tatsuo fixed that. I will remove the mark.
And I have felt that the followings are almost same.
* Allow LIMIT ability on single-table queries that have no ORDER BY to use
a matching index [limit]
* Improve LIMIT processing by using index to limit rows processed [limit]
* Have optimizer take LIMIT into account when considering index scans
[limit]And Isn't it preferable to omit 'in ORDER BY' from
* Use indexes in ORDER BY for restrictive data sets, min(), max()
?
I have now made it two items:
* Use indexes in ORDER BY for restrictive data sets
* Use indexes in ORDER BY for min(), max()
We currently do not use indexes to handle ORDER BY because it is slower,
but for queries returning only a few rows, we could use the index and
skip the ORDER BY. Not sure if this is done yet, or if it is important.
--
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 Jan 12 20:54:49 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA81488
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 20:53:54 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA70113;
Wed, 12 Jan 2000 21:54:02 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 12 Jan 2000 21:54:02 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <200001130112.UAA23888@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001122153320.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 12 Jan 2000, Bruce Momjian wrote:
On Wed, 12 Jan 2000, Bruce Momjian wrote:
OK, now we have to decide if we are going to require this be done as
part of initdb. I am inclined to say the user _has_ to be _prompted_ in
a secure matter for the password as part of initdb. Have a command-line
switch for the password is not secure, IMHO, though it is better than
nothing.If we do a 'CREATE USER <user> WITH PASSWORD <pass>', its no more secure
then using a command line switch for password ...Why is that? ps shows command args, righ?
Point. You won me over :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Jan 12 20:58:53 2000
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 UAA82133
for <pgsql-hackers@postgresql.org>;
Wed, 12 Jan 2000 20:57:48 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA23120
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 10:57:46 +0900 (JST)
Received: from localhost (IDENT:t-ishii@srapc968-yotsuya [133.137.36.133])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA06338
for <pgsql-hackers@postgresql.org>; Thu, 13 Jan 2000 10:57:46 +0900
To: pgsql-hackers@postgresql.org
Subject: libpq+MB/putenv(), getenv() clean up
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000113105845O.t-ishii@sra.co.jp>
Date: Thu, 13 Jan 2000 10:58:45 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 42
Hi,
I have a plan to clean up the usage of putenv(), getenv() in libpq+MB
configuration. This needs some interface changes with libpq in the
frontend side. I'm not sure this is visible to end users or not, and I
would like to hear from hackes.
First of all, I would like to explain the current implementation.
(1) While establishing a connection, if the environment variable
PGCLIENTENCODING is not set, libpq asks the backend what the encoding
for the database is. This is done by sending a query "select
getdatabaseencoding()". In this case, both the backend and the
frontend uses same encoding and its name is set to the
PGCLIENTENCODING environment variable for the later use.
(fe-connect.c: PQsetenvPoll())
(2) When libpq prints the result of a query, it needs to determine the
length of a multi-byte letter. For this purpose, getenv() is called to
know the encoding name. (fe-print.c)
Above implementation has a design flaw since it is not multithread-safe.
To fix the problem, I would like to make changes as follows:
(1) Add a new member "int client_encoding" to struct pg_conn.
(2) Add an argument which is a pointer to PGconn to PQsetenvPoll() so
that the client encoding can be set in (1) above.
(3) Add a new function PQclientencoding() to extract client_encoding
from PGconn.
(4) Change PQmblen() so that it extracts encoding info using
PQclientencoding() rather than calling getenv(). This also requires
add an argument which is a pointer to PGconn.
(5) Change fe-print.c:do_filed() to add an argument which is a pointer to
PGconn.
Comments and suggestions are welcome.
--
Tatsuo Ishii
From bouncefilter Wed Jan 12 21:14:47 2000
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 VAA92247
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 21:14:26 -0500 (EST) (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 LAA01096; Thu, 13 Jan 2000 11:13:30 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "PostgreSQL-development" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] TODO list updated
Date: Thu, 13 Jan 2000 11:19:00 +0900
Message-ID: <000301bf5d6c$8d9a1600$2801007e@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: <200001130152.UAA25362@candle.pha.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]Hmmm,who solved ????
* -spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgrI thought you or Tatsuo fixed that. I will remove the mark.
I have had a fix for it for 3 months but not committed because I don't
know how WAL would change it.
OK I would commit it after some checking.
And I have felt that the followings are almost same.
* Allow LIMIT ability on single-table queries that have noORDER BY to use
a matching index [limit]
* Improve LIMIT processing by using index to limit rowsprocessed [limit]
* Have optimizer take LIMIT into account when considering index scans
[limit]And Isn't it preferable to omit 'in ORDER BY' from
* Use indexes in ORDER BY for restrictive data sets, min(), max()
?I have now made it two items:
* Use indexes in ORDER BY for restrictive data sets
* Use indexes in ORDER BY for min(), max()We currently do not use indexes to handle ORDER BY because it is slower,
but for queries returning only a few rows, we could use the index and
skip the ORDER BY. Not sure if this is done yet, or if it is important.
Tom has changed to take IndexScan into account even when no qual exists.
* -Allow optimizer to prefer plans that match ORDER BY(Tom)
Currently optimizer is too eager to use index scan. He is planning to take
limit into account AFAIK, He has mentioned it many times and I have been
looking forward to his change.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Jan 12 21:38:51 2000
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 VAA98152
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 21:38:22 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA26834;
Wed, 12 Jan 2000 21:34:15 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001130234.VAA26834@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <000301bf5d6c$8d9a1600$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 13, 2000 11:19:00 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Wed, 12 Jan 2000 21:34:15 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]Hmmm,who solved ????
* -spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgrI thought you or Tatsuo fixed that. I will remove the mark.
I have had a fix for it for 3 months but not committed because I don't
know how WAL would change it.
OK I would commit it after some checking.
Ah, so my memory isn't that bad. WAL is not going into 7.0, so it
should be fine.
We currently do not use indexes to handle ORDER BY because it is slower,
but for queries returning only a few rows, we could use the index and
skip the ORDER BY. Not sure if this is done yet, or if it is important.Tom has changed to take IndexScan into account even when no qual exists.
* -Allow optimizer to prefer plans that match ORDER BY(Tom)
Currently optimizer is too eager to use index scan. He is planning to take
limit into account AFAIK, He has mentioned it many times and I have been
looking forward to his change.
OK, TODO updated.
--
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 Jan 12 21:42:51 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA98572
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 21:41:49 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA11447;
Wed, 12 Jan 2000 21:41:28 -0500 (EST)
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
cc: "PostgreSQL-development" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-reply-to: <000201bf5d63$c9c8f8c0$2801007e@tpf.co.jp>
References: <000201bf5d63$c9c8f8c0$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Thu, 13 Jan 2000 10:16:15 +0900"
Date: Wed, 12 Jan 2000 21:41:28 -0500
Message-ID: <11444.947731288@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
TODO item comments:
* -SELECT foo UNION SELECT foo is incorrectly simplified to SELECT foo
The above is NOT done.
* prevent primary key that exceeds max index columns [primary]
The above is done as of yesterday.
* Fix memory leak for expressions[memory](Tom?)
This isn't going to happen for 7.0, looks like :-(
* -Allow compression of large fields or a compressed field type
This has to be marked not-done again, unless Jan manages to squeeze
it back in via the toaster before Feb.
* Pull requested data directly from indexes, bypassing heap data
I doubt this is ever going to happen --- to make it possible, we'd
have to store tuple-commit status in index entries as well as in the
tuples themselves. That would be a substantial space and speed penalty;
is the potential gain really worth it?
* -Convert function(constant) into a constant for index use(Tom)
Bernard Frankpitt should get the bulk of the credit for that one, not me.
* Allow LIMIT ability on single-table queries that have no ORDER BY to use
a matching index [limit]
* Improve LIMIT processing by using index to limit rows processed [limit]
* Have optimizer take LIMIT into account when considering index scans [limit]
I agree with Hiroshi that these entries are redundant.
* -Make index creation use psort code, because it is now faster(Vadim)
I did that, not Vadim.
* -elog() flushes cache, try invalidating just entries from current xact,
perhaps using invalidation cache
I don't think this is done?
* -Process const = const parts of OR clause in separate pass(Tom)
Again, mostly Frankpitt.
Some other things I did that aren't mentioned in TODO, but perhaps
deserve to be shown as 7.0 fixes:
* Interlock to prevent DROP DATABASE on a database with running backends
* Buffer reference counting bugfixes
* Fix libpq bug that causes it to drop backend error message sent
just before connection closure (ie, any FATAL error message :-().
regards, tom lane
From bouncefilter Wed Jan 12 21:55:46 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA00126
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 21:55:24 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA11529;
Wed, 12 Jan 2000 21:55:13 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-reply-to: <200001130152.UAA25362@candle.pha.pa.us>
References: <200001130152.UAA25362@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Wed, 12 Jan 2000 20:52:22 -0500"
Date: Wed, 12 Jan 2000 21:55:13 -0500
Message-ID: <11526.947732113@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
We currently do not use indexes to handle ORDER BY because it is slower,
Er, actually, we *do* use indexes for ORDER BY currently:
regression=# explain select * from tenk1 order by unique1;
NOTICE: QUERY PLAN:
Index Scan using tenk1_unique1 on tenk1 (cost=760.00 rows=10000 width=148)
If you start psql with PGOPTIONS="-fi" you can see that the optimizer
believes an explicit sort would be much slower:
regression=# explain select * from tenk1 order by unique1;
NOTICE: QUERY PLAN:
Sort (cost=3233.91 rows=10000 width=148)
-> Seq Scan on tenk1 (cost=563.00 rows=10000 width=148)
but (at least on my machine) the explicit sort is marginally faster.
Evidently, the cost estimate for an explicit sort is *way* too high.
I have been poking at this and am currently thinking that the CPU-vs-
disk scaling constants (_cpu_page_weight_ and cpu_index_page_weight_)
may be drastically off for modern hardware. This is one of the
optimizer issues that I'm hoping to resolve for 7.0.
regards, tom lane
From bouncefilter Wed Jan 12 22:05:55 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA04535
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 22:05:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA28083;
Wed, 12 Jan 2000 22:01:20 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001130301.WAA28083@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <11444.947731288@sss.pgh.pa.us> from Tom Lane at "Jan 12,
2000 09:41:28 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 12 Jan 2000 22:01:20 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
TODO item comments:
* -SELECT foo UNION SELECT foo is incorrectly simplified to SELECT foo
The above is NOT done.
Fixed.
* prevent primary key that exceeds max index columns [primary]
The above is done as of yesterday.
OK.
* Fix memory leak for expressions[memory](Tom?)
This isn't going to happen for 7.0, looks like :-(
I figured.
* -Allow compression of large fields or a compressed field type
This has to be marked not-done again, unless Jan manages to squeeze
it back in via the toaster before Feb.
I was optimistic. I will take it off mark.
* Pull requested data directly from indexes, bypassing heap data
I doubt this is ever going to happen --- to make it possible, we'd
have to store tuple-commit status in index entries as well as in the
tuples themselves. That would be a substantial space and speed penalty;
is the potential gain really worth it?
Ingres does this. Not sure if it worth it. Comments?
* -Convert function(constant) into a constant for index use(Tom)
Bernard Frankpitt should get the bulk of the credit for that one, not me.
Updated.
* Allow LIMIT ability on single-table queries that have no ORDER BY to use
a matching index [limit]
* Improve LIMIT processing by using index to limit rows processed [limit]
* Have optimizer take LIMIT into account when considering index scans [limit]I agree with Hiroshi that these entries are redundant.
Only one remains now.
* -Make index creation use psort code, because it is now faster(Vadim)
I did that, not Vadim.
Vadim had claimed it. You did it. Updated.
* -elog() flushes cache, try invalidating just entries from current xact,
perhaps using invalidation cacheI don't think this is done?
I thought we fixed this. Hiroshi? I could swear this came in the past
few weeks.
* -Process const = const parts of OR clause in separate pass(Tom)
Again, mostly Frankpitt.
Updated.
Some other things I did that aren't mentioned in TODO, but perhaps
deserve to be shown as 7.0 fixes:* Interlock to prevent DROP DATABASE on a database with running backends
* Buffer reference counting bugfixes
* Fix libpq bug that causes it to drop backend error message sent
just before connection closure (ie, any FATAL error message :-().
All added to reliability section.
--
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 Jan 12 22:06:49 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA04595
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 22:06:06 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA28098;
Wed, 12 Jan 2000 22:02:40 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001130302.WAA28098@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <11526.947732113@sss.pgh.pa.us> from Tom Lane at "Jan 12,
2000 09:55:13 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 12 Jan 2000 22:02:40 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
We currently do not use indexes to handle ORDER BY because it is slower,
Er, actually, we *do* use indexes for ORDER BY currently:
regression=# explain select * from tenk1 order by unique1;
NOTICE: QUERY PLAN:
Index Scan using tenk1_unique1 on tenk1 (cost=760.00 rows=10000 width=148)If you start psql with PGOPTIONS="-fi" you can see that the optimizer
believes an explicit sort would be much slower:regression=# explain select * from tenk1 order by unique1;
NOTICE: QUERY PLAN:
Sort (cost=3233.91 rows=10000 width=148)
-> Seq Scan on tenk1 (cost=563.00 rows=10000 width=148)but (at least on my machine) the explicit sort is marginally faster.
Evidently, the cost estimate for an explicit sort is *way* too high.
But it shouldn't be using the ORDER BY, except when the number of rows
processed is less than the full table, right?
I have been poking at this and am currently thinking that the CPU-vs-
disk scaling constants (_cpu_page_weight_ and cpu_index_page_weight_)
may be drastically off for modern hardware. This is one of the
optimizer issues that I'm hoping to resolve for 7.0.
Makes sense. CPU's have gotten much faster than disk.
--
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 Jan 12 22:06:48 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA04576
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 22:05:52 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA11549;
Wed, 12 Jan 2000 22:05:31 -0500 (EST)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] libpq+MB/putenv(), getenv() clean up
In-reply-to: <20000113105845O.t-ishii@sra.co.jp>
References: <20000113105845O.t-ishii@sra.co.jp>
Comments: In-reply-to Tatsuo Ishii <t-ishii@sra.co.jp>
message dated "Thu, 13 Jan 2000 10:58:45 +0900"
Date: Wed, 12 Jan 2000 22:05:31 -0500
Message-ID: <11546.947732731@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
I have a plan to clean up the usage of putenv(), getenv() in libpq+MB
configuration. This needs some interface changes with libpq in the
frontend side. I'm not sure this is visible to end users or not, and I
would like to hear from hackes.
I think it is a very good idea to remove getenv() from PQmblen().
getenv() is rather slow, at least on the machines I use, and having
to do it for each character processed is a huge performance hit.
PQmblen is exported by libpq (psql is an example of an application
that uses it). So very possibly, changing it would break a few client
applications. A possible answer is to leave PQmblen alone, and invent
a new routine with a different name that looks at PGconn. We could
deprecate PQmblen and delete it after a few releases. I'm not sure
if this is worth the trouble or not --- maybe it's OK to make a non-
compatible change to PQmblen.
(1) While establishing a connection, if the environment variable
PGCLIENTENCODING is not set, libpq asks the backend what the encoding
for the database is.
Above implementation has a design flaw since it is not multithread-safe.
You would still do one getenv() during connection setup, right, to see
if PGCLIENTENCODING is set? If you don't, that would be a significant
change in behavior that might make a lot of people unhappy.
regards, tom lane
From bouncefilter Wed Jan 12 22:10:52 2000
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 WAA05124
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 22:10:20 -0500 (EST) (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 MAA01131; Thu, 13 Jan 2000 12:09:23 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "PostgreSQL-development" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] TODO list updated
Date: Thu, 13 Jan 2000 12:14:54 +0900
Message-ID: <000401bf5d74$5d071d00$2801007e@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
In-Reply-To: <11444.947731288@sss.pgh.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom LaneTODO item comments:
* Pull requested data directly from indexes, bypassing heap data
I doubt this is ever going to happen --- to make it possible, we'd
have to store tuple-commit status in index entries as well as in the
tuples themselves. That would be a substantial space and speed penalty;
is the potential gain really worth it?
I agree with Tom. We could omit rows using indexes but cound't
pull data from indexes without time qualification of heap tuples now.
* -elog() flushes cache, try invalidating just entries from current xact,
perhaps using invalidation cacheI don't think this is done?
If I recognize correctly this item,this was fixed by my recent changes
for cache invalidation though I had changed it without knowing this item.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Jan 12 22:19:51 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA06605
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 22:19:44 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA11600;
Wed, 12 Jan 2000 22:19:35 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-reply-to: <200001130302.WAA28098@candle.pha.pa.us>
References: <200001130302.WAA28098@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Wed, 12 Jan 2000 22:02:40 -0500"
Date: Wed, 12 Jan 2000 22:19:34 -0500
Message-ID: <11597.947733574@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
but (at least on my machine) the explicit sort is marginally faster.
Evidently, the cost estimate for an explicit sort is *way* too high.
But it shouldn't be using the ORDER BY,
Right, if the cost estimates were in line with reality it would be
choosing the explicit sort.
... except when the number of rows
processed is less than the full table, right?
Now if there were *also* a LIMIT clause then the tradeoffs change again
--- the index scan wins for a small LIMIT because of its much lower
startup cost. But the optimizer knows nothing of this and will still
estimate on the basis that all of the tuples are going to be processed.
As Hiroshi just remarked, we really need to teach the optimizer about
LIMIT. Another thing I'm hoping to get done before 7.0.regards, tom lane
From bouncefilter Wed Jan 12 22:39:54 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA12448
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 22:39:04 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA29279;
Wed, 12 Jan 2000 22:34:33 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001130334.WAA29279@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <000401bf5d74$5d071d00$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 13, 2000 12:14:54 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Wed, 12 Jan 2000 22:34:33 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom LaneTODO item comments:
* Pull requested data directly from indexes, bypassing heap data
I doubt this is ever going to happen --- to make it possible, we'd
have to store tuple-commit status in index entries as well as in the
tuples themselves. That would be a substantial space and speed penalty;
is the potential gain really worth it?I agree with Tom. We could omit rows using indexes but cound't
pull data from indexes without time qualification of heap tuples now.
Removed.
* -elog() flushes cache, try invalidating just entries from current xact,
perhaps using invalidation cacheI don't think this is done?
If I recognize correctly this item,this was fixed by my recent changes
for cache invalidation though I had changed it without knowing this item.
Great. I thought so. I remember some CVS messages saying this.
--
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 Jan 12 22:40:52 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA12533
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 22:39:50 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA29364;
Wed, 12 Jan 2000 22:36:04 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001130336.WAA29364@candle.pha.pa.us>
Subject: Re: [HACKERS] libpq+MB/putenv(), getenv() clean up
In-Reply-To: <11546.947732731@sss.pgh.pa.us> from Tom Lane at "Jan 12,
2000 10:05:31 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 12 Jan 2000 22:36:04 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
I have a plan to clean up the usage of putenv(), getenv() in libpq+MB
configuration. This needs some interface changes with libpq in the
frontend side. I'm not sure this is visible to end users or not, and I
would like to hear from hackes.I think it is a very good idea to remove getenv() from PQmblen().
getenv() is rather slow, at least on the machines I use, and having
to do it for each character processed is a huge performance hit.
Yikes, we are calling it for every character. I think it munges through
the entire process environment space looking for a value.
--
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 Jan 12 22:41:50 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA12685
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 22:40:56 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA11684;
Wed, 12 Jan 2000 22:40:49 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Adriaan Joubert" <a.joubert@albourne.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] BlowAwayRelationBuffers
In-reply-to: <000201bf5cdb$c31fd620$2801007e@tpf.co.jp>
References: <000201bf5cdb$c31fd620$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Wed, 12 Jan 2000 18:02:33 +0900"
Date: Wed, 12 Jan 2000 22:40:48 -0500
Message-ID: <11681.947734848@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I commited the following change to REL tree after 6.5.2.
It might be late for Adriaan.
! if (SharedBufferChanged)
TransactionIdAbort(xid);
! if (SharedBufferChanged && !TransactionIdDidCommit(xid))
TransactionIdAbort(xid);
OK, I guess the point is that if VACUUM aborts at some time after
it's done its internal commit, this code would have un-done the
commit, thereby allowing HEAP_MOVED_OFF tuples to spring back to
life?
I was trying to figure out if this change might fix the duplicate-
tuples-after-failed-VACUUM problems that we've just been hearing
about. Certainly there is plenty of stuff going on in VACUUM after
its internal commit, so plenty of places that could elog(ERROR).
But it looks like the very first thing that happens after commit
is a scan to commit HEAP_MOVED_IN tuples and kill HEAP_MOVED_OFF
tuples, so this couldn't help much unless the failure happened
during that scan. Which doesn't seem really likely...
regards, tom lane
From bouncefilter Wed Jan 12 22:52:48 2000
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 WAA14274
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 22:52:15 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id MAA29806;
Thu, 13 Jan 2000 12:52:13 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id MAA07757;
Thu, 13 Jan 2000 12:52:13 +0900
To: tgl@sss.pgh.pa.us
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] libpq+MB/putenv(), getenv() clean up
In-Reply-To: Your message of "Wed, 12 Jan 2000 22:05:31 -0500"
<11546.947732731@sss.pgh.pa.us>
References: <11546.947732731@sss.pgh.pa.us>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000113125212C.t-ishii@sra.co.jp>
Date: Thu, 13 Jan 2000 12:52:12 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 28
I think it is a very good idea to remove getenv() from PQmblen().
getenv() is rather slow, at least on the machines I use, and having
to do it for each character processed is a huge performance hit.
I didn't notice that. Thanks for the point.
PQmblen is exported by libpq (psql is an example of an application
that uses it). So very possibly, changing it would break a few client
applications. A possible answer is to leave PQmblen alone, and invent
a new routine with a different name that looks at PGconn. We could
deprecate PQmblen and delete it after a few releases. I'm not sure
if this is worth the trouble or not --- maybe it's OK to make a non-
compatible change to PQmblen.
With the changes I propose, PQmblen() would not work anymore
anyway. I'll post to interfaces list about the incompatible changes.
You would still do one getenv() during connection setup, right, to see
if PGCLIENTENCODING is set?
Yes.
If you don't, that would be a significant
change in behavior that might make a lot of people unhappy.
So the behavior won't be changed.
--
Tatsuo Ishii
From bouncefilter Wed Jan 12 23:03:40 2000
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 XAA28285
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 23:00:28 -0500 (EST) (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 NAA01162; Thu, 13 Jan 2000 13:00:09 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Adriaan Joubert" <a.joubert@albourne.com>, <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] BlowAwayRelationBuffers
Date: Thu, 13 Jan 2000 13:05:41 +0900
Message-ID: <000501bf5d7b$74ba7300$2801007e@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
In-Reply-To: <11681.947734848@sss.pgh.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I commited the following change to REL tree after 6.5.2.
It might be late for Adriaan.! if (SharedBufferChanged)
TransactionIdAbort(xid);! if (SharedBufferChanged && !TransactionIdDidCommit(xid))
TransactionIdAbort(xid);OK, I guess the point is that if VACUUM aborts at some time after
it's done its internal commit, this code would have un-done the
commit, thereby allowing HEAP_MOVED_OFF tuples to spring back to
life?
Yes.
I was trying to figure out if this change might fix the duplicate-
tuples-after-failed-VACUUM problems that we've just been hearing
about. Certainly there is plenty of stuff going on in VACUUM after
its internal commit, so plenty of places that could elog(ERROR).
But it looks like the very first thing that happens after commit
is a scan to commit HEAP_MOVED_IN tuples and kill HEAP_MOVED_OFF
Certainly when BlowAwayRelationBuffers() is called,commit to HEAP_
MOVED_IN(OFF) was already completed.
However it seems that the pages which are about to be truncated
are not touched.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Jan 12 23:15:48 2000
Received: from mail.psn.ne.jp (mail.psn.ne.jp [210.167.249.5])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA33204
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 23:15:16 -0500 (EST)
(envelope-from sakaida@psn.co.jp)
Received: from ppp119 (ppp119.psn.ne.jp [210.167.249.119])
by mail.psn.ne.jp (8.9.1/3.7W) with SMTP id NAA19223;
Thu, 13 Jan 2000 13:15:11 +0900 (JST)
Date: Thu, 13 Jan 2000 13:18:56 +0900
From: SAKAIDA <sakaida@psn.co.jp>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] libpq+MB/putenv(), getenv() clean up
In-Reply-To: <20000113105845O.t-ishii@sra.co.jp>
References: <20000113105845O.t-ishii@sra.co.jp>
Message-Id: <387D523014A.9FD9SAKAIDA@smtp.psn.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.25.07
Hi,
Tatsuo Ishii <t-ishii@sra.co.jp> wrote:
I have a plan to clean up the usage of putenv(), getenv() in libpq+MB
configuration. This needs some interface changes with libpq in the
frontend side. I'm not sure this is visible to end users or not, and I
would like to hear from hackes.
This plan is welcome !
Above implementation has a design flaw since it is not multithread-safe.
To fix the problem, I would like to make changes as follows:(1) Add a new member "int client_encoding" to struct pg_conn.
(2) Add an argument which is a pointer to PGconn to PQsetenvPoll() so
that the client encoding can be set in (1) above.(3) Add a new function PQclientencoding() to extract client_encoding
from PGconn.(4) Change PQmblen() so that it extracts encoding info using
PQclientencoding() rather than calling getenv(). This also requires
add an argument which is a pointer to PGconn.(5) Change fe-print.c:do_filed() to add an argument which is a pointer to
PGconn.Comments and suggestions are welcome.
Do those changes mean that libpq(or psql) always has the MULTIBYTE
function?
Now, libpq's MULTIBYTE function is a compile option(--with-mb).
But, I always want the MULTIBYTE function, even if PostgreSQL have
*not* been made with "--with-mb" option. Because, I want to access
two kind of PostgreSQL servers(named A and B) by using the B's psql.
(Here, A server is "--with-mb" and B server is not "--with-mb".)
Regards,
SAKAIDA Masaaki -- Osaka, Japan
From bouncefilter Wed Jan 12 23:43:50 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA52221
for <pgsql-hackers@hub.org>; Wed, 12 Jan 2000 23:42:58 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id EAA06261;
Thu, 13 Jan 2000 04:51:31 GMT
Sender: lockhart@hub.org
Message-ID: <387D59D3.FB3DCE60@alumni.caltech.edu>
Date: Thu, 13 Jan 2000 04:51: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: Michael Robinson <robinson@netrinsics.com>
CC: pgsql-hackers@hub.org
Subject: Re: [HACKERS] Copy from/to asymmetry
References: <200001121821.CAA76248@netrinsics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I set my time zone to GMT+8 today (because the "official" timezone prescribed
by the FreeBSD timezone database for my location is "CST", which was causing
all sorts of other problems elsewhere).
...
I was able to recover in a few minutes by manually editing the script file
to replace all "GMT+8" with "+0800".
...
I assume that my backups are similarly corrupted.
Sure, if you were running with a similarly unusual timezone format.
I looked through dt.c, and ParseDateTime appears to assume that timezones
are either strictly alphabetic or of the form "+0000".
Right, those are the forms we have seen or heard about (the minutes
field in the second form is optional). Yours is a new one for me.
EncodeDateTime,
on the other hand, blindly spits out whatever the operating system gives it
from localtime().
Yup. afaik this is the only way to get daylight savings time info
since there is no api to do so otherwise. Since this is the very first
report of this style of timezone, I don't feel too guilty, and it will
be easy to fix (I hope anyway).
1. x == datetime_in(datetime_out(x)) should always be true for all valid x.
Impossible to do apriori, given that we rely on the system to provide
timezone info for output. However, we try to fix all unusual cases,
and afaik there are no reasonable formats we have rejected for
support. I'm leaving town for a couple of days, but will look at it
when I return.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Jan 12 23:52:54 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA53377
for <pgsql-hackers@postgreSQL.org>;
Wed, 12 Jan 2000 23:52:25 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id FAA06268;
Thu, 13 Jan 2000 05:00:40 GMT
Sender: lockhart@hub.org
Message-ID: <387D5BF8.F1B7EE5A@alumni.caltech.edu>
Date: Thu, 13 Jan 2000 05:00:40 +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: Don Baccus <dhogaza@pacifier.com>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Informix and OUTER join syntax
References: <From "(env:" "pgman)" at "Jan 12, 2000 03:38:10 pm">
<3.0.1.32.20000112131308.01051970@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
SELECT *
FROM tab1, OUTER(tab2, OUTER tab3)
WHERE tab1.col1 = tab2.col1 AND
tab2.col1 = tab3.col1
It does the tab2, tab3 as an _outer_ join first, then _outer_ joins to
tab1. Can someone show me this in ANSI syntax?SELECT *
FROM tab1 RIGHT JOIN (tab2 RIGHT JOIN tab3 on col1) on col1
Pretty sure this is correct (assuming that the Informix syntax is
showing a right-side outer join). istm that SQL92 is clearer, in the
sense that the WHERE clause in the Informix syntax specifies that
columns shall be equal, when in fact there is an implicit "or no
column matches" coming from the OUTER specification. SQL92 uses unique
syntax to specify this.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Jan 13 00:51:53 2000
Received: from netrinsics.com (robinson@[202.106.226.225])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA70919
for <pgsql-hackers@hub.org>; Thu, 13 Jan 2000 00:51:34 -0500 (EST)
(envelope-from robinson@netrinsics.com)
Received: (from robinson@localhost)
by netrinsics.com (8.9.3/8.9.3) id NAA77189;
Thu, 13 Jan 2000 13:51:52 +0800 (+0800) (envelope-from robinson)
Date: Thu, 13 Jan 2000 13:51:52 +0800 (+0800)
From: Michael Robinson <robinson@netrinsics.com>
Message-Id: <200001130551.NAA77189@netrinsics.com>
To: lockhart@alumni.caltech.edu, robinson@netrinsics.com
Subject: Re: [HACKERS] Copy from/to asymmetry
Cc: pgsql-hackers@hub.org
In-Reply-To: <387D59D3.FB3DCE60@alumni.caltech.edu>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
EncodeDateTime,
on the other hand, blindly spits out whatever the operating system gives it
from localtime().Yup. afaik this is the only way to get daylight savings time info
since there is no api to do so otherwise. Since this is the very first
report of this style of timezone, I don't feel too guilty, and it will
be easy to fix (I hope anyway).
The GMT+8 format is part of the POSIX standard (at least according to
the zoneinfo source file). In the meantime, I've created a new zoneinfo
file with ISO "+0800" format, as a workaround. (To make matters worse, I
discovered that POSIX GMT+8 == ISO -0800 ; in other words, the semantics of
the sign character are reversed in the two standards.)
1. x == datetime_in(datetime_out(x)) should always be true for all valid x.
Impossible to do apriori, given that we rely on the system to provide
timezone info for output. However, we try to fix all unusual cases,
and afaik there are no reasonable formats we have rejected for
support.
Perhaps, if the system supports strptime(), this function could be used as
a last-ditch effort by ParseDateTime before returning an error. That would
solve all cases where the datetime_in timezone equals the system timezone
setting.
Or, maybe just use strptime() outright. I don't know, it's just a suggestion.
-Michael Robinson
From bouncefilter Thu Jan 13 06:27:53 2000
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA59871
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 06:27:40 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9D3E1E.dip0.t-ipconnect.de
(root@p3E9D3E1E.dip0.t-ipconnect.de [62.157.62.30])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id MAA66748
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 12:28:08 +0100 (CET)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id IAA07441
for pgsql-hackers@postgreSQL.org; Thu, 13 Jan 2000 08:48:17 +0100
Date: Thu, 13 Jan 2000 08:48:16 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FETCH without FROM/IN
Message-ID: <20000113084816.A7433@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000112161216.A334@fam-meskes.de> <9917.947693351@sss.pgh.pa.us>
<20000112175326.A2376@fam-meskes.de>
<11241.947725982@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <11241.947725982@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Wed, Jan 12, 2000 at 08:13:02PM -0500
On Wed, Jan 12, 2000 at 08:13:02PM -0500, Tom Lane wrote:
I think, though, that you could make our syntax work like
FETCH [ opt_direction fetch_how_many FROM/IN ] portal_name
without conflicts. That'd be good since it'd be more like SQL92.
Yes. I just read the patch I got from Rene in detail and it seems to
implement:
FETCH [ <direction> [ <fetch_how_many> ]] [ FROM/IN ] portal_name;
Both direction and fetch_how_many are no longer optional in that they could
be replaced by an empty string I wonder if this is correct. It would mean
that we have to specify an amount resp. all everytime we do give a
direction.
However, I think it should be possible to make it:
FETCH [ <direction> ][ <fetch_how_many> ] [ FROM/IN ] portal_name;
This seems better, isn't it?
Michael
-
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Thu Jan 13 04:23:03 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA27630
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 04:22:06 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id KAA207714;
Thu, 13 Jan 2000 10:21:58 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALM5AW>; Thu, 13 Jan 2000 10:21:58 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC1FE@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Peter Eisentraut'" <peter_e@gmx.net>
Cc: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: AW: [HACKERS] Re: Regress tests reveal *serious* psql bug
Date: Thu, 13 Jan 2000 10:21:57 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
If I'm going to hack around in that code, one related question: what
should the deal be regarding variable interpolation into quoted
strings? Yes/No/Maybe?
definitely No. If you want to specify a string with an embedded variable,
the imho expected syntax would be:
'The table ' || :tabname || ' is empty'
Of course that has the problem, that psql would have to quote the :tabname
content.
Andreas
From bouncefilter Thu Jan 13 04:26:52 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA28183
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 04:26:25 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id KAA205236
for <pgsql-hackers@postgreSQL.org>; Thu, 13 Jan 2000 10:26:21 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALM5BK>; Thu, 13 Jan 2000 10:26:18 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC1FF@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Re: Regress tests reveal *serious* psql bug
Date: Thu, 13 Jan 2000 10:26:17 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
In fact, I think it should be an error to reference a variable that is
not defined. This will catch accidental references too. If you
reference a variable that does not exist like :myvar, it passes the
literal :myvar to the backend.
That is what I would expect also.
Andreas
From bouncefilter Thu Jan 13 04:33:51 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA32425
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 04:33:47 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id KAA222104
for <pgsql-hackers@postgreSQL.org>; Thu, 13 Jan 2000 10:33:44 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALM5D1>; Thu, 13 Jan 2000 10:33:44 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC200@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Re: Regress tests reveal *serious* psql bug
Date: Thu, 13 Jan 2000 10:33:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
SELECT arrtest.a[1:3],
arrtest.b[1:1][1:2][1:2],
arrtest.c[1:2],
arrtest.d[1:1][1:2]
FROM arrtest;
Sorry for the stupid question, but can sombody enlighten me.
Why was the ":" used in the first place ? I would expect to use a ','
for an array slice. No ?
As in: select arrtest.a[1,1][1,2]
(This is also what others use for array slices)
Andreas
From bouncefilter Thu Jan 13 05:23:56 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA46575
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 05:22:58 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id FAA01848
for pgsql-hackers@postgresql.org; Thu, 13 Jan 2000 05:05:58 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: "Kevin Lam" <kamanl@earthlink.com>
X-Newsgroups: comp.databases.postgresql.hackers
References: <o5e94.3459$GF1.189168@newsread1.prod.itd.earthlink.net>
<dMD94.30940$kX4.128640@news.rdc2.mi.home.com>
<38782bb0.1232288@news.earthlink.net>
Subject: Re: question about MS Access connect to Postgresql 6.5.2-1
Lines: 20
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Message-ID: <M1hf4.10571$o62.480245@newsread1.prod.itd.earthlink.net>
X-Complaints-To: abuse@earthlink.net
X-Trace: newsread1.prod.itd.earthlink.net 947756268 207.217.154.186 (Thu,
13 Jan 2000 01:37:48 PST)
Organization: EarthLink Network, Inc.
X-ELN-Date: Thu Jan 13 01:37:48 2000
Date: Thu, 13 Jan 2000 09:37:48 GMT
To: pgsql-hackers@postgresql.org
"Micheal H." <mr_hopkins@earthlink.net> wrote in message
news:38782bb0.1232288@news.earthlink.net...
I found the read only option, unchecked it and still have the problem
updating or adding records...Postgresql-6.3.2 and Access97
It's working fine to me now. The one of the drawback of
creating database in Access97 and upsize (right term? ) to
postgres will remove your primary for some unknown
reason. So, my best bet is creating those tables by using
postgres and then link the table over. This works for me.
Anyone are using PhP for Windows for the web scripting
tools?
Kevin.
From bouncefilter Thu Jan 13 04:54:56 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA34480
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 04:54:19 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id KAA33278;
Thu, 13 Jan 2000 10:52:50 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALM5GX>; Thu, 13 Jan 2000 10:52:50 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC201@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Bruce Momjian'" <pgman@candle.pha.pa.us>, "'PostgreSQL-development'"
<pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Informix and OUTER join syntax
Date: Thu, 13 Jan 2000 10:52:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Looking in the Informix manuals, I now see how they handle
complex outer
joins:SELECT *
FROM tab1, OUTER(tab2, tab3)
WHERE tab1.col1 = tab2.col1 AND
tab2.col1 = tab3.col1It does the tab2, tab3 join first, then _outer_ joins to tab1.
Interesting.
Ok, just to clarify:
this select gives at least one row for every row in tab1
if an inner join on tab2, tab3 does not give a match (tab1.col1=tab2.col1)
all columns of tab2 and tab3 are set to null for that row.
If that is what you said, I didn't understand it.
Andreas
From bouncefilter Thu Jan 13 05:12:57 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA41097
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 05:12:27 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA11258;
Thu, 13 Jan 2000 11:11:51 +0100
Date: Thu, 13 Jan 2000 11:11:51 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Status request for 7.0
In-Reply-To: <200001122241.RAA18423@candle.pha.pa.us>
Message-ID: <Pine.LNX.3.96.1000113105655.8168F-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 12 Jan 2000, Bruce Momjian wrote:
We are about 3 weeks from the scheduled 7.0 beta.
I am interested in hearing a status on our open items:
foreign keys/activity queue - Jan
long tuples/TOAST - Jan
outer joins - Thomas
Date/Time types - Thomas
I'm finishing to_char()'s family routines now (it is 8 routines).
I'd like remove it to main tree next week (I will send patch).
Agree Thomas?
Karel
From bouncefilter Thu Jan 13 05:41:56 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA51170
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 05:41:32 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id LAA32090;
Thu, 13 Jan 2000 11:38:12 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALM5RV>; Thu, 13 Jan 2000 11:38:11 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC203@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Bruce Momjian'" <pgman@candle.pha.pa.us>, "'Tom Lane'"
<tgl@sss.pgh.pa.us>
Cc: "'Hiroshi Inoue'" <Inoue@tpf.co.jp>, "'PostgreSQL-development'"
<pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] TODO list updated
Date: Thu, 13 Jan 2000 11:38:10 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Bruce Momjian <pgman@candle.pha.pa.us> writes:
We currently do not use indexes to handle ORDER BY
because it is slower,
Er, actually, we *do* use indexes for ORDER BY currently:
regression=# explain select * from tenk1 order by unique1;
NOTICE: QUERY PLAN:
Index Scan using tenk1_unique1 on tenk1 (cost=760.00rows=10000 width=148)
If you start psql with PGOPTIONS="-fi" you can see that the
optimizer
believes an explicit sort would be much slower:
regression=# explain select * from tenk1 order by unique1;
NOTICE: QUERY PLAN:
Sort (cost=3233.91 rows=10000 width=148)
-> Seq Scan on tenk1 (cost=563.00 rows=10000 width=148)but (at least on my machine) the explicit sort is marginally faster.
Evidently, the cost estimate for an explicit sort is *way* too high.
Doing the sort, or the index access is allways a tradeoff.
For interactive access the index is faster,
for batch mode the sort is faster.
I would try to avoid a sort, that would need more than a few
100 Mb of sort disk space, even if I would eventually get my last
row faster.
The tradeoff is, that you wait an hour before you get the first row,
and block all those resources until you finish.
The index access gives the first rows fast, and does not block
resources.
In mathematical terms I would give the sort an exponential cost
curve regarding sort size
(probably also dependent on ~16 * available sort memory),
and the index access a linear cost curve.
Andreas
From bouncefilter Thu Jan 13 06:01:10 2000
Received: from meryl.it.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA54381
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 06:00:38 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Pingvin.DoCS.UU.SE (e99re41@Pingvin.DoCS.UU.SE [130.238.9.118])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA10258;
Thu, 13 Jan 2000 12:00:30 +0100 (MET)
Received: from localhost (e99re41@localhost) by Pingvin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA06454;
Thu, 13 Jan 2000 12:00:29 +0100
X-Authentication-Warning: Pingvin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 13 Jan 2000 12:00:28 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] libpq+MB/putenv(), getenv() clean up
In-Reply-To: <20000113105845O.t-ishii@sra.co.jp>
Message-ID: <Pine.GSO.4.02A.10001131154340.6438-100000@Pingvin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Tatsuo Ishii wrote:
Hi,
I have a plan to clean up the usage of putenv(), getenv() in libpq+MB
configuration. This needs some interface changes with libpq in the
frontend side. I'm not sure this is visible to end users or not, and I
would like to hear from hackes.First of all, I would like to explain the current implementation.
(1) While establishing a connection, if the environment variable
PGCLIENTENCODING is not set, libpq asks the backend what the encoding
for the database is. This is done by sending a query "select
getdatabaseencoding()". In this case, both the backend and the
frontend uses same encoding and its name is set to the
PGCLIENTENCODING environment variable for the later use.
(fe-connect.c: PQsetenvPoll())
Whatever you do, please do not set any environment variables from within
programs. It's evil. Consider the user leaving the database and connecting
to another, but then PGCLIENTENCODING is already set to what would be
interpreted as his "preference", but maybe he wants the backend to decide.
I saw you had some hacks in psql for working around this, but psql is not
every application. I think what you are suggesting below would incorporate
this change, I just want to express it explicitly.
(2) When libpq prints the result of a query, it needs to determine the
length of a multi-byte letter. For this purpose, getenv() is called to
know the encoding name. (fe-print.c)Above implementation has a design flaw since it is not multithread-safe.
To fix the problem, I would like to make changes as follows:(1) Add a new member "int client_encoding" to struct pg_conn.
(2) Add an argument which is a pointer to PGconn to PQsetenvPoll() so
that the client encoding can be set in (1) above.(3) Add a new function PQclientencoding() to extract client_encoding
from PGconn.
How about PQencoding()?
(4) Change PQmblen() so that it extracts encoding info using
PQclientencoding() rather than calling getenv(). This also requires
add an argument which is a pointer to PGconn.
How about PQmblen(character, encoding)? Then you could call it PQmblen(c,
PQclientencoding(conn)) or PQmblen(c, other_encoding). That makes it more
general.
(5) Change fe-print.c:do_filed() to add an argument which is a pointer to
PGconn.Comments and suggestions are welcome.
--
Tatsuo Ishii************
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 13 06:12:52 2000
Received: from meryl.it.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA57661
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 06:12:32 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Pingvin.DoCS.UU.SE (e99re41@Pingvin.DoCS.UU.SE [130.238.9.118])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA11194;
Thu, 13 Jan 2000 12:12:29 +0100 (MET)
Received: from localhost (e99re41@localhost) by Pingvin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA06473;
Thu, 13 Jan 2000 12:12:27 +0100
X-Authentication-Warning: Pingvin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 13 Jan 2000 12:12:27 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <200001122350.SAA21120@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.10001131200420.6438-100000@Pingvin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 12 Jan 2000, Bruce Momjian wrote:
Wow, we're at 32% done!
Actually, there are tons of _done_ items on the list. I mentioned only
the big undone ones.
I just do a
echo $(( `grep '^* -' TODO | wc -l` * 100 / `grep '^*' TODO | wc -l` ))
<grin>
* Make postgres user have a password by default
There's an initdb switch.
OK, now we have to decide if we are going to require this be done as
part of initdb. I am inclined to say the user _has_ to be _prompted_ in
a secure matter for the password as part of initdb. Have a command-line
switch for the password is not secure, IMHO, though it is better than
nothing.
Okay, a prompt it shall be. But not mandatory, since in my environment we
don't even use passwords.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 13 06:16:57 2000
Received: from meryl.it.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA58156
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 06:16:20 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Pingvin.DoCS.UU.SE (e99re41@Pingvin.DoCS.UU.SE [130.238.9.118])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA11379;
Thu, 13 Jan 2000 12:16:11 +0100 (MET)
Received: from localhost (e99re41@localhost) by Pingvin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA06477;
Thu, 13 Jan 2000 12:16:10 +0100
X-Authentication-Warning: Pingvin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 13 Jan 2000 12:16:09 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <11294.947726814@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10001131213500.6438-100000@Pingvin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 12 Jan 2000, Tom Lane wrote:
Note that if initdb is a shell script, then it still has to be very
careful what it does with the password; put it in any command line
for a program invoked by the script, and the leak is back with you.
A C-program version of initdb would be a lot safer. But in theory you
can pass the password to the backend without exposing it in any command
line (put it in a data file instead, say).
What is does is some sort of sed s/genericpassword/realpassword/ so I
guess this is not completely safe either. But something like this you'd
have to do. Can I count you in on beating Bruce into submission for an
initdb in C? ;)
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 13 06:21:52 2000
Received: from meryl.it.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA58876
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 06:21:47 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Pingvin.DoCS.UU.SE (e99re41@Pingvin.DoCS.UU.SE [130.238.9.118])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA11702;
Thu, 13 Jan 2000 12:21:36 +0100 (MET)
Received: from localhost (e99re41@localhost) by Pingvin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA06491;
Thu, 13 Jan 2000 12:21:29 +0100
X-Authentication-Warning: Pingvin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 13 Jan 2000 12:21:27 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@hub.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.BSF.4.21.0001122153320.46499-100000@thelab.hub.org>
Message-ID: <Pine.GSO.4.02A.10001131216270.6438-100000@Pingvin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 12 Jan 2000, The Hermit Hacker wrote:
On Wed, 12 Jan 2000, Bruce Momjian wrote:
If we do a 'CREATE USER <user> WITH PASSWORD <pass>', its no more secure
then using a command line switch for password ...Why is that? ps shows command args, righ?
Point. You won me over :)
But it doesn't show the complete command line, only SELECT or UPDATE, etc.
I'm not sure if it also shows create, I haven't been able to simulate
that.
What's the whole point of access control if you can happily scan your ps
output for all selects, inserts, updates, etc. going through and keep
record of it?
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 13 06:24:59 2000
Received: from meryl.it.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA59244
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 06:24:08 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Pingvin.DoCS.UU.SE (e99re41@Pingvin.DoCS.UU.SE [130.238.9.118])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA11815;
Thu, 13 Jan 2000 12:23:57 +0100 (MET)
Received: from localhost (e99re41@localhost) by Pingvin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA06495;
Thu, 13 Jan 2000 12:23:51 +0100
X-Authentication-Warning: Pingvin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 13 Jan 2000 12:23:49 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: SAKAIDA <sakaida@psn.co.jp>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] libpq+MB/putenv(), getenv() clean up
In-Reply-To: <387D523014A.9FD9SAKAIDA@smtp.psn.ne.jp>
Message-ID: <Pine.GSO.4.02A.10001131222280.6438-100000@Pingvin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, SAKAIDA wrote:
Do those changes mean that libpq(or psql) always has the MULTIBYTE
function?Now, libpq's MULTIBYTE function is a compile option(--with-mb).
But, I always want the MULTIBYTE function, even if PostgreSQL have
*not* been made with "--with-mb" option. Because, I want to access
two kind of PostgreSQL servers(named A and B) by using the B's psql.
(Here, A server is "--with-mb" and B server is not "--with-mb".)
Aah, that's a good point, but an always-on psql and libpq is much slower.
But you could use the psql that stems from the multibyte compile, or not?
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 13 06:27:53 2000
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA59860
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 06:27:35 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9D3E1E.dip0.t-ipconnect.de
(root@p3E9D3E1E.dip0.t-ipconnect.de [62.157.62.30])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id MAA66726
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 12:28:03 +0100 (CET)
Received: (from michael@localhost)
by p3E9D3E1E.dip0.t-ipconnect.de (8.9.3/8.9.3/Debian 8.9.3-6) id
MAA00751
for pgsql-hackers@postgresql.org; Thu, 13 Jan 2000 12:26:21 +0100
Date: Thu, 13 Jan 2000 12:26:18 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Another item for TODO list
Message-ID: <20000113122618.A535@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
Bruce, could you please add
* fix array handling for ECPG
to our TODO list for 7.0?
Thanks.
Right now you can insert an array of integeres as single integers but not as
array. And you cannot insert an array of structs as single structs.
This has to be cleaned up.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Thu Jan 13 06:30:58 2000
Received: from meryl.it.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA62008
for <hackers@postgresql.org>; Thu, 13 Jan 2000 06:30:54 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Pingvin.DoCS.UU.SE (e99re41@Pingvin.DoCS.UU.SE [130.238.9.118])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA12187;
Thu, 13 Jan 2000 12:30:43 +0100 (MET)
Received: from localhost (e99re41@localhost) by Pingvin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA06499;
Thu, 13 Jan 2000 12:30:41 +0100
X-Authentication-Warning: Pingvin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 13 Jan 2000 12:30:40 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
cc: Tatsuo Ishii <t-ishii@sra.co.jp>
Subject: --enable-multibyte
Message-ID: <Pine.GSO.4.02A.10001131224190.6438-100000@Pingvin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
We had a dicussion about this already, but I think I came up with a
solution that works for everyone.
[proposal]
* If you configure with --enable-multibyte then you build a server and
clients that are multibyte enabled (as defined by the MULTIBYTE symbol).
If you don't use multibyte functionality then nothing will change, so this
would be the preferred option for package maintainers.
* If you configure with --enable-multibyte=XXX then XXX will be initdb's
default encoding, but XXX won't be used anywhere else. This option is for
those who insist on it; the preferred way to go about this would be the
respective option for initdb itself.
I'd leave the --with-mb option in there but hidden and make the new option
the published interface. Any protests?
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 13 07:42:58 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA77143
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 07:42:34 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id IAA74601;
Thu, 13 Jan 2000 08:40:30 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 13 Jan 2000 08:40:30 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.GSO.4.02A.10001131213500.6438-100000@Pingvin.DoCS.UU.SE>
Message-ID: <Pine.BSF.4.21.0001130839130.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Peter Eisentraut wrote:
On Wed, 12 Jan 2000, Tom Lane wrote:
Note that if initdb is a shell script, then it still has to be very
careful what it does with the password; put it in any command line
for a program invoked by the script, and the leak is back with you.
A C-program version of initdb would be a lot safer. But in theory you
can pass the password to the backend without exposing it in any command
line (put it in a data file instead, say).What is does is some sort of sed s/genericpassword/realpassword/ so I
guess this is not completely safe either. But something like this you'd
have to do. Can I count you in on beating Bruce into submission for an
initdb in C? ;)
Just a thought...since its a script, why not put the password into an
environment variable and read it from that?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 13 07:43:00 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA77160
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 07:42:53 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id IAA74605;
Thu, 13 Jan 2000 08:41:48 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 13 Jan 2000 08:41:48 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.GSO.4.02A.10001131216270.6438-100000@Pingvin.DoCS.UU.SE>
Message-ID: <Pine.BSF.4.21.0001130840430.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Peter Eisentraut wrote:
On Wed, 12 Jan 2000, The Hermit Hacker wrote:
On Wed, 12 Jan 2000, Bruce Momjian wrote:
If we do a 'CREATE USER <user> WITH PASSWORD <pass>', its no more secure
then using a command line switch for password ...Why is that? ps shows command args, righ?
Point. You won me over :)
But it doesn't show the complete command line, only SELECT or UPDATE, etc.
I'm not sure if it also shows create, I haven't been able to simulate
that.
No, that isn't the problem...the problem is that initdb, if you run it
with command line arguments, will show up in a ps listing with those
command line arguments...
if you type 'initdb --pgpasswd=passwd' it will show up in pas as exactly
that ...
its not the SELECT/UPDATE/etc that we are worried about...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 13 07:54:58 2000
Received: from meryl.it.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA78474
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 07:53:59 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Pingvin.DoCS.UU.SE (e99re41@Pingvin.DoCS.UU.SE [130.238.9.118])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA18686;
Thu, 13 Jan 2000 13:53:55 +0100 (MET)
Received: from localhost (e99re41@localhost) by Pingvin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA06562;
Thu, 13 Jan 2000 13:53:51 +0100
X-Authentication-Warning: Pingvin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 13 Jan 2000 13:53:50 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@hub.org>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.BSF.4.21.0001130839130.46499-100000@thelab.hub.org>
Message-ID: <Pine.GSO.4.02A.10001131350530.6438-100000@Pingvin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, The Hermit Hacker wrote:
What is does is some sort of sed s/genericpassword/realpassword/ so I
guess this is not completely safe either. But something like this you'd
have to do. Can I count you in on beating Bruce into submission for an
initdb in C? ;)Just a thought...since its a script, why not put the password into an
environment variable and read it from that?
That won't solve the problem. The password has to be substituted into the
catalog template and sed is the way to go for that. I guess it's a long
shot to worry about that now. And option --pwprompt should be relatively
safe until initdb is a C program.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 13 07:55:54 2000
Received: from meryl.it.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA78631
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 07:55:13 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Pingvin.DoCS.UU.SE (e99re41@Pingvin.DoCS.UU.SE [130.238.9.118])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA18765;
Thu, 13 Jan 2000 13:55:09 +0100 (MET)
Received: from localhost (e99re41@localhost) by Pingvin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA06566;
Thu, 13 Jan 2000 13:55:08 +0100
X-Authentication-Warning: Pingvin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 13 Jan 2000 13:55:08 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@hub.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.BSF.4.21.0001130840430.46499-100000@thelab.hub.org>
Message-ID: <Pine.GSO.4.02A.10001131354000.6438-100000@Pingvin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, The Hermit Hacker wrote:
No, that isn't the problem...the problem is that initdb, if you run it
with command line arguments, will show up in a ps listing with those
command line arguments...if you type 'initdb --pgpasswd=passwd' it will show up in pas as exactly
that ...
Not to mention the world readable shell history files which would make
this even more convenient ...
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 13 08:34:59 2000
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 IAA92117
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 08:34:12 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
IAA25149;
Thu, 13 Jan 2000 08:15:57 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001131315.IAA25149@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.GSO.4.02A.10001131213500.6438-100000@Pingvin.DoCS.UU.SE>
from Peter Eisentraut at "Jan 13, 2000 12:16:09 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 13 Jan 2000 08:15:57 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Wed, 12 Jan 2000, Tom Lane wrote:
Note that if initdb is a shell script, then it still has to be very
careful what it does with the password; put it in any command line
for a program invoked by the script, and the leak is back with you.
A C-program version of initdb would be a lot safer. But in theory you
can pass the password to the backend without exposing it in any command
line (put it in a data file instead, say).What is does is some sort of sed s/genericpassword/realpassword/ so I
guess this is not completely safe either. But something like this you'd
have to do. Can I count you in on beating Bruce into submission for an
initdb in C? ;)
I will be responsible to make sure the password doesn't get into a
command as an argument. sed has a -f command that will take it's regex
input from a file. That is the solution, though the umask has to be set
to make sure the temp file is not readable by anyone else.
Most OS vendors use shell scripts for this type of thing because it
doesn't have to be fast, and it is changed 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 Thu Jan 13 08:20:54 2000
Received: from server1.ppc.pims.org (ptr4.skynet.be [194.78.114.4] (may be
forged)) by hub.org (8.9.3/8.9.3) with ESMTP id IAA85318;
Thu, 13 Jan 2000 08:20:06 -0500 (EST)
(envelope-from huffmana@ppc.pims.org)
Received: from ppc.pims.org ([207.176.11.63]) by server1.ppc.pims.org
(Netscape Messaging Server 3.6) with ESMTP id AAA688A;
Thu, 13 Jan 2000 14:18:40 +0100
Message-ID: <387DD039.D6AFF828@ppc.pims.org>
Date: Thu, 13 Jan 2000 14:16:42 +0100
From: "Allan Huffman" <huffmana@ppc.pims.org>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org,
swaffors@ppc.pims.org
Subject: [HACK]-[INTERFACE] jdbc/postgresql.jar execution errors
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear [HACKERS] and [NTERFACES]
We are having some trouble getting an applet that accesses PostgreSQL to
run under Netscape. The following is a present status summary:
If anyone can help it would be really terrific!
When executing the applet, the Netscape web server logs shows
connections or calls being made to different classes and jar files. The
postgresql.jar file is found correctly through the classpath (identified
in the web server start file in /Netscape/Suitespot/https-default/start
ref the classpath), but, it then seems to look for errors.class,
errors_EN.class, and errors_EN_US.class, none of which can be found. We
expanded the postgresql.jar file, and those classes weren't part of the
tree either.
This appears to be either -
For some reason normal classes (not part of the postgres
package) are being looked for as sub-classes in the postgres set
OR
Those classes are meant to be postgres error classes that
weren't compiled or included in the postgresql.jar file. Then again,
after looking at the README and Makefiles for the postgresql.jar file,
we would tend to agree that the file is being built with all the classes
normally needed. We also looked at http://www.retep.org.uk/postgres/
(faq), and it seems to suggest that building the jar file with the right
classes for postgresql is fairly straightforward.
Hmmmm.....
The applet runs correctly until it tries to execute the following
line:
==> Class.classDriver = ClassforName("postgresql.Driver");
It then enters that try/catch error process and appear to try to find
the missing classes.
When compiling the applet no error messages like "class not found"
are flagged. But, there are execution errors when we compiled with
jdbc6_5-1_2:
==>getConnection ERROR 1: The postgresql.jar file does not contain the
correct JDBC classes for this JVM. Try rebuilding. If that fails, try
forcing the version supplying it to the command line using the argument
-Djava.version=1.1 or -Djava.version=1.2
==>Exception thrown was java.lang.ClassNotFoundExcption:
postgresql.jdbc1.Connection.
Sounds a lot like the problems that we are having trying to run under
Netscape!
Allan tried to use the command line argument they talked about but can't
find the command line
in the Visual Cafe environment even after searching the help files......
Perhaps postgresql.jar is a 1.2 java driver.
We've got a business trip and we are leaving on for 2.5 to 3 weeks.
Should be fun -- a few eastern Europe countries like Uzbekistan, Kyrghyz
Republic, and Kazakhstan.
Sincerely,
Allan in Belgium
and
Scott in Germany
From bouncefilter Thu Jan 13 08:24:58 2000
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 IAA87032
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 08:23:43 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
IAA25161;
Thu, 13 Jan 2000 08:16:50 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001131316.IAA25161@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.GSO.4.02A.10001131216270.6438-100000@Pingvin.DoCS.UU.SE>
from Peter Eisentraut at "Jan 13, 2000 12:21:27 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 13 Jan 2000 08:16:50 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Wed, 12 Jan 2000, The Hermit Hacker wrote:
Point. You won me over :)
But it doesn't show the complete command line, only SELECT or UPDATE, etc.
I'm not sure if it also shows create, I haven't been able to simulate
that.What's the whole point of access control if you can happily scan your ps
output for all selects, inserts, updates, etc. going through and keep
record of it?
It only shows the command, not the table involved or the parameters.
--
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 Jan 13 08:22:59 2000
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 IAA86158;
Thu, 13 Jan 2000 08:22:00 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
IAA25230;
Thu, 13 Jan 2000 08:18:13 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001131318.IAA25230@candle.pha.pa.us>
Subject: Re: [HACKERS] Another item for TODO list
In-Reply-To: <20000113122618.A535@fam-meskes.de> from Michael Meskes at "Jan
13, 2000 12:26:18 pm"
To: Michael Meskes <meskes@postgresql.org>
Date: Thu, 13 Jan 2000 08:18:13 -0500 (EST)
CC: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce, could you please add
* fix array handling for ECPG
to our TODO list for 7.0?
Thanks.
Right now you can insert an array of integeres as single integers but not as
array. And you cannot insert an array of structs as single structs.
Added to TODO under CLIENTS.
--
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 Jan 13 08:26:54 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA87466
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 08:26:11 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
IAA25578;
Thu, 13 Jan 2000 08:22:47 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001131322.IAA25578@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.GSO.4.02A.10001131354000.6438-100000@Pingvin.DoCS.UU.SE>
from Peter Eisentraut at "Jan 13, 2000 01:55:08 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 13 Jan 2000 08:22:47 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Thu, 13 Jan 2000, The Hermit Hacker wrote:
No, that isn't the problem...the problem is that initdb, if you run it
with command line arguments, will show up in a ps listing with those
command line arguments...if you type 'initdb --pgpasswd=passwd' it will show up in pas as exactly
that ...Not to mention the world readable shell history files which would make
this even more convenient ...
Man, why is my bash shell history world-readable. Who's idea was that?
Also, Peter, I got you the sed -f option to use files as sed
parameters, which gets us out of this problem. Another day, another
escape from recoding it in C... :-)
--
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 Jan 13 08:30:55 2000
Received: from meryl.it.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA89352
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 08:30:40 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Pingvin.DoCS.UU.SE (e99re41@Pingvin.DoCS.UU.SE [130.238.9.118])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id OAA21811;
Thu, 13 Jan 2000 14:30:37 +0100 (MET)
Received: from localhost (e99re41@localhost) by Pingvin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id OAA06574;
Thu, 13 Jan 2000 14:30:35 +0100
X-Authentication-Warning: Pingvin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 13 Jan 2000 14:30:35 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <200001131315.IAA25149@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.10001131426360.6438-100000@Pingvin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Bruce Momjian wrote:
What is does is some sort of sed s/genericpassword/realpassword/ so I
guess this is not completely safe either. But something like this you'd
have to do. Can I count you in on beating Bruce into submission for an
initdb in C? ;)I will be responsible to make sure the password doesn't get into a
command as an argument. sed has a -f command that will take it's regex
input from a file. That is the solution, though the umask has to be set
to make sure the temp file is not readable by anyone else.
That's one more file to find and to erase! Sounds very ugly to me. Better
leave off this option altogether and user alter user. Can end users
comment on this at all?
Most OS vendors use shell scripts for this type of thing because it
doesn't have to be fast, and it is changed often.
So we can do it better! Also besides actual code changes (as recently),
initdb itself hardly ever changes. When I get some time I'll develop a
prototype to convince you. :)
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 13 08:39:58 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA93083
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 08:39:38 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
IAA27452;
Thu, 13 Jan 2000 08:36:01 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001131336.IAA27452@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.GSO.4.02A.10001131426360.6438-100000@Pingvin.DoCS.UU.SE>
from Peter Eisentraut at "Jan 13, 2000 02:30:35 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 13 Jan 2000 08:36:01 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Thu, 13 Jan 2000, Bruce Momjian wrote:
What is does is some sort of sed s/genericpassword/realpassword/ so I
guess this is not completely safe either. But something like this you'd
have to do. Can I count you in on beating Bruce into submission for an
initdb in C? ;)I will be responsible to make sure the password doesn't get into a
command as an argument. sed has a -f command that will take it's regex
input from a file. That is the solution, though the umask has to be set
to make sure the temp file is not readable by anyone else.That's one more file to find and to erase! Sounds very ugly to me. Better
leave off this option altogether and user alter user. Can end users
comment on this at all?
Huh. Use trap and have it automatically removed on exit:
trap "rm -f /tmp/pgpass.$$" 0 1 2 3 15
Most OS vendors use shell scripts for this type of thing because it
doesn't have to be fast, and it is changed often.So we can do it better! Also besides actual code changes (as recently),
initdb itself hardly ever changes. When I get some time I'll develop a
prototype to convince you. :)
OK.
--
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 Jan 13 08:38:58 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA92843
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 08:38:18 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA74979;
Thu, 13 Jan 2000 09:38:21 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 13 Jan 2000 09:38:21 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.GSO.4.02A.10001131426360.6438-100000@Pingvin.DoCS.UU.SE>
Message-ID: <Pine.BSF.4.21.0001130936500.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Peter Eisentraut wrote:
On Thu, 13 Jan 2000, Bruce Momjian wrote:
What is does is some sort of sed s/genericpassword/realpassword/ so I
guess this is not completely safe either. But something like this you'd
have to do. Can I count you in on beating Bruce into submission for an
initdb in C? ;)I will be responsible to make sure the password doesn't get into a
command as an argument. sed has a -f command that will take it's regex
input from a file. That is the solution, though the umask has to be set
to make sure the temp file is not readable by anyone else.That's one more file to find and to erase! Sounds very ugly to me. Better
leave off this option altogether and user alter user. Can end users
comment on this at all?Most OS vendors use shell scripts for this type of thing because it
doesn't have to be fast, and it is changed often.So we can do it better! Also besides actual code changes (as recently),
initdb itself hardly ever changes. When I get some time I'll develop a
prototype to convince you. :)
I could be wrong here, but I don't think anyone *really* cares whether its
in script or C...just nobody wants to do the coding... :)
I personally think there have been enough solutions to the problem
provided that a C version isn't required, but if someone wants to go
through the trouble of doing it (when suitable solutions are present to
not require it), who am I to argue?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 13 09:14:54 2000
Received: from alert.infoplease.com (range.infoplease.com [208.222.166.25])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA02494
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 09:14:36 -0500 (EST)
(envelope-from kdebisschop@range.infoplease.com)
Received: from skillet.infoplease.com (skillet [10.0.1.212])
by alert.infoplease.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10523;
Thu, 13 Jan 2000 09:12:09 -0500 (EST)
Received: (from kdebisschop@localhost)
by skillet.infoplease.com (8.9.3/8.9.1) id JAA17490;
Thu, 13 Jan 2000 09:12:12 -0500
Date: Thu, 13 Jan 2000 09:12:12 -0500
Message-Id: <200001131412.JAA17490@skillet.infoplease.com>
X-Authentication-Warning: skillet.infoplease.com: kdebisschop set sender to
kdebisschop@spaceheater.infoplease.com using -f
From: Karl DeBisschop <kdebisschop@range.infoplease.com>
To: peter_e@gmx.net
CC: pgman@candle.pha.pa.us, tgl@sss.pgh.pa.us, scrappy@hub.org,
pgsql-hackers@postgreSQL.org
In-reply-to: <Pine.GSO.4.02A.10001131426360.6438-100000@Pingvin.DoCS.UU.SE>
(message from Peter Eisentraut on Thu, 13 Jan 2000 14:30:35 +0100
(MET))
Subject: Re: [HACKERS] TODO list updated
Reply-to: kdebisschop@range.infoplease.com
References: <Pine.GSO.4.02A.10001131426360.6438-100000@Pingvin.DoCS.UU.SE>
That's one more file to find and to erase! Sounds very ugly to me. Better
leave off this option altogether and user alter user. Can end users
comment on this at all?
As an end user, an initdb in C sounds like the best option.
I don't really like the temp file idea - i have too many temp files
already. Nor will the average user be immediately understand that the
environment variable should be set without leaving a trace in their
history.
I suppose any of the options could be added to initdb for the novice
or lazy user. If there is no other solution, I'd prefer a note on
initdb to `psql template1` and `ALTER USER...`
--
Karl DeBisschop <kdebisschop@alert.infoplease.com>
617.832.0332 (Fax: 617.956.2696)
Information Please - your source for FREE online reference
http://www.infoplease.com - Your Ultimate Fact Finder
http://kids.infoplease.com - The Great Homework Helper
Netsaint Plugins Development
http://netsaintplug.sourceforge.net
From bouncefilter Thu Jan 13 09:34:59 2000
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 JAA08032;
Thu, 13 Jan 2000 09:34:34 -0500 (EST)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 128lKb-0002yJ-0C; Thu, 13 Jan 2000 14:34:33 +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 PAA06325;
Thu, 13 Jan 2000 15:26:10 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <C638C6DF>; Thu, 13 Jan 2000 14:34:07 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70C0A8@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Allan Huffman'" <huffmana@ppc.pims.org>, pgsql-hackers@postgresql.org,
pgsql-interfaces@postgresql.org, swaffors@ppc.pims.org
Subject: RE: [HACKERS] [HACK]-[INTERFACE] jdbc/postgresql.jar execution er
rors
Date: Thu, 13 Jan 2000 14:34:05 -0000
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain;
charset="iso-8859-1"
Replies prefixed with PM:
--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.
-----Original Message-----
From: Allan Huffman [mailto:huffmana@ppc.pims.org]
Sent: Thursday, January 13, 2000 1:17 PM
To: pgsql-hackers@postgreSQL.org; pgsql-interfaces@postgreSQL.org;
swaffors@ppc.pims.org
Subject: [HACKERS] [HACK]-[INTERFACE] jdbc/postgresql.jar execution
errors
Dear [HACKERS] and [NTERFACES]
We are having some trouble getting an applet that accesses PostgreSQL to
run under Netscape. The following is a present status summary:
If anyone can help it would be really terrific!
When executing the applet, the Netscape web server logs shows
connections or calls being made to different classes and jar files. The
postgresql.jar file is found correctly through the classpath (identified
in the web server start file in /Netscape/Suitespot/https-default/start
ref the classpath), but, it then seems to look for errors.class,
errors_EN.class, and errors_EN_US.class, none of which can be found. We
expanded the postgresql.jar file, and those classes weren't part of the
tree either.
PM: It should be looking for errors.properties, errors_en.properties
etc... This sounds like a bug in Netscapes VM...
This appears to be either -
For some reason normal classes (not part of the postgres
package) are being looked for as sub-classes in the postgres set
OR
Those classes are meant to be postgres error classes that
weren't compiled or included in the postgresql.jar file. Then again,
after looking at the README and Makefiles for the postgresql.jar file,
we would tend to agree that the file is being built with all the classes
normally needed.
PM: The files in question are actually plain text files. the standard
English one is errors.properties, which should be in the postgresql
directory. This should be the _last_ one looked for. The others are done
in reverse order, and should be parsed as errors_en_us.properties then
errors_en.properties. This allows us to have foreign language support in
the error messages (we have english & french, and 7.0 has dutch).
We also looked at http://www.retep.org.uk/postgres/
(faq), and it seems to suggest that building the jar file with the right
classes for postgresql is fairly straightforward.
Hmmmm.....
The applet runs correctly until it tries to execute the following
line:
==> Class.classDriver = ClassforName("postgresql.Driver");
PM: It should be Class.forName but I presume this is a typo...
It then enters that try/catch error process and appear to try to find
the missing classes.
PM: What version of Netscape are you using? So far, only IE has had
problems, but of those applet users contacting me haven't seen this
problem.
When compiling the applet no error messages like "class not found"
are flagged. But, there are execution errors when we compiled with
jdbc6_5-1_2:
==>getConnection ERROR 1: The postgresql.jar file does not contain the
correct JDBC classes for this JVM. Try rebuilding. If that fails, try
forcing the version supplying it to the command line using the argument
-Djava.version=1.1 or -Djava.version=1.2
PM: Compile the postgresql.jar file using JDK1.1.x (x=6 or 7) and not
1.2. Your copy of netscape is using the earlier JVM, and the class file
format is slightly different, as is the JDBC API.
==>Exception thrown was java.lang.ClassNotFoundExcption:
postgresql.jdbc1.Connection.
PM: Yes, jdbc1 is for JDK1.1.x, while jdbc2 is for JDK1.2 (aka Java2)
and later
Sounds a lot like the problems that we are having trying to run under
Netscape!
Allan tried to use the command line argument they talked about but can't
find the command line
in the Visual Cafe environment even after searching the help files......
Perhaps postgresql.jar is a 1.2 java driver.
PM: It depends on how you compile it. There are actually two drivers in
there.
We've got a business trip and we are leaving on for 2.5 to 3 weeks.
Should be fun -- a few eastern Europe countries like Uzbekistan, Kyrghyz
Republic, and Kazakhstan.
Sincerely,
Allan in Belgium
and
Scott in Germany
************
From bouncefilter Thu Jan 13 14:11:57 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id OAA83829
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 14:11:35 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 9809 invoked from network); 13 Jan 2000 19:11:14 -0000
Received: from h-62.96.160.130.host.de.colt.net (root@62.96.160.130)
by pille.addcom.de with SMTP; 13 Jan 2000 19:11:14 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id PAA01083
for pgsql-hackers@postgresql.org; Thu, 13 Jan 2000 15:39:16 +0100
Date: Thu, 13 Jan 2000 15:39:16 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: FETCH statement again
Message-ID: <20000113153916.B1071@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
I just got a reply from the original author of the patch I was talking
about:
----- Forwarded message from Rene Hogendoorn <hogend@nlr.nl> -----
From: Rene Hogendoorn <hogend@nlr.nl>
Date: Thu, 13 Jan 2000 14:23:08 +0100 (MET)
To: Michael Meskes <michael@fam-meskes.de>
Subject: Re: ECPG patches
TL> Michael Meskes <meskes@postgreSQL.org> writes:
<fetch statement> ::= FETCH [ [ <fetch orientation> ] FROM ]
<cursor name> INTO <fetch target list>
To me this seems to say that FROM is just optional. Okay, if I
make it optional in our parser?
TL> Careful --- notice that FROM is only optional if you *also*
TL> omit all the preceding optional clauses. Otherwise there will
TL> be a reduce conflict that you could only resolve by removing
TL> all of FETCH's secondary keywords from the ColId list. I
TL> don't think that would be an acceptable tradeoff.
The reduce conflict is caused by the /* EMPTY */ alternatives of
'opt_direction', 'fetch_how_many' and 'opt_portal_name'. Considering
the sql92 syntax, 'opt_portalname' is wrong; the portalname is not
optional, but required. Requiring a portalname also solves the problem
of 'EXEC SQL FETCH; being a valid statement.
Furthermore, at least INFORMIX supports 'FETCH NEXT t1;'. So, I strongly
suggest to NOT require 'FROM'.
...
Regards
Rene
--
R. A. Hogendoorn E-mail: hogend@nlr.nl
Information and Communication Technology Division Tel. +31-527-24-8367
National Aerospace Laboratory, The Netherlands Fax. +31-527-24-8210
----- End forwarded message -----
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Thu Jan 13 10:41:55 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA25395
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 10:41:15 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA08638;
Thu, 13 Jan 2000 07:25:36 -0800 (PST)
Message-Id: <3.0.1.32.20000113065514.01066e10@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 13 Jan 2000 06:55:14 -0800
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: Informix and OUTER join syntax
Cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <387D5BF8.F1B7EE5A@alumni.caltech.edu>
References: <From "(env:" "pgman)" at "Jan 12, 2000 03:38:10 pm">
<3.0.1.32.20000112131308.01051970@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 05:00 AM 1/13/00 +0000, Thomas Lockhart wrote:
SELECT *
FROM tab1, OUTER(tab2, OUTER tab3)
WHERE tab1.col1 = tab2.col1 AND
tab2.col1 = tab3.col1
It does the tab2, tab3 as an _outer_ join first, then _outer_ joins to
tab1. Can someone show me this in ANSI syntax?SELECT *
FROM tab1 RIGHT JOIN (tab2 RIGHT JOIN tab3 on col1) on col1Pretty sure this is correct (assuming that the Informix syntax is
showing a right-side outer join). istm that SQL92 is clearer, in the
sense that the WHERE clause in the Informix syntax specifies that
columns shall be equal, when in fact there is an implicit "or no
column matches" coming from the OUTER specification. SQL92 uses unique
syntax to specify this.
And if I understand SQL92 correctly, if tab1, tab2, and tab3 only
share col1 in common, then you can further simplify:
SELECT *
FROM tab1 NATURAL RIGHT JOIN (tab2 NATURAL RIGHT JOIN tab3)
Is that right? Again, I'm missing my Date SQL 92 primer...and some
might argue this is less clear than explicitly listing the column(s)
to join on.
Anyway, thanks for the verification of my first stab at this, I think
I'm getting a feel for the notation.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 13 10:16:55 2000
Received: from www.geocrawler.com (sourceforge.net [209.81.8.17])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA15701
for <pgsql-hackers@hub.org>; Thu, 13 Jan 2000 10:16:41 -0500 (EST)
(envelope-from nobody@www.geocrawler.com)
Received: (from nobody@localhost)
by www.geocrawler.com (8.9.3/8.9.3) id HAA07465;
Thu, 13 Jan 2000 07:16:41 -0800
Date: Thu, 13 Jan 2000 07:16:41 -0800
Message-Id: <200001131516.HAA07465@www.geocrawler.com>
To: pgsql-hackers@hub.org
Subject: Uninstalling PostgreSQL ??!!
From: "Adam Walczykiewicz" <archiver@db.geocrawler.com>
Reply-To: "Adam Walczykiewicz" <adam.walczykiewicz@multiuser.com.pl>
This message was sent from Geocrawler.com by "Adam Walczykiewicz" <adam.walczykiewicz@multiuser.com.pl>
Be sure to reply to that address.
Hi!
I've compiled and installed PostgreSQL v.6.5.2.
(I use SuSe Linux 6.2.).
Now I want to replace it with v.6.5.3.
There is "make clean" statement in Makefile.
But where to find "make uninstall"?
Is PostgreSQL install only in /usr/local/pgsql
(I used default Dir) and it's enough to
rm -f from that directory(?!).
(I would like to make PostgreSQL.RPM for SuSe
Linux.that's why I have to know how to
uninstall...)
Thanks for any help!
Adam(adam.walczykiewicz@multiuser.com.pl)
Geocrawler.com - The Knowledge Archive
From bouncefilter Thu Jan 13 10:24:55 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA16940
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 10:24:44 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA29168
for <pgsql-hackers@postgreSQL.org>; Thu, 13 Jan 2000 16:24:42 +0100
Date: Thu, 13 Jan 2000 16:24:42 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: How PG parser search (build-in) function?
Message-ID: <Pine.LNX.3.96.1000113160102.19765F-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
I have a question... How PG parser select (build-in) function?
Check parser function's arguments datetypes only or check returns value
datetype too (for function searching in system cache ..etc)?
I have function to_number(text, text) this function returns numeric
datetype. Is possible (effective) write this function for more
datatypes than for numeric? The function is always "to_number(text, text)",
possible difference is in a returned datetype.
(The function extract number from formated string and this number
return, but how datetype we want return?)
Karel
PS. Sorry if my problem description is a litle mazy..
----------------------------------------------------------------------
Karel Zak <zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/
Docs: http://docs.linux.cz (big docs archive)
Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
-----------------------------------------------------------------------
From bouncefilter Thu Jan 13 10:38:55 2000
Received: from meryl.it.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA24976
for <pgsql-hackers@hub.org>; Thu, 13 Jan 2000 10:38:30 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Pingvin.DoCS.UU.SE (e99re41@Pingvin.DoCS.UU.SE [130.238.9.118])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id QAA02800;
Thu, 13 Jan 2000 16:38:21 +0100 (MET)
Received: from localhost (e99re41@localhost) by Pingvin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id QAA06640;
Thu, 13 Jan 2000 16:38:18 +0100
X-Authentication-Warning: Pingvin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 13 Jan 2000 16:38:17 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Adam Walczykiewicz <adam.walczykiewicz@multiuser.com.pl>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] Uninstalling PostgreSQL ??!!
In-Reply-To: <200001131516.HAA07465@www.geocrawler.com>
Message-ID: <Pine.GSO.4.02A.10001131634260.6438-100000@Pingvin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Adam Walczykiewicz wrote:
This message was sent from Geocrawler.com by "Adam Walczykiewicz" <adam.walczykiewicz@multiuser.com.pl>
Be sure to reply to that address.Hi!
I've compiled and installed PostgreSQL v.6.5.2.
(I use SuSe Linux 6.2.).
Now I want to replace it with v.6.5.3.
There is "make clean" statement in Makefile.
But where to find "make uninstall"?
One more reason to move to automake, ey?
Is PostgreSQL install only in /usr/local/pgsql
(I used default Dir) and it's enough to
rm -f from that directory(?!).
Yes.
(I would like to make PostgreSQL.RPM for SuSe
Linux.that's why I have to know how to
uninstall...)
I think you have a misconception about RPMs. Your easiest bet would be to
start at with the RedHat RPMs and adjust what needs adjusting.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 13 10:45:55 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA26206
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 10:45:41 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA12674;
Thu, 13 Jan 2000 10:45:15 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-reply-to: <200001131315.IAA25149@candle.pha.pa.us>
References: <200001131315.IAA25149@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Thu, 13 Jan 2000 08:15:57 -0500"
Date: Thu, 13 Jan 2000 10:45:15 -0500
Message-ID: <12671.947778315@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I will be responsible to make sure the password doesn't get into a
command as an argument. sed has a -f command that will take it's regex
input from a file. That is the solution, though the umask has to be set
to make sure the temp file is not readable by anyone else.
Another possibility is not to try to 'sed' the password into the initial
database contents, but to run an ALTER USER command (using a standalone
backend) after we've done the initial setup of template1. As long as
this is done before a postmaster is started, it's perfectly safe ---
no one other than the postgres user will have been able to connect to
the database yet.
Doing it this way, the password would need to appear in the stdin input
of that standalone backend, but not anyplace else.
After thinking about it a little more, I wonder if I was too optimistic
to say that an initdb script could transfer the password securely.
Consider: we can get the password with
echo "Please enter password for postgres superuser: "
read PASSWORD
and now the password is in a shell variable of the shell running initdb,
and hasn't been exposed anywhere else. So far so good, but now what?
You can't securely do
echo $PASSWORD | backend
or
echo $PASSWORD > allegedly-secure-temp-file
or even
backend <<EOF
ALTER USER ... PASSWORD $PASSWORD
EOF
(the latter *looks* good, but way too many shells implement
here-documents by creating a temp file to put the data in;
do you want to trust the shell to make the here-doc secure?)
What I am starting to think is that we do need a C program. However,
it could be very small; it shouldn't try to do all of what initdb does.
All it needs to do is fetch the password from stdin and then echo it
to stdout in an ALTER USER command. The invocation in initdb would
look something like
securepassword $SUPERUSERNAME | standalone-backend ...
and the code would be on the order of
fprintf(stderr, "Please enter password for %s: ", argv[1]);
fgets(stdin, password);
printf("ALTER USER %s PASSWORD '%s'\n", argv[1], password);
(Actually, you'd want it to do a few more pushups: turn off tty
echoing before prompting for password, read password twice and
check it was entered the same both times, retry if not, etc.
Another reason that a pure shell script isn't really up to the
job is that AFAIR it can't easily turn off tty echoing.)
regards, tom lane
From bouncefilter Thu Jan 13 10:50:55 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA27044
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 10:50:18 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA12726;
Thu, 13 Jan 2000 10:50:08 -0500 (EST)
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] How PG parser search (build-in) function?
In-reply-to: <Pine.LNX.3.96.1000113160102.19765F-100000@ara.zf.jcu.cz>
References: <Pine.LNX.3.96.1000113160102.19765F-100000@ara.zf.jcu.cz>
Comments: In-reply-to Karel Zak - Zakkr <zakkr@zf.jcu.cz>
message dated "Thu, 13 Jan 2000 16:24:42 +0100"
Date: Thu, 13 Jan 2000 10:50:07 -0500
Message-ID: <12723.947778607@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Karel Zak - Zakkr <zakkr@zf.jcu.cz> writes:
I have a question... How PG parser select (build-in) function?
Check parser function's arguments datetypes only or check returns value
datetype too (for function searching in system cache ..etc)?
The argument types have to be different. In general, the parser
doesn't *know* what the return type of the function is; it has to
discover that by looking up the function. So you can't have two
functions of the same name unless they differ in number and/or type
of arguments.
regards, tom lane
From bouncefilter Thu Jan 13 11:01:55 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA30614
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 11:01:45 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA29869;
Thu, 13 Jan 2000 10:57:33 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001131557.KAA29869@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <12671.947778315@sss.pgh.pa.us> from Tom Lane at "Jan 13,
2000 10:45:15 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 13 Jan 2000 10:57:33 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
After thinking about it a little more, I wonder if I was too optimistic
to say that an initdb script could transfer the password securely.
Consider: we can get the password withecho "Please enter password for postgres superuser: "
read PASSWORDand now the password is in a shell variable of the shell running initdb,
and hasn't been exposed anywhere else. So far so good, but now what?
You can't securely doecho $PASSWORD | backend
or
echo $PASSWORD > allegedly-secure-temp-file
This is secure. echo is a shell builtin, and does not invoke a separate
process with arguments.
(Actually, you'd want it to do a few more pushups: turn off tty
echoing before prompting for password, read password twice and
check it was entered the same both times, retry if not, etc.
Another reason that a pure shell script isn't really up to the
job is that AFAIR it can't easily turn off tty echoing.)
That is the part that is hard to do in a shell, except I think there are
stty settings for this.
I just did:
stty -echo
read PASS
stty echo
echo $PASS
and it worked perfectly:
#$ /bjm/x
<- typed test here
test
--
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 Jan 13 11:02:56 2000
Received: from meryl.it.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA31354
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 11:02:19 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Pingvin.DoCS.UU.SE (e99re41@Pingvin.DoCS.UU.SE [130.238.9.118])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA05224;
Thu, 13 Jan 2000 17:02:16 +0100 (MET)
Received: from localhost (e99re41@localhost) by Pingvin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id RAA06644;
Thu, 13 Jan 2000 17:02:14 +0100
X-Authentication-Warning: Pingvin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 13 Jan 2000 17:02:14 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: initdb (Re: [HACKERS] TODO list updated)
In-Reply-To: <12671.947778315@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10001131653240.6438-100000@Pingvin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Tom Lane wrote:
What I am starting to think is that we do need a C program. However,
it could be very small; it shouldn't try to do all of what initdb does.
All it needs to do is fetch the password from stdin and then echo it
to stdout in an ALTER USER command. The invocation in initdb would
One more little utility lying around, not my favourite.
What I had been phantasizing about is an initdb completely in C that
a) eliminates all shell incompatibilities
b) doesn't depend on the grace of external utilities
c) doesn't need any external files
The implemenation idea behind c) was to include all the catalog/*.h files
directly, having changed the DATA() and DESC() macros prior, thus
eliminating the need for .bki files, genbki.sh (which fortunately hadn't
had any compatibility problems), another set of files being installed that
you don't really need at runtime.
Also you wouldn't need pg_version or pg_encoding which implies you don't
need libpq, which means you don't need to set LD_LIBRARY_PATH. The idea is
that initdb should run right out of the box after make install.
I'm going to try if I can get something like this together before this
thing goes out the door. But I urge you to give the potential advantages
of this careful consideration.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 13 11:05:55 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA32970
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 11:05:05 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA30451;
Thu, 13 Jan 2000 17:04:28 +0100
Date: Thu, 13 Jan 2000 17:04:28 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] How PG parser search (build-in) function?
In-Reply-To: <12723.947778607@sss.pgh.pa.us>
Message-ID: <Pine.LNX.3.96.1000113165409.30099A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Tom Lane wrote:
Karel Zak - Zakkr <zakkr@zf.jcu.cz> writes:
I have a question... How PG parser select (build-in) function?
Check parser function's arguments datetypes only or check returns value
datetype too (for function searching in system cache ..etc)?The argument types have to be different. In general, the parser
doesn't *know* what the return type of the function is; it has to
discover that by looking up the function. So you can't have two
functions of the same name unless they differ in number and/or type
of arguments.
Well, we must use the numeric version of to_number() only and parser
must cast from numeric itself (but IMHO it is not effective convert in
to_number() string to numeric and in parser convert numeric to other
datetype. But if it not possible.. :-(
Thank!
Karel
From bouncefilter Thu Jan 13 11:34:56 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA40337;
Thu, 13 Jan 2000 11:34:45 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA12928;
Thu, 13 Jan 2000 11:34:31 -0500 (EST)
To: Michael Meskes <meskes@postgreSQL.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FETCH without FROM/IN
In-reply-to: <20000113084816.A7433@fam-meskes.de>
References: <20000112161216.A334@fam-meskes.de> <9917.947693351@sss.pgh.pa.us>
<20000112175326.A2376@fam-meskes.de>
<11241.947725982@sss.pgh.pa.us>
<20000113084816.A7433@fam-meskes.de>
Comments: In-reply-to Michael Meskes <meskes@postgreSQL.org>
message dated "Thu, 13 Jan 2000 08:48:16 +0100"
Date: Thu, 13 Jan 2000 11:34:31 -0500
Message-ID: <12925.947781271@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Meskes <meskes@postgreSQL.org> writes:
On Wed, Jan 12, 2000 at 08:13:02PM -0500, Tom Lane wrote:
I think, though, that you could make our syntax work like
FETCH [ opt_direction fetch_how_many FROM/IN ] portal_name
without conflicts. That'd be good since it'd be more like SQL92.
Note: I was assuming the same definitions of 'opt_direction' and
'fetch_how_many' as are in the current gram.y; namely, they can
expand to either an option phrase or empty. So what I was really
saying is
FETCH [ [ direction ] [ how_many ] FROM/IN ] portal_name
Yes. I just read the patch I got from Rene in detail and it seems to
implement:
FETCH [ <direction> [ <fetch_how_many> ]] [ FROM/IN ] portal_name;
Certainly we currently accept a how_many clause without a preceding
direction, so if the patch removes that possibility then it's wrong.
However, I think it should be possible to make it:
FETCH [ <direction> ][ <fetch_how_many> ] [ FROM/IN ] portal_name;
This seems better, isn't it?
If you do it like that (ie, the portal name is now required), I *think*
it will work without shift-reduce conflicts in the current grammar,
but we may regret it later when we try to do more of SQL92. I would
recommend sticking to an SQL92-like syntax, in which FROM/IN is not
optional if direction and/or how_many appear.
The reason I'm concerned about this is that all of the direction and
howmany keywords are considered valid ColIds (and if we take them out
of the ColIds list, we risk breaking databases that work at present).
That means that the parser has some difficulty in figuring out whether
an apparent keyword is really a keyword, or a portal name that happens
to be the same as a keyword. For example, consider
FETCH NEXT;
If both FROM and portal_name were optional, this statement would
actually be ambiguous: is it FETCH NEXT from the default portal,
or FETCH with default options from a cursor named NEXT?
In the syntax you are proposing, this statement is valid and not
ambiguous --- NEXT must be a cursor name --- but the only way an
LR(1) parser can figure that out is to look ahead one token to see
that semicolon comes next.
What I'm concerned about is that SQL92 allows other options *after*
the cursor name, and we may someday want to support those. We could
easily find that the grammar is no longer LR(1) (ie, it takes more than
one token lookahead to decide whether we have the portal name or not);
and then we've got trouble. If FROM is required after FETCH options
then this risk is much reduced.
Another reason for requiring FROM/IN is that we will not be able to
expand the "FETCH n" syntax for how_many to handle a more general
expression (as opposed to a bare signed-integer constant, as we have
now) unless there is a delimiter between it and the portal name.
We still have unresolved headaches in the grammar that come from the
lack of delimiters around constant expressions in column DEFAULT
options; let's not add another source of the same kind of trouble.
In short, the syntax
FETCH [ [ direction ] [ how_many ] FROM/IN ] portal_name
poses much less risk for future expansion than the syntax
FETCH [ direction ] [ how_many ] [ FROM/IN ] portal_name
and that's why I think we'd be safer to stick with the former.
regards, tom lane
From bouncefilter Thu Jan 13 11:40:55 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA41080
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 11:40:42 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA12952;
Thu, 13 Jan 2000 11:40:32 -0500 (EST)
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] Re: Regress tests reveal *serious* psql bug
In-reply-to:
<219F68D65015D011A8E000006F8590C603FDC200@sdexcsrv1.f000.d0188.sd.spardat.at>
References:
<219F68D65015D011A8E000006F8590C603FDC200@sdexcsrv1.f000.d0188.sd.spardat.at>
Comments: In-reply-to Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
message dated "Thu, 13 Jan 2000 10:33:43 +0100"
Date: Thu, 13 Jan 2000 11:40:32 -0500
Message-ID: <12949.947781632@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
Why was the ":" used in the first place ? I would expect to use a ','
for an array slice. No ?
I'd think a comma is a separator between subscripts for different
dimensions, ie, a[1,2] would be equivalent to a[1][2]. It'd
certainly surprise *me* if it were interpreted as a slice indicator.
In any case, we're stuck with the notation now, I fear.
regards, tom lane
From bouncefilter Thu Jan 13 11:42:56 2000
Received: from cap-ferrat.albourne.com (cap-ferrat.albourne.com
[195.89.178.227]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA41358
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 11:42:36 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (bishop-rock.albourne.com [195.89.178.230])
by cap-ferrat.albourne.com (8.9.3/8.9.3/Albourne/UKS/2.9/MAPS) with
ESMTP id QAA15778; Thu, 13 Jan 2000 16:42:25 GMT
Sender: a.joubert@albourne.com
Message-ID: <387E0077.2F6D206C@albourne.com>
Date: Thu, 13 Jan 2000 16:42:31 +0000
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
CC: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] Re: Regress tests reveal *serious* psql bug
References:
<219F68D65015D011A8E000006F8590C603FDC200@sdexcsrv1.f000.d0188.sd.spardat.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Zeugswetter Andreas SB wrote:
SELECT arrtest.a[1:3],
arrtest.b[1:1][1:2][1:2],
arrtest.c[1:2],
arrtest.d[1:1][1:2]
FROM arrtest;Sorry for the stupid question, but can sombody enlighten me.
Why was the ":" used in the first place ? I would expect to use a ','
for an array slice. No ?As in: select arrtest.a[1,1][1,2]
(This is also what others use for array slices)
In Fortran 90 (one of the few languages that has true arrays with a size
as well as a shape) arrays are indexed as
A(1:8:2, -2:10)
which would mean the 2D array defined by rows (1,3,5,7) and columns
(-2,...,10). So ',' is commonly used to separate dimensions, and it
would be confusing to suddenly use commas to define a range. And as
Fortran is pretty much the grand-daddy of all programming languages we
can't really go and change that ;-) Putting indexes in separate ['s is
just a modern C'ism, because C has no real multi-dimensional arrays,
only pointer dereferencing.
Adriaan (a Fortran programmer)
From bouncefilter Thu Jan 13 11:50:56 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA42697
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 11:50:48 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA15390;
Thu, 13 Jan 2000 11:47:57 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-reply-to: <200001131557.KAA29869@candle.pha.pa.us>
References: <200001131557.KAA29869@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Thu, 13 Jan 2000 10:57:33 -0500"
Date: Thu, 13 Jan 2000 11:47:56 -0500
Message-ID: <15387.947782076@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
You can't securely do
echo $PASSWORD | backend
or
echo $PASSWORD > allegedly-secure-temp-file
This is secure. echo is a shell builtin, and does not invoke a separate
process with arguments.
echo is a builtin in ksh and derivatives, but I don't think it's safe
to assume it is a builtin everywhere...
regards, tom lane
From bouncefilter Thu Jan 13 12:00:56 2000
Received: from alert.infoplease.com ([208.222.166.25])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA44809
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 12:00:34 -0500 (EST)
(envelope-from kdebisschop@range.infoplease.com)
Received: from skillet.infoplease.com (skillet [10.0.1.212])
by alert.infoplease.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14372;
Thu, 13 Jan 2000 11:58:23 -0500 (EST)
Received: (from kdebisschop@localhost)
by skillet.infoplease.com (8.9.3/8.9.1) id LAA22497;
Thu, 13 Jan 2000 11:58:26 -0500
Date: Thu, 13 Jan 2000 11:58:26 -0500
Message-Id: <200001131658.LAA22497@skillet.infoplease.com>
X-Authentication-Warning: skillet.infoplease.com: kdebisschop set sender to
kdebisschop@spaceheater.infoplease.com using -f
From: Karl DeBisschop <kdebisschop@range.infoplease.com>
To: tgl@sss.pgh.pa.us
CC: pgman@candle.pha.pa.us, peter_e@gmx.net, scrappy@hub.org,
pgsql-hackers@postgresql.org
In-reply-to: <12671.947778315@sss.pgh.pa.us> (message from Tom Lane on Thu, 13
Jan 2000 10:45:15 -0500)
Subject: Re: [HACKERS] TODO list updated
Reply-to: kdebisschop@range.infoplease.com
References: <200001131315.IAA25149@candle.pha.pa.us>
<12671.947778315@sss.pgh.pa.us>
What I am starting to think is that we do need a C program. However,
it could be very small; it shouldn't try to do all of what initdb does.
All it needs to do is fetch the password from stdin and then echo it
to stdout in an ALTER USER command. The invocation in initdb would
look something likesecurepassword $SUPERUSERNAME | standalone-backend ...
and the code would be on the order of
fprintf(stderr, "Please enter password for %s: ", argv[1]);
fgets(stdin, password);
printf("ALTER USER %s PASSWORD '%s'\n", argv[1], password);
Why not something like:
#include <libpq-fe.h>
char *pghost;
char *pgport;
char *pgoptions;
char *pgtty;
char *dbName;
char *user;
char *password;
char *query;
PGconn *conn;
PGresult *res;
fprintf(stderr, "Please enter password for %s: ", argv[1]);
fgets(stdin, password);
pgoptions = NULL; /* special options to start up the backend server */
pgtty = NULL; /* debugging tty for the backend server */
conn = PQsetdb(pghost, pgport, pgoptions, pgtty, dbName);
sprintf(query,"ALTER USER postgres SET PASSWORD='%s'",password)
PGresult= PQexec(conn,query);
PQfinish(conn);
--
Karl DeBisschop <kdebisschop@alert.infoplease.com>
617.832.0332 (Fax: 617.956.2696)
Information Please - your source for FREE online reference
http://www.infoplease.com - Your Ultimate Fact Finder
http://kids.infoplease.com - The Great Homework Helper
Netsaint Plugins Development
http://netsaintplug.sourceforge.net
From bouncefilter Thu Jan 13 11:59:56 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA43879
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 11:58:59 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA15425;
Thu, 13 Jan 2000 11:58:34 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: initdb (Re: [HACKERS] TODO list updated)
In-reply-to: <Pine.GSO.4.02A.10001131653240.6438-100000@Pingvin.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10001131653240.6438-100000@Pingvin.DoCS.UU.SE>
Comments: In-reply-to Peter Eisentraut <e99re41@DoCS.UU.SE>
message dated "Thu, 13 Jan 2000 17:02:14 +0100"
Date: Thu, 13 Jan 2000 11:58:34 -0500
Message-ID: <15422.947782714@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
What I had been phantasizing about is an initdb completely in C that
a) eliminates all shell incompatibilities
b) doesn't depend on the grace of external utilities
These apparent advantages won't really be realized unless you propose
to replace *all* our shell-scripts with C; so I'm not persuaded by those
arguments. However
c) doesn't need any external files
The implemenation idea behind c) was to include all the catalog/*.h files
directly, having changed the DATA() and DESC() macros prior, thus
eliminating the need for .bki files, genbki.sh (which fortunately hadn't
had any compatibility problems), another set of files being installed that
you don't really need at runtime.
is very attractive indeed --- it'd eliminate the risk of incompatibility
between genbki's interpretation of the catalog .h files and the C
compiler's interpretation thereof, as well as give us more flexibility
in what we put in the .h files. (For example, I just finished hacking
up genbki.sh to interpret "INDEX_MAX_KEYS*2" and "INDEX_MAX_KEYS*4"
correctly. If we ever go to 8-byte oids, that code will need fixed
again. Whole problem goes away if the tables are processed by the C
compiler...)
What I'd be inclined to think about is a compromise: leave initdb as
mostly a shell script, but replace genbki.sh and the lib template files
with something that compiles up tables equivalent to the template files
and when invoked spits out bootstrapping commands on its stdout. It'd
be very easy to test: diff its output against the existing template files.
Also you wouldn't need pg_version or pg_encoding which implies you don't
need libpq, which means you don't need to set LD_LIBRARY_PATH.
Again, not very interesting, since you won't get far until you have
made libpq.so accessible...
regards, tom lane
From bouncefilter Thu Jan 13 12:11:56 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA49410
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 12:11:22 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA15473;
Thu, 13 Jan 2000 12:10:29 -0500 (EST)
To: kdebisschop@range.infoplease.com
cc: pgman@candle.pha.pa.us, peter_e@gmx.net, scrappy@hub.org,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] TODO list updated
In-reply-to: <200001131658.LAA22497@skillet.infoplease.com>
References: <200001131315.IAA25149@candle.pha.pa.us>
<12671.947778315@sss.pgh.pa.us>
<200001131658.LAA22497@skillet.infoplease.com>
Comments: In-reply-to Karl DeBisschop <kdebisschop@range.infoplease.com>
message dated "Thu, 13 Jan 2000 11:58:26 -0500"
Date: Thu, 13 Jan 2000 12:10:29 -0500
Message-ID: <15470.947783429@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Karl DeBisschop <kdebisschop@range.infoplease.com> writes:
What I am starting to think is that we do need a C program. However,
it could be very small; it shouldn't try to do all of what initdb does.
Why not something like:
[ fire up a postmaster and send it an ALTER USER command ]
That's got a race condition: at the time you start the postmaster,
the postgres superuser hasn't got a password. A bad guy could get
in there and set the password the way *he* wanted it, or less
detectably: just connect as postgres, wait for you to set the password,
then read it out (he's still connected as postgres and still has
superuser rights...)
If we thought that was acceptable, the whole issue of setting the
password in initdb (rather than doing it manually later on) wouldn't
be on the table. The idea is to have a password in place *before*
opening the store.
If Bruce is correct that 'echo' is a shell builtin on all shells,
then
echo "ALTER USER ..." | standalone-backend
seems like a sufficient solution. I am a little concerned about
that "if", but it may be a close-enough answer.
regards, tom lane
From bouncefilter Thu Jan 13 12:20:56 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA50786
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 12:20:08 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id NAA77183;
Thu, 13 Jan 2000 13:18:11 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 13 Jan 2000 13:18:11 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <15387.947782076@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001131317350.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
You can't securely do
echo $PASSWORD | backend
or
echo $PASSWORD > allegedly-secure-temp-fileThis is secure. echo is a shell builtin, and does not invoke a separate
process with arguments.echo is a builtin in ksh and derivatives, but I don't think it's safe
to assume it is a builtin everywhere...
bash-2.03$ which echo
/usr/slocal/bin/echo
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 13 12:27:56 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA51774
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 12:27:16 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA02514;
Thu, 13 Jan 2000 12:22:24 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001131722.MAA02514@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <15387.947782076@sss.pgh.pa.us> from Tom Lane at "Jan 13,
2000 11:47:56 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 13 Jan 2000 12:22:23 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
You can't securely do
echo $PASSWORD | backend
or
echo $PASSWORD > allegedly-secure-temp-fileThis is secure. echo is a shell builtin, and does not invoke a separate
process with arguments.echo is a builtin in ksh and derivatives, but I don't think it's safe
to assume it is a builtin everywhere...
I believe it is safe. csh and sh have it built in. Does anyone know of
a shell that does not have echo builtin? How do you tell? Not sure.
--
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 Jan 13 12:36:56 2000
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 MAA56743
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 12:35:56 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA02639;
Thu, 13 Jan 2000 12:25:21 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001131725.MAA02639@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list updated
In-Reply-To: <Pine.BSF.4.21.0001131317350.46499-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 13, 2000 01:18:11 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Thu, 13 Jan 2000 12:25:21 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Thu, 13 Jan 2000, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
You can't securely do
echo $PASSWORD | backend
or
echo $PASSWORD > allegedly-secure-temp-fileThis is secure. echo is a shell builtin, and does not invoke a separate
process with arguments.echo is a builtin in ksh and derivatives, but I don't think it's safe
to assume it is a builtin everywhere...bash-2.03$ which echo
/usr/slocal/bin/echo
which is an external program looking for another external program. From
bash:
#$ type echo
echo is a shell builtin
#$ which which
/usr/bin/which
--
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 Jan 13 12:36:58 2000
Received: from alert.infoplease.com ([208.222.166.25])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA56766
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 12:36:03 -0500 (EST)
(envelope-from kdebisschop@range.infoplease.com)
Received: from skillet.infoplease.com (skillet [10.0.1.212])
by alert.infoplease.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16054;
Thu, 13 Jan 2000 12:33:14 -0500 (EST)
Received: (from kdebisschop@localhost)
by skillet.infoplease.com (8.9.3/8.9.1) id MAA23568;
Thu, 13 Jan 2000 12:33:17 -0500
Date: Thu, 13 Jan 2000 12:33:17 -0500
Message-Id: <200001131733.MAA23568@skillet.infoplease.com>
X-Authentication-Warning: skillet.infoplease.com: kdebisschop set sender to
kdebisschop@spaceheater.infoplease.com using -f
From: Karl DeBisschop <kdebisschop@range.infoplease.com>
To: tgl@sss.pgh.pa.us
CC: pgman@candle.pha.pa.us, peter_e@gmx.net, scrappy@hub.org,
pgsql-hackers@postgresql.org
In-reply-to: <15470.947783429@sss.pgh.pa.us> (message from Tom Lane on Thu, 13
Jan 2000 12:10:29 -0500)
Subject: Re: [HACKERS] TODO list updated
Reply-to: kdebisschop@range.infoplease.com
References: <200001131315.IAA25149@candle.pha.pa.us>
<12671.947778315@sss.pgh.pa.us>
<200001131658.LAA22497@skillet.infoplease.com>
<15470.947783429@sss.pgh.pa.us>
That's got a race condition: at the time you start the postmaster,
the postgres superuser hasn't got a password. A bad guy could get
in there and set the password the way *he* wanted it
Or could `echo "ALTER USER ..." | standalone-backend` to the backend
-- isn't that still a race condition?
or less detectably: just connect as postgres, wait for you to set the
password, then read it out (he's still connected as postgres and
still has superuser rights...)
Or connect to the stanadalone backend, and create a trigger on ALTER
USER... to print the command to a file. Seems like echo doesn't solve
this vulnerablilty either.
Obviously I'm pretty naive here, so I'll just shut up after this. But
from what I know of how these parts all work together, the echo
approach has the same problems, but maybe to a somewaht smaller degree.
And even if echo is a builtin in all shells, an alias will override
the builtin, at least in bash. So if you machine has been penetrated
to the point where the above race condition comes into play, you also
cannot trust echo.
Just my $0.02 worth.
--
Karl DeBisschop <kdebisschop@alert.infoplease.com>
617.832.0332 (Fax: 617.956.2696)
Information Please - your source for FREE online reference
http://www.infoplease.com - Your Ultimate Fact Finder
http://kids.infoplease.com - The Great Homework Helper
Netsaint Plugins Development
http://netsaintplug.sourceforge.net
From bouncefilter Thu Jan 13 12:43:56 2000
Received: from alert.infoplease.com ([208.222.166.25])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA58120
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 12:43:48 -0500 (EST)
(envelope-from kdebisschop@range.infoplease.com)
Received: from skillet.infoplease.com (skillet [10.0.1.212])
by alert.infoplease.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16299;
Thu, 13 Jan 2000 12:42:13 -0500 (EST)
Received: (from kdebisschop@localhost)
by skillet.infoplease.com (8.9.3/8.9.1) id MAA23842;
Thu, 13 Jan 2000 12:42:16 -0500
Date: Thu, 13 Jan 2000 12:42:16 -0500
Message-Id: <200001131742.MAA23842@skillet.infoplease.com>
X-Authentication-Warning: skillet.infoplease.com: kdebisschop set sender to
kdebisschop@spaceheater.infoplease.com using -f
From: Karl DeBisschop <kdebisschop@range.infoplease.com>
To: scrappy@hub.org
CC: tgl@sss.pgh.pa.us, pgman@candle.pha.pa.us, peter_e@gmx.net,
pgsql-hackers@postgreSQL.org
In-reply-to: <Pine.BSF.4.21.0001131317350.46499-100000@thelab.hub.org>
(message from The Hermit Hacker on Thu, 13 Jan 2000 13:18:11 -0400
(AST))
Subject: Re: [HACKERS] TODO list updated
Reply-to: kdebisschop@range.infoplease.com
References: <Pine.BSF.4.21.0001131317350.46499-100000@thelab.hub.org>
bash-2.03$ which echo
/usr/slocal/bin/echo
I don't think that test has bearing on whether echo is builtin.
Consider the following:
skillet.infoplease.com:/u/kdebisschop> export PATH=.:$PATH
skillet.infoplease.com:/u/kdebisschop> which echo
/usr/bin/echo
skillet.infoplease.com:/u/kdebisschop> echo '#!/bin/echo trap door'>./echo
skillet.infoplease.com:/u/kdebisschop> chmod +x echo
skillet.infoplease.com:/u/kdebisschop> which echo
/disk/1/home/kdebisschop/echo
skillet.infoplease.com:/u/kdebisschop> ./echo foo
trap door ./echo foo
skillet.infoplease.com:/u/kdebisschop> echo foo
foo
So bash is using the builtin, but which shows the script.
BUT, for aliases (this is a totally separate shell, BTW):
skillet.infoplease.com:/u/kdebisschop> alias echo='echo tarp door'
skillet.infoplease.com:/u/kdebisschop> echo foo
tarp door foo
skillet.infoplease.com:/u/kdebisschop> which echo
/usr/bin/echo
--
Karl DeBisschop <kdebisschop@alert.infoplease.com>
617.832.0332 (Fax: 617.956.2696)
Information Please - your source for FREE online reference
http://www.infoplease.com - Your Ultimate Fact Finder
http://kids.infoplease.com - The Great Homework Helper
Netsaint Plugins Development
http://netsaintplug.sourceforge.net
From bouncefilter Thu Jan 13 13:30:57 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA70428
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 13:30:01 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA16241;
Thu, 13 Jan 2000 13:29:11 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, The Hermit Hacker <scrappy@hub.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] TODO list updated
In-reply-to: <200001131722.MAA02514@candle.pha.pa.us>
References: <200001131722.MAA02514@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Thu, 13 Jan 2000 12:22:23 -0500"
Date: Thu, 13 Jan 2000 13:29:11 -0500
Message-ID: <16238.947788151@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
echo is a builtin in ksh and derivatives, but I don't think it's safe
to assume it is a builtin everywhere...
I believe it is safe. csh and sh have it built in. Does anyone know of
a shell that does not have echo builtin? How do you tell? Not sure.
I looked at the man pages for plain old Bourne shell on the oldest
systems I have access to (SunOS 4.1.4 and HPUX 9). They all say that
echo is a builtin. So I guess it's probably safe enough. There may
be a few hoary old machines where
echo "ALTER USER ... $password ..." | backend
is a security risk, but it seems like it should be a very minimal
problem. (Especially since even a non-builtin echo should be a live
process for only a *really* short interval, even if the backend takes
longer to process the command.)
regards, tom lane
From bouncefilter Thu Jan 13 13:23:57 2000
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 NAA69450
for <pgsql-hackers@hub.org>; Thu, 13 Jan 2000 13:23:30 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63668 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S315392AbQAMSXD>;
Thu, 13 Jan 2000 19:23:03 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 128p0Y-0000ei-00; Thu, 13 Jan 2000 19:30:06 +0100
Date: Thu, 13 Jan 2000 19:30:06 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Michael Robinson <robinson@netrinsics.com>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] Copy from/to asymmetry
In-Reply-To: <200001121821.CAA76248@netrinsics.com>
Message-ID: <Pine.LNX.4.21.0001130046300.1646-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-13, Michael Robinson mentioned:
2. psql should exit with an error status if it receives a fatal error
from the backend and isatty(0) is false.
This is already accomplished in the current sources.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 13 13:40:57 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA75429
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 13:40:27 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA16272;
Thu, 13 Jan 2000 13:38:23 -0500 (EST)
To: kdebisschop@range.infoplease.com
cc: pgman@candle.pha.pa.us, peter_e@gmx.net, scrappy@hub.org,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] TODO list updated
In-reply-to: <200001131733.MAA23568@skillet.infoplease.com>
References: <200001131315.IAA25149@candle.pha.pa.us>
<12671.947778315@sss.pgh.pa.us>
<200001131658.LAA22497@skillet.infoplease.com>
<15470.947783429@sss.pgh.pa.us>
<200001131733.MAA23568@skillet.infoplease.com>
Comments: In-reply-to Karl DeBisschop <kdebisschop@range.infoplease.com>
message dated "Thu, 13 Jan 2000 12:33:17 -0500"
Date: Thu, 13 Jan 2000 13:38:23 -0500
Message-ID: <16269.947788703@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Karl DeBisschop <kdebisschop@range.infoplease.com> writes:
That's got a race condition: at the time you start the postmaster,
the postgres superuser hasn't got a password. A bad guy could get
in there and set the password the way *he* wanted it
Or could `echo "ALTER USER ..." | standalone-backend` to the backend
-- isn't that still a race condition?
No, not unless he's already either root or postgres. Ordinary other
users can't run a standalone backend in your database (that's one reason
why the toplevel data directory must always have permissions 700).
And even if echo is a builtin in all shells, an alias will override
the builtin, at least in bash. So if you machine has been penetrated
to the point where the above race condition comes into play, you also
cannot trust echo.
Again, if the attacker has already managed to modify your .profile,
then you've lost the game. What we're concerned about here is other
users on your machine or any of the machines that your pg_hba file
allows connections from. Running ps while you are doing initdb, for
example, doesn't require any special preconditions beyond a regular
user account on the same machine you are on.
regards, tom lane
From bouncefilter Thu Jan 13 14:48:58 2000
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 OAA92615
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 14:48:15 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id OAA07600;
Thu, 13 Jan 2000 14:48:02 -0500
Message-ID: <387E2BE9.6658C6FD@wgcr.org>
Date: Thu, 13 Jan 2000 14:47:54 -0500
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 <pgman@candle.pha.pa.us>
CC: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] TODO list updated
References: <200001122350.SAA21120@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
* Make postgres user have a password by default
There's an initdb switch.
OK, now we have to decide if we are going to require this be done as
part of initdb. I am inclined to say the user _has_ to be _prompted_ in
a secure matter for the password as part of initdb. Have a command-line
switch for the password is not secure, IMHO, though it is better than
nothing.
Let's get people's opinions on this, and we can mark it as done.
As a packager, and a user, I would like the _option_ of setting a
default password using a --prompt-for-password switch.
By all means don't make it default to prompting for a password -- there
are those who do not need a password on the database superuser account,
due to other security measures and connection models (IE, backing a
webserver that is handling authentication and pooling connections under
a single (nonprivileged) user).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Thu Jan 13 17:15:04 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA31528
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 17:14:52 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max05-058.enterprise.net
[194.72.197.58])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id WAA15336;
Thu, 13 Jan 2000 22:14:49 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id WAA24994;
Thu, 13 Jan 2000 22:14:39 GMT
Message-Id: <200001132214.WAA24994@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgreSQL.org
Subject: Problem with foreign keys and inheritance
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 13 Jan 2000 22:14:39 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
[Version: CVS as of yesterday]
When I create a table that inherits from another table that uses foreign
keys, I get something like this:
ERROR: cache lookup of attribute 10 in relation 124171 failed
This is happening in get_attribute_name() of backend/utils/adt/ruleutils.c
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"For the LORD is good; his mercy is everlasting; and
his truth endureth to all generations."
Psalms 100:5
From bouncefilter Thu Jan 13 23:18:07 2000
Received: from pcr.ca (www.pcr.ca [207.139.158.13] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id XAA29946
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 23:17:06 -0500 (EST)
(envelope-from admin@wtbwts.com)
Received: by pcr.ca (Postfix, from userid 1000)
id 62AC91FE8; Thu, 13 Jan 2000 23:16:04 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1])
by pcr.ca (Postfix) with ESMTP id 4E74C1F8C
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 23:16:04 +0000 (GMT)
Date: Thu, 13 Jan 2000 23:16:04 +0000 (GMT)
From: admin <admin@wtbwts.com>
X-Sender: admin@server.b0x.com
To: pgsql-hackers@postgresql.org
Subject: SPI_fnumber can't see oid
Message-ID: <Pine.BSF.4.10.10001132307050.75240-100000@server.b0x.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
It seems SPI_fnumber can't recognize oid as an attribute for a tuple
description. I performed my tests using contrib/spi/refint.c which uses
function to test the validity of the trigger for check_foreign_key() and
for check_primary_key(). I changed refint.c slightly to verify that
SPI_fnumber was really returning SPI_ERROR_NOATTRIBUTE and indeed it was.
Here's the exact line I got from the check_foreign_key trigger:
ERROR: check_foreign_key: there is no attribute oid in relation product
Looking at src/backend/executor/spi.c, I noticed SPI_fnumber started
counting at 0. Is this normal or should it be -1, assuming oid might be
just before 0?
Let me know what you think,
Marc
From bouncefilter Thu Jan 13 19:47:03 2000
Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA77518
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 19:46:55 -0500 (EST) (envelope-from xun@cs.ucsb.edu)
Received: from brubeck.cs.ucsb.edu (brubeck [128.111.49.47])
by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id QAA25346;
Thu, 13 Jan 2000 16:46:52 -0800 (PST)
Received: by brubeck.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4)
id QAA17082 for ; Thu, 13 Jan 2000 16:46:52 -0800 (PST)
Date: Thu, 13 Jan 2000 16:46:52 -0800 (PST)
From: xun@cs.ucsb.edu (Xun Cheng)
Message-Id: <200001140046.QAA17082@brubeck.cs.ucsb.edu>
To: pgsql-hackers@postgresql.org
Cc: xun@cs.ucsb.edu
Subject: [hackers]development suggestion needed
Hi, everyone, I like your work very much and hope PostgreSQL can
grow into something competitive with Oracle just like Linux vs.
Windows.
I have background in relational database management system
research and I want to try to be a developer for PostgreSQL.
Right now I only try to be familiar with your code base. I
plan to start with a specific function module in the backend.
I'm thinking of /docs/pgsql/src/backend/executor because
I want to experiment with some new fast join algorithms.
My long term objective is to introduce materialized view
subsystem into PostgreSQL. Could anyone tell me if
the directory /docs/pgsql/src/backend/executor is the
right place to start or just give me some general suggestions
which are not in the FAQs? Oh one more thing I want to
mention is that those join algorithms I want to experiment
with may have some special data access paths similar to an index.
Further if it doesn't bother you much, could someone
answer the following question(s) for me? (Sorry if
some are already in the docs)
1. Does postgresql do raw storage device management or it relies
on file system? My impression is no raw device. If no,
is it difficult to add it and possibly how?
2. Do you have standard benchmark results for postgresql?
I guess not since it only implements a subset of SQL'92.
What about subset of a benchmark or something repeatable?
3. Suppose I have added a new two rel. join algorithm, how
would I proceed to compare the performance of it with
the exisiting two relation join algorithms under
different senarios? Are there any existing facilities
in the current code base for this purpose? Am I right
that the available join algos implemented are nested loop
join (including index-based), hash join (which one? hybrid),
sort-merge join?
4. Usually a single sequential pass of a large joining relation
is preferred to random access in large join operation.
It's mostly because of the current disk access characteristics.
Is it possible for me to do some benchmarking about this
using postgresql? What I'm actually asking are the issues about
how to control the flow of data form disk to buffers,
how to stop file system interference and how to arrange
actual data placement on the disk.
Sorry again if I'm not clear with my questions. I'd like
to further explain them if necessary.
thanks for any help
xun
From bouncefilter Thu Jan 13 20:14:06 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA83471
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 20:13:14 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA23412;
Thu, 13 Jan 2000 20:09:40 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001140109.UAA23412@candle.pha.pa.us>
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: <200001140046.QAA17082@brubeck.cs.ucsb.edu> from Xun Cheng at
"Jan
13, 2000 04:46:52 pm"
To: Xun Cheng <xun@cs.ucsb.edu>
Date: Thu, 13 Jan 2000 20:09:40 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have background in relational database management system
research and I want to try to be a developer for PostgreSQL.
Right now I only try to be familiar with your code base. I
plan to start with a specific function module in the backend.
I'm thinking of /docs/pgsql/src/backend/executor because
I want to experiment with some new fast join algorithms.
My long term objective is to introduce materialized view
subsystem into PostgreSQL. Could anyone tell me if
the directory /docs/pgsql/src/backend/executor is the
right place to start or just give me some general suggestions
which are not in the FAQs? Oh one more thing I want to
mention is that those join algorithms I want to experiment
with may have some special data access paths similar to an index.
Good.
Further if it doesn't bother you much, could someone
answer the following question(s) for me? (Sorry if
some are already in the docs)
1. Does postgresql do raw storage device management or it relies
on file system? My impression is no raw device. If no,
is it difficult to add it and possibly how?
No, only file system. We don't see much advantage to raw i/o.
2. Do you have standard benchmark results for postgresql?
I guess not since it only implements a subset of SQL'92.
What about subset of a benchmark or something repeatable?
We do the Wisconsin. I think it is in the source tree.
3. Suppose I have added a new two rel. join algorithm, how
would I proceed to compare the performance of it with
the exisiting two relation join algorithms under
different senarios? Are there any existing facilities
in the current code base for this purpose? Am I right
that the available join algos implemented are nested loop
join (including index-based), hash join (which one? hybrid),
sort-merge join?
You can control the join types used with flags to postgres. Very easy.
4. Usually a single sequential pass of a large joining relation
is preferred to random access in large join operation.
It's mostly because of the current disk access characteristics.
Is it possible for me to do some benchmarking about this
using postgresql? What I'm actually asking are the issues about
how to control the flow of data form disk to buffers,
how to stop file system interference and how to arrange
actual data placement on the disk.
Good idea. We deal with this regularly in deciding to use an index in
the optimizer or a sequential scan. Our optimizer is quite good.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 13 20:24:02 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA84709
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 20:23:47 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA25269;
Thu, 13 Jan 2000 20:23:24 -0500 (EST)
To: xun@cs.ucsb.edu (Xun Cheng)
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-reply-to: <200001140046.QAA17082@brubeck.cs.ucsb.edu>
References: <200001140046.QAA17082@brubeck.cs.ucsb.edu>
Comments: In-reply-to xun@cs.ucsb.edu (Xun Cheng)
message dated "Thu, 13 Jan 2000 16:46:52 -0800"
Date: Thu, 13 Jan 2000 20:23:24 -0500
Message-ID: <25266.947813004@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
xun@cs.ucsb.edu (Xun Cheng) writes:
I want to experiment with some new fast join algorithms.
Cool. Welcome aboard!
Could anyone tell me if
the directory /docs/pgsql/src/backend/executor is the
right place to start
The executor is only half the problem: you must also teach the
planner/optimizer how and when to use the new join type.
Hiroshi Inoue has recently been down this path (adding support
for TID-based scans), and might be able to give you more specific
advice.
1. Does postgresql do raw storage device management or it relies
on file system? My impression is no raw device. If no,
is it difficult to add it and possibly how?
Postgres uses Unix files. We have avoided raw-device access mostly on
grounds of portability. To persuade people that such a change should go
into the distribution, you'd need to prove that *significantly* better
performance is obtained with raw access. I for one don't think it's a
foregone conclusion; Postgres gets considerable benefit from sitting
atop Unix kernel device schedulers and disk buffer caches.
As far as the actual implementation goes, the low level access methods
go through a "storage manager" switch that was intended to allow for
the addition of a new storage manager, such as a raw-device manager.
So you could get a good deal of stuff working by implementing code that
parallels md.c/fd.c. The main problem at this point is that there is a
fair amount of utility code that goes out and does its own manipulation
of the database file structure. You'd need to clean that up by pushing
it all down below the storage manager switch (inventing new storage
manager calls as needed).
that the available join algos implemented are nested loop
join (including index-based), hash join (which one? hybrid),
sort-merge join?
Right. The hash join uses batching if it estimates that the relation
is too large to fit in memory; is that what you call "hybrid"?
4. Usually a single sequential pass of a large joining relation
is preferred to random access in large join operation.
It's mostly because of the current disk access characteristics.
Is it possible for me to do some benchmarking about this
using postgresql? What I'm actually asking are the issues about
how to control the flow of data form disk to buffers,
how to stop file system interference and how to arrange
actual data placement on the disk.
You don't get to do either of the latter two unless you write a
raw-device storage manager --- which'd be a fair amount of work
for what might be little return. Are you convinced that that ought
to be the first thing you work on? I'd be inclined to think about
join algorithms in the abstract, without trying to control physical
disk placement of the data...
regards, tom lane
From bouncefilter Thu Jan 13 20:34:04 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA89056
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 20:33:10 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA25317
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 20:32:51 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Peter opens a can of worms
Date: Thu, 13 Jan 2000 20:32:51 -0500
Message-ID: <25314.947813571@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter E writes (in elog.h):
+ #ifndef __GNUC__
extern void elog(int lev, const char *fmt, ...);
+ #else
+ /* This extension allows gcc to check the format string for consistency with
+ the supplied arguments. */
+ extern void elog(int lev, const char *fmt, ...) __attribute__ ((format (printf
, 2, 3)));
+ #endifCool. Now who's going to fix the cartload of warnings this has
produced? I'm counting about 125 of them. They should be fixed,
on grounds of portability, but the main problem right now is that
it's difficult to see the *real* warnings because of all these
guys...
regards, tom lane
From bouncefilter Thu Jan 13 20:47:04 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA90838
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 20:46:11 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id RAA16405;
Thu, 13 Jan 2000 17:45:40 -0800 (PST)
Message-Id: <3.0.1.32.20000113174339.01078360@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 13 Jan 2000 17:43:39 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, xun@cs.ucsb.edu (Xun Cheng)
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <25266.947813004@sss.pgh.pa.us>
References: <200001140046.QAA17082@brubeck.cs.ucsb.edu>
<200001140046.QAA17082@brubeck.cs.ucsb.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 08:23 PM 1/13/00 -0500, Tom Lane wrote:
As far as the actual implementation goes, the low level access methods
go through a "storage manager" switch that was intended to allow for
the addition of a new storage manager, such as a raw-device manager.
So you could get a good deal of stuff working by implementing code that
parallels md.c/fd.c. The main problem at this point is that there is a
fair amount of utility code that goes out and does its own manipulation
of the database file structure. You'd need to clean that up by pushing
it all down below the storage manager switch (inventing new storage
manager calls as needed).
This would need to be done to implement some sort of tablespace-style
facility, too, right? I'm off Xun's thread in asking but I've been
wondering. DBs like Oracle allow you to place tables and indices
whereever you like in the filesystem. This is normally done to
distribute things across different spindles, and in large, busy
databases makes a significant difference. I've done some experimenting
moving index files to a different spindle (using "ln" to fool
postgres, of course) and insertions go measurably faster. Spindles
are so cheap nowadays :)
I know there's been discussion of letting folks specify where the
WAL will be placed when it's implemented, for safety's sake - it
will also improve performance.
You don't get to do either of the latter two unless you write a
raw-device storage manager
Not within a single filesystem, but scattering things across spindles
could be done without a raw-device storage manager :)
(not what he's talking about, but heck, thought I'd raise it)
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 13 20:48:02 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA90954
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 20:47:08 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA26391;
Thu, 13 Jan 2000 20:47:05 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Many regress tests failing due to latest psql changes
Date: Thu, 13 Jan 2000 20:47:05 -0500
Message-ID: <26388.947814425@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
It looks like the latest psql has a buffer-flush-timing problem.
Error messages are appearing out-of-sync with script echoing,
for example:
*** expected/boolean.out Sat Jan 8 19:31:26 2000
--- results/boolean.out Thu Jan 13 20:41:24 2000
***************
*** 111,118 ****
-- This is now an invalid expression
-- For pre-v6.3 this evaluated to false - thomas 1997-10-23
INSERT INTO BOOLTBL2 (f1)
- VALUES (bool 'XXX');
ERROR: Bad boolean external representation 'XXX'
-- BOOLTBL2 should be full of false's at this point
SELECT '' AS f_4, BOOLTBL2.*;
f_4 | f1
--- 111,118 ----
-- This is now an invalid expression
-- For pre-v6.3 this evaluated to false - thomas 1997-10-23
INSERT INTO BOOLTBL2 (f1)
ERROR: Bad boolean external representation 'XXX'
+ VALUES (bool 'XXX');
-- BOOLTBL2 should be full of false's at this point
SELECT '' AS f_4, BOOLTBL2.*;
f_4 | f1 This is making it difficult to look for actual backend bugs,
so I respectfully request a fix ASAP.
regards, tom lane
From bouncefilter Thu Jan 13 20:57:07 2000
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 UAA92042
for <hackers@postgreSQL.org>; Thu, 13 Jan 2000 20:56:22 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA02669;
Fri, 14 Jan 2000 10:56:18 +0900 (JST)
Received: from localhost (IDENT:t-ishii@srapc968-yotsuya [133.137.36.133])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA21133;
Fri, 14 Jan 2000 10:56:17 +0900
To: peter_e@gmx.net, e99re41@DoCS.UU.SE
Cc: hackers@postgreSQL.org, t-ishii@sra.co.jp
Subject: Re: [HACKERS] --enable-multibyte
In-Reply-To: <Pine.GSO.4.02A.10001131224190.6438-100000@Pingvin.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10001131224190.6438-100000@Pingvin.DoCS.UU.SE>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000114105726K.t-ishii@sra.co.jp>
Date: Fri, 14 Jan 2000 10:57:26 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 14
Peter,
* If you configure with --enable-multibyte then you build a server and
clients that are multibyte enabled (as defined by the MULTIBYTE symbol).
If you don't use multibyte functionality then nothing will change, so this
would be the preferred option for package maintainers.
This actually would mean that the default encoding is set to
SQL_ASCII, I guess. Since the encoding column in pg_database must be
filled with some value, we need to pick up a default value for it
anyway. Any encoding could be a candidate for the default, probably
SQL_ASCII is a good choice, IMHO.
--
Tatsuo Ishii
From bouncefilter Thu Jan 13 21:02:02 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA96198
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 21:01:44 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA26432;
Thu, 13 Jan 2000 21:01:38 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: xun@cs.ucsb.edu (Xun Cheng), pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-reply-to: <3.0.1.32.20000113174339.01078360@mail.pacifier.com>
References: <200001140046.QAA17082@brubeck.cs.ucsb.edu>
<200001140046.QAA17082@brubeck.cs.ucsb.edu>
<3.0.1.32.20000113174339.01078360@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Thu, 13 Jan 2000 17:43:39 -0800"
Date: Thu, 13 Jan 2000 21:01:37 -0500
Message-ID: <26429.947815297@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Don Baccus <dhogaza@pacifier.com> writes:
This would need to be done to implement some sort of tablespace-style
facility, too, right? I'm off Xun's thread in asking but I've been
wondering. DBs like Oracle allow you to place tables and indices
whereever you like in the filesystem. This is normally done to
distribute things across different spindles, and in large, busy
databases makes a significant difference. I've done some experimenting
moving index files to a different spindle (using "ln" to fool
postgres, of course) and insertions go measurably faster. Spindles
are so cheap nowadays :)
As you say, you can fake it manually with symbolic links, but that's
a kluge.
The "database location" stuff that Peter and Thomas have been arguing
about is intended to allow a single postmaster to control databases that
are in multiple physical locations --- but there seems to be some debate
as to whether it works ;-). (I never tried it.) In any case, we don't
currently have any official provision for controlling location at finer
than database level. It'd be nice to be able to push individual tables
around, I suppose.
This wouldn't require a new storage manager, since presumably you'd
still be using the Unix-filesystem storage manager. The trick would be
to allow a path rather than just a base file name to be specified
per-relation. I'm not sure if it'd be hard or not. Probably, all the
system tables would have to stay in the database's default directory,
but maybe user tables could be given path names without too much
trouble...
regards, tom lane
From bouncefilter Thu Jan 13 21:11:02 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA97431
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 21:10:46 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA27173
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 21:10:30 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Re: Peter opens a can of worms
In-reply-to: <25314.947813571@sss.pgh.pa.us>
References: <25314.947813571@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
message dated "Thu, 13 Jan 2000 20:32:51 -0500"
Date: Thu, 13 Jan 2000 21:10:30 -0500
Message-ID: <27170.947815830@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I wrote:
Cool. Now who's going to fix the cartload of warnings this has
produced? I'm counting about 125 of them.
On further investigation, it seems that some of these warnings are
real portability issues (pointers being printed as ints, etc).
But a very considerable fraction are bogus. gcc doesn't know about
elog's "%m" extension to the standard %-format set, and it seems to
be assuming that there should be a parameter to go with the %m.
I have a feeling we will have to revert this change...
regards, tom lane
From bouncefilter Thu Jan 13 21:23:02 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA98812
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 21:22:34 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id SAA28410;
Thu, 13 Jan 2000 18:21:41 -0800 (PST)
Message-Id: <3.0.1.32.20000113181933.010771d0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 13 Jan 2000 18:19:33 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed
Cc: xun@cs.ucsb.edu (Xun Cheng), pgsql-hackers@postgreSQL.org
In-Reply-To: <26429.947815297@sss.pgh.pa.us>
References: <3.0.1.32.20000113174339.01078360@mail.pacifier.com>
<200001140046.QAA17082@brubeck.cs.ucsb.edu>
<200001140046.QAA17082@brubeck.cs.ucsb.edu>
<3.0.1.32.20000113174339.01078360@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 09:01 PM 1/13/00 -0500, Tom Lane wrote:
As you say, you can fake it manually with symbolic links, but that's
a kluge.
Yes, it is. Or worse :)
The "database location" stuff that Peter and Thomas have been arguing
about is intended to allow a single postmaster to control databases that
are in multiple physical locations --- but there seems to be some debate
as to whether it works ;-). (I never tried it.) In any case, we don't
currently have any official provision for controlling location at finer
than database level. It'd be nice to be able to push individual tables
around, I suppose.
Putting indices on different spindles than the tables is known to
significantly speed up the Ars Digita Community system under load
with Oracle. Systems like this, used to back busy web sites, stuff
things into tables many times a second. As I mentioned, I've played
around a bit with postgres using "ln" and it does indeed help boost
the number of inserts my (paltry, two-spindle) system could sustain.
The selects that such sites spew forth are handled wonderfully
by Postgres now, with MVCC and the change that stops the update
of pg_log after read-only selects.
My site's still in the experimental stage, being used by a couple
dozen folks to record bird distribution data in the Pacific NW, so
I don't personally have real-world data to get a feeling for how
important this might become. Still, Oracle DBA docs talk a lot
about it so in some real-world scenarios being able to distribute
tables and indices on different spindles must pay off.
This wouldn't require a new storage manager, since presumably you'd
still be using the Unix-filesystem storage manager. The trick would be
to allow a path rather than just a base file name to be specified
per-relation. I'm not sure if it'd be hard or not. Probably, all the
system tables would have to stay in the database's default directory,
but maybe user tables could be given path names without too much
trouble...
I've looked into it, actually, and have reached the same conclusion.
Including the bit about keeping system tables in the database's default
directory.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 13 21:38:03 2000
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 VAA04183
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 21:37:45 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA26503;
Thu, 13 Jan 2000 21:20:56 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001140220.VAA26503@candle.pha.pa.us>
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: <3.0.1.32.20000113174339.01078360@mail.pacifier.com> from Don
Baccus at "Jan 13, 2000 05:43:39 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Thu, 13 Jan 2000 21:20:56 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Xun Cheng <xun@cs.ucsb.edu>,
pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
This would need to be done to implement some sort of tablespace-style
facility, too, right? I'm off Xun's thread in asking but I've been
wondering. DBs like Oracle allow you to place tables and indices
whereever you like in the filesystem. This is normally done to
distribute things across different spindles, and in large, busy
databases makes a significant difference. I've done some experimenting
moving index files to a different spindle (using "ln" to fool
postgres, of course) and insertions go measurably faster. Spindles
are so cheap nowadays :)
WAL will add the oid to the base file name. That may make tablespaces
easier.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 13 21:37:04 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA03986
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 21:36:54 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA26708;
Thu, 13 Jan 2000 21:32:44 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001140232.VAA26708@candle.pha.pa.us>
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: <26429.947815297@sss.pgh.pa.us> from Tom Lane at "Jan 13,
2000 09:01:37 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 13 Jan 2000 21:32:44 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>, Xun Cheng <xun@cs.ucsb.edu>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
As you say, you can fake it manually with symbolic links, but that's
a kluge.The "database location" stuff that Peter and Thomas have been arguing
about is intended to allow a single postmaster to control databases that
are in multiple physical locations --- but there seems to be some debate
as to whether it works ;-). (I never tried it.) In any case, we don't
currently have any official provision for controlling location at finer
than database level. It'd be nice to be able to push individual tables
around, I suppose.This wouldn't require a new storage manager, since presumably you'd
still be using the Unix-filesystem storage manager. The trick would be
to allow a path rather than just a base file name to be specified
per-relation. I'm not sure if it'd be hard or not. Probably, all the
system tables would have to stay in the database's default directory,
but maybe user tables could be given path names without too much
trouble...
Or we could continue to use symlinks, and just create them ourselves in
the backend.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 13 21:43:06 2000
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 VAA04712
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 21:42:06 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id LAA11861;
Fri, 14 Jan 2000 11:42:04 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id LAA22129;
Fri, 14 Jan 2000 11:42:03 +0900
To: tgl@sss.pgh.pa.us
Cc: dhogaza@pacifier.com, xun@cs.ucsb.edu, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: Your message of "Thu, 13 Jan 2000 21:01:37 -0500"
<26429.947815297@sss.pgh.pa.us>
References: <26429.947815297@sss.pgh.pa.us>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000114114203R.t-ishii@sra.co.jp>
Date: Fri, 14 Jan 2000 11:42:03 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 44
The "database location" stuff that Peter and Thomas have been arguing
about is intended to allow a single postmaster to control databases that
are in multiple physical locations --- but there seems to be some debate
as to whether it works ;-). (I never tried it.) In any case, we don't
currently have any official provision for controlling location at finer
than database level. It'd be nice to be able to push individual tables
around, I suppose.This wouldn't require a new storage manager, since presumably you'd
still be using the Unix-filesystem storage manager. The trick would be
to allow a path rather than just a base file name to be specified
per-relation. I'm not sure if it'd be hard or not. Probably, all the
system tables would have to stay in the database's default directory,
but maybe user tables could be given path names without too much
trouble...
This is possible since PostgreSQL was born unless I misunderstand what
you are saying...
test=> create table "/tmp/t1" (i int);
CREATE
bash$ ls -l /tmp/t1
-rw------- 1 postgres postgres 0 Jan 14 11:19 /tmp/t1
Even,
test=> create table "../test2/pg_proc" (i int);
ERROR: cannot create ../test2/pg_proc
This is not good. Maybe we should prevent to make this kind of table
names.
BTW, it would be nice to add a "table space" concept to the create
table statement.
-- reserve a table space named 'foo' which is physically located under
-- /pg/myspace. Only PostgreSQL super user can execute this command
-- to avoid security risks.
create table space foo as '/pg/myspace';
-- create table t1 under /pg/myspace
create table t1 (i int) with table space 'foo';
--
Tatsuo Ishii
From bouncefilter Thu Jan 13 22:01:03 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA09335
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 22:00:45 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id SAA10978;
Thu, 13 Jan 2000 18:58:37 -0800 (PST)
Message-Id: <3.0.1.32.20000113185639.01072980@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 13 Jan 2000 18:56:39 -0800
To: Tatsuo Ishii <t-ishii@sra.co.jp>, tgl@sss.pgh.pa.us
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed
Cc: xun@cs.ucsb.edu, pgsql-hackers@postgreSQL.org
In-Reply-To: <20000114114203R.t-ishii@sra.co.jp>
References: <Your message of "Thu,
13 Jan 2000 21:01:37 -0500"<26429.947815297@sss.pgh.pa.us>
<26429.947815297@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:42 AM 1/14/00 +0900, Tatsuo Ishii wrote:
This is possible since PostgreSQL was born unless I misunderstand what
you are saying...test=> create table "/tmp/t1" (i int);
Clever...
Of course, when I'm porting over thousands of lines of an Oracle
data model and tens of thousands of lines of scripting code that
refers to these tables via queries this is a very inconvenient
way to locate a particular table in a particular place. It involves
changing a lot of code...
Besides being somewhat ... baroque? :)
BTW, it would be nice to add a "table space" concept to the create
table statement.
I figured you felt that way!
-- reserve a table space named 'foo' which is physically located under
-- /pg/myspace. Only PostgreSQL super user can execute this command
-- to avoid security risks.
create table space foo as '/pg/myspace';-- create table t1 under /pg/myspace
create table t1 (i int) with table space 'foo';
Yes, that's the Oracle-ish style of it. Of course, Oracle allows
all sorts of anal retentive features like allowing a DBA to
restrict the size of the tablespace, etc that I personally
don't care about...
Though I understand why they're important to some.
Oracle tables and indices within a single tablespace all live in
one file (if you're using filesystem rather than raw I/O), so
they also provide features which allow you to specify how big
a chunk to allocate per extent (Oracle pre-allocates to avoid
running out of disk space while you're running except in ways
that you control, and in hopes of getting contiguous chunks of
disk storage because they hope you're using previously empty
disks used only for Oracle).
Features like this don't fit well with each table/index residing
in its own file. Personally I don't have any need for them, either,
but as Postgres gets more popular (as it will as it continues to
improve) it may attract the attention of folks with traditional
DBA requirements like this.
Of course, that would require a new storage manager, one similar
in concept to what would be needed to implement raw I/O.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 13 22:25:06 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA14927
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 22:24:04 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA28247;
Thu, 13 Jan 2000 22:18:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001140318.WAA28247@candle.pha.pa.us>
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: <3.0.1.32.20000113185639.01072980@mail.pacifier.com> from Don
Baccus at "Jan 13, 2000 06:56:39 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Thu, 13 Jan 2000 22:18:14 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, tgl@sss.pgh.pa.us, xun@cs.ucsb.edu,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Oracle tables and indices within a single tablespace all live in
one file (if you're using filesystem rather than raw I/O), so
they also provide features which allow you to specify how big
a chunk to allocate per extent (Oracle pre-allocates to avoid
running out of disk space while you're running except in ways
that you control, and in hopes of getting contiguous chunks of
disk storage because they hope you're using previously empty
disks used only for Oracle).
And with data and index in the same file, you can't split them across
spindles.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 13 22:50:05 2000
Received: from corvette.mascari.com (dhcp26142035.columbus.rr.com
[24.26.142.35]) by hub.org (8.9.3/8.9.3) with ESMTP id WAA20947
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 22:49:26 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id WAA03456;
Thu, 13 Jan 2000 22:44:46 -0500
Message-ID: <387E9B6C.DE291D54@mascari.com>
Date: Thu, 13 Jan 2000 22:43:41 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Don Baccus <dhogaza@pacifier.com>, Tatsuo Ishii <t-ishii@sra.co.jp>,
tgl@sss.pgh.pa.us, xun@cs.ucsb.edu, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
References: <200001140318.WAA28247@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Oracle tables and indices within a single tablespace all live in
one file (if you're using filesystem rather than raw I/O), so
they also provide features which allow you to specify how big
a chunk to allocate per extent (Oracle pre-allocates to avoid
running out of disk space while you're running except in ways
that you control, and in hopes of getting contiguous chunks of
disk storage because they hope you're using previously empty
disks used only for Oracle).And with data and index in the same file, you can't split them across
spindles.
But you can certainly do that in ORACLE, if you wish. In fact,
ORACLE recommends it:
Place Data Files for Maximum Performance
Tablespace location is determined by the physical location of the
data files that constitute that tablespace. Use the hardware
resources of your computer appropriately.
For example, if several disk drives are available to store the
database, it might be helpful to store table data in a tablespace
on one disk drive, and index data in a tablespace on another disk
drive. This way, when users query table information, both disk
drives can work simultaneously, retrieving table and index data
at the same time.
Mike Mascari
From bouncefilter Thu Jan 13 23:24:08 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA30835
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 23:23:54 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id AAA82407;
Fri, 14 Jan 2000 00:21:23 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 14 Jan 2000 00:21:23 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, Xun Cheng <xun@cs.ucsb.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: <26429.947815297@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001140016150.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Tom Lane wrote:
Don Baccus <dhogaza@pacifier.com> writes:
This would need to be done to implement some sort of tablespace-style
facility, too, right? I'm off Xun's thread in asking but I've been
wondering. DBs like Oracle allow you to place tables and indices
whereever you like in the filesystem. This is normally done to
distribute things across different spindles, and in large, busy
databases makes a significant difference. I've done some experimenting
moving index files to a different spindle (using "ln" to fool
postgres, of course) and insertions go measurably faster. Spindles
are so cheap nowadays :)As you say, you can fake it manually with symbolic links, but that's
a kluge.The "database location" stuff that Peter and Thomas have been arguing
about is intended to allow a single postmaster to control databases that
are in multiple physical locations --- but there seems to be some debate
as to whether it works ;-). (I never tried it.) In any case, we don't
currently have any official provision for controlling location at finer
than database level. It'd be nice to be able to push individual tables
around, I suppose.This wouldn't require a new storage manager, since presumably you'd
still be using the Unix-filesystem storage manager. The trick would be
to allow a path rather than just a base file name to be specified
per-relation. I'm not sure if it'd be hard or not. Probably, all the
system tables would have to stay in the database's default directory,
but maybe user tables could be given path names without too much
trouble...
Okay, I've been thinking about this recently with the whole Udmsearch of
PostgreSQL. We just put a 9gig drive online to handle this, as well as
other database related projects, since I wanted alot of room to grow
(PostgreSQL itself indexed out to something like 1gig, and the lists are
growing) ...
All the major OSs out there have "disk management tools" that allow you to
build "large file systems" out of smaller ones... Solaris has DiskSuite,
FreeBSD has vinum, Linux has ??... why are we looking/investigating adding
a level of complexity to PostgreSQL to handle something that, as far as I
know, each of the OSs out there already has a way of dealing with?
Some aren't necessarily mature yet...Solaris's is the only one that I'm
aware of that has a *beautiful* growfs program that allows you to add a
new drive to an existing "pack" and grow the file system into that new
drive while the system is live...but the utilities are there...
I think the major problem that I'm worried about isn't spreading tables
across drives, but its when that *one* table grows to the point that its
about to overflow my drive...I'd rather add a 9gig drive on, make it an
18gig file system, and let it continue to grow...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 13 23:32:04 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA35347
for <pgsql-hackers@postgresql.org>;
Thu, 13 Jan 2000 23:31:42 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id AAA82476;
Fri, 14 Jan 2000 00:31:30 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 14 Jan 2000 00:31:30 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Xun Cheng <xun@cs.ucsb.edu>,
pgsql-hackers@postgresql.org
Subject: Multiple Spindles ( Was: Re: [HACKERS] [hackers]development
suggestion
needed )
In-Reply-To: <3.0.1.32.20000113181933.010771d0@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0001140022380.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Don Baccus wrote:
My site's still in the experimental stage, being used by a couple
dozen folks to record bird distribution data in the Pacific NW, so
I don't personally have real-world data to get a feeling for how
important this might become. Still, Oracle DBA docs talk a lot
about it so in some real-world scenarios being able to distribute
tables and indices on different spindles must pay off.
What would it take to break the data/base/<database> directory down? To
something like, maybe:
data/base/<database>/pg_*
/tables/*
/indices/*
Then, one could easily mount a drive as /tables and another one as
/indices ...
We know the difference between a table and an index, so I wouldn't think
it would be *too* hard add /tables/ internally to the existing
path...would it?
You'd basically have somethign like:
sprintf("%s/data/base/%s/tables/%s", data_dir, database, tablename);
Instead of:
sprintf("%s/data/base/%s/%s", data_dir, database, tablename);
I know, I'm being simplistic here, but...
Or, a different way:
if(table) sprintf("%s/data/base/table/%s/%s", data_dir,database,tablename);
else if(index) sprintf("%s/data/base/index/%s/%s", data_dir,database,tablename);
else sprintf("%s/data/base/sys/%s/%s", data_dir,database,sysfile);
This would give you the ability to put all table from all databass onto
one file system, and all indexes onto another, and all system files onto a
third...
I don't know, I'm oversimplying and spewing thoughts out
again...but...*shrug*
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 13 23:31:09 2000
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 XAA32577
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 23:30:23 -0500 (EST) (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 NAA00749; Fri, 14 Jan 2000 13:29:13 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tatsuo Ishii" <t-ishii@sra.co.jp>, <tgl@sss.pgh.pa.us>
Cc: <dhogaza@pacifier.com>, <xun@cs.ucsb.edu>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] [hackers]development suggestion needed
Date: Fri, 14 Jan 2000 13:34:45 +0900
Message-ID: <000401bf5e48$aecd2740$2801007e@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: <20000114114203R.t-ishii@sra.co.jp>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tatsuo IshiiBTW, it would be nice to add a "table space" concept to the create
table statement.-- reserve a table space named 'foo' which is physically located under
-- /pg/myspace. Only PostgreSQL super user can execute this command
-- to avoid security risks.
create table space foo as '/pg/myspace';-- create table t1 under /pg/myspace
create table t1 (i int) with table space 'foo';
--
I agree with Tatsuo though I prefer
create table t1 (i int) tablespace foo;
.
Isn't it preferable to encapsulate the table location and storage type ?
At first,a tablespace would only correspond to a directory and it won't
be so difficult to implment. But we would gain a lot with the feature.
In the future,the tablespace may be changed to mean real(??)
tablespace.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Thu Jan 13 23:45:04 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA37981
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 23:44:56 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA29967;
Thu, 13 Jan 2000 23:41:06 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001140441.XAA29967@candle.pha.pa.us>
Subject: Re: Multiple Spindles ( Was: Re: [HACKERS] [hackers]development
suggestion needed )
In-Reply-To: <Pine.BSF.4.21.0001140022380.46499-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 14, 2000 00:31:30 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Thu, 13 Jan 2000 23:41:05 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Xun Cheng <xun@cs.ucsb.edu>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Thu, 13 Jan 2000, Don Baccus wrote:
My site's still in the experimental stage, being used by a couple
dozen folks to record bird distribution data in the Pacific NW, so
I don't personally have real-world data to get a feeling for how
important this might become. Still, Oracle DBA docs talk a lot
about it so in some real-world scenarios being able to distribute
tables and indices on different spindles must pay off.What would it take to break the data/base/<database> directory down? To
something like, maybe:data/base/<database>/pg_*
/tables/*
/indices/*
And put sort and large objects somewhere separate too.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 13 23:45:05 2000
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 XAA37808
for <pgsql-hackers@postgreSQL.org>;
Thu, 13 Jan 2000 23:44:04 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id NAA26128;
Fri, 14 Jan 2000 13:43:50 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id NAA24529;
Fri, 14 Jan 2000 13:43:49 +0900
To: scrappy@hub.org
Cc: tgl@sss.pgh.pa.us, dhogaza@pacifier.com, xun@cs.ucsb.edu,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: Your message of "Fri, 14 Jan 2000 00:21:23 -0400 (AST)"
<Pine.BSF.4.21.0001140016150.46499-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001140016150.46499-100000@thelab.hub.org>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000114134349G.t-ishii@sra.co.jp>
Date: Fri, 14 Jan 2000 13:43:49 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 36
I agree with Tatsuo though I prefer
create table t1 (i int) tablespace foo;
.
Isn't it preferable to encapsulate the table location and storage type ?
Agreed.
At first,a tablespace would only correspond to a directory and it won't
be so difficult to implment. But we would gain a lot with the feature.In the future,the tablespace may be changed to mean real(??)
tablespace.
Good point.
I think the major problem that I'm worried about isn't spreading tables
across drives, but its when that *one* table grows to the point that its
about to overflow my drive...I'd rather add a 9gig drive on, make it an
18gig file system, and let it continue to grow...
We could extend the create tablespace command something like:
create tablespace foo as '/pg/myspace1 /pg/myspace2 ';
to spread a table (space) among different disk drives. Moreover we
could define the "policy" to use the tablespace:
create tablespace foo as '/pg/myspace1 /pg/myspace2 ' policy roundrobin;
in above case, if the table hits the 1GB limit in /pg/myspace1 then
new segment will be created in /pg/myspace2.
Just an idea...
--
Tatsuo Ishii
From bouncefilter Fri Jan 14 00:39:27 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA54437
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 00:38:57 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA02801;
Thu, 13 Jan 2000 21:37:20 -0800 (PST)
Message-Id: <3.0.1.32.20000113205003.01083d50@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 13 Jan 2000 20:50:03 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed
Cc: Tatsuo Ishii <t-ishii@sra.co.jp>, tgl@sss.pgh.pa.us, xun@cs.ucsb.edu,
pgsql-hackers@postgreSQL.org
In-Reply-To: <200001140318.WAA28247@candle.pha.pa.us>
References: <3.0.1.32.20000113185639.01072980@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:18 PM 1/13/00 -0500, Bruce Momjian wrote:
Oracle tables and indices within a single tablespace all live in
one file (if you're using filesystem rather than raw I/O), so
they also provide features which allow you to specify how big
a chunk to allocate per extent (Oracle pre-allocates to avoid
running out of disk space while you're running except in ways
that you control, and in hopes of getting contiguous chunks of
disk storage because they hope you're using previously empty
disks used only for Oracle).And with data and index in the same file, you can't split them across
spindles.
Which is why folks define more than one tablespace, eh? Something
you can't do in PG...
Perhaps I didn't make it clear that you can define as many
tablespaces as you want?
And freely assign any table or index to any tablespace you
want?
Given my statement above, it is clear you can:
1. Coalesce indices and tables into a single tablespace (the
default) if you only define one (again, more or less how
Oracle defaults, though I sorta forget because I'm not an
Oracle stud and no one in their right mind allows Oracle to
set defaults, because they're always wrong)
-or-
2. At the other extreme, you can define as many tablespaces as
you have tables and indices, and each can live in their own
separate tablespace (i.e. spindle, if that is what you want
to do).
-or-
3. Set yourself up at any point between either extreme, according
to your own needs.
I don't think it's that difficult to understand, is it?
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 00:02:24 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA40636
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 00:00:56 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id AAA82717;
Fri, 14 Jan 2000 00:59:08 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 14 Jan 2000 00:59:08 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Xun Cheng <xun@cs.ucsb.edu>, pgsql-hackers@postgreSQL.org
Subject: Re: Multiple Spindles ( Was: Re: [HACKERS] [hackers]development
suggestion needed )
In-Reply-To: <200001140441.XAA29967@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001140048230.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Bruce Momjian wrote:
On Thu, 13 Jan 2000, Don Baccus wrote:
My site's still in the experimental stage, being used by a couple
dozen folks to record bird distribution data in the Pacific NW, so
I don't personally have real-world data to get a feeling for how
important this might become. Still, Oracle DBA docs talk a lot
about it so in some real-world scenarios being able to distribute
tables and indices on different spindles must pay off.What would it take to break the data/base/<database> directory down? To
something like, maybe:data/base/<database>/pg_*
/tables/*
/indices/*And put sort and large objects somewhere separate too.
why not? by default, one drive, it would make no difference except for
file layout, but it would *really* give room to expand...
Right now, the udmsearch database contains (approx):
tables:
10528 dict10
5088 dict11
2608 dict12
3232 dict16
64336 dict2
47960 dict3
3096 dict32
65952 dict4
42944 dict5
36384 dict6
34792 dict7
21008 dict8
14120 dict9
31912 url
indexs:
5216 url_id10
2704 url_id11
1408 url_id12
1648 url_id16
36440 url_id2
27128 url_id3
1032 url_id32
37416 url_id4
22600 url_id5
19096 url_id6
18248 url_id7
10880 url_id8
6920 url_id9
6464 word10
3256 word11
1672 word12
2280 word16
26344 word2
21200 word3
2704 word32
28720 word4
21880 word5
19240 word6
18464 word7
11952 word8
8864 word9
if tables/indexs were in different subdirectories, it would be too easy
for me, at some point in the future, to take just the tables directory and
put them on their own dedicated drive, halving the space used on either
drive...
I don't know...IMHO, it sounds like the simplist solution that provides
the multi-spindle benefits ppl are suggesting...
From bouncefilter Fri Jan 14 00:56:06 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA58347
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 00:55:15 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id AAA07713
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 00:39:15 -0500 (EST)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA02812;
Thu, 13 Jan 2000 21:37:21 -0800 (PST)
Message-Id: <3.0.1.32.20000113210831.01081270@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 13 Jan 2000 21:08:31 -0800
To: Mike Mascari <mascarm@mascari.com>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed
Cc: Tatsuo Ishii <t-ishii@sra.co.jp>, tgl@sss.pgh.pa.us, xun@cs.ucsb.edu,
pgsql-hackers@postgreSQL.org
In-Reply-To: <387E9B6C.DE291D54@mascari.com>
References: <200001140318.WAA28247@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:43 PM 1/13/00 -0500, Mike Mascari wrote:
For example, if several disk drives are available to store the
database, it might be helpful to store table data in a tablespace
on one disk drive, and index data in a tablespace on another disk
drive.
My gosh, imagine - I didn't just make this up! The amazement :)
This way, when users query table information, both disk
drives can work simultaneously, retrieving table and index data
at the same time.
Overlapped Disk I/O - I remember that term from way back in my
(gulp) PDP-8 days, working as a system hacker...
Look - in case there's any doubt, I'm not trying to toast Postgres,
I'm a fan, interested in getting more involved in the development
scenario. I raised this issue because Xun raised some "really big
database issues which I as a database theorist have an interest in".
My biggest sin if any is to try to paint the horizon, at this point.
Philip Greenspun still says that those of us (including employee
#3 or so of his company, Ben) who are interested in Postgres are "losers"
by definition (Ben no longer works there). Meanwhile, folks like Ben
and I keep telling folks that Postgres is growing into an ideal
RDBMS for database-backed websites (you know, that place where all
money is flowing and will continue to do so tomorrow, though don't
ask me about next week? :) And Philip says you're a loser if you
won't pay Oracle's license fee. He speaks as a dude badly bitten
by Illustra, based long ago on a long-dead version of Postgres but
the pain not yet forgotten...
Things like the Oracle documentation cited above fall into the class
of advice to folks running really big - and REALLY BUSY - database
servers.
Sure, hardware (cycles, RAM) fallsin price and as time goes on we
can perhaps forget some of the more horrific optimization stuff that
was invented to deal with small computer systems of one decade ago.
As a compiler writer, trust me - I'm familiar with the concept. And
with changing pardigms as designs flow from CISC to RISC (oh gosh,
not a theoretical advantage but you mean just a cost/performance point
on the transistor-per-chip curve? Damn, I should've patented my
cynicism 10 years ago!) and back to post-RISC CISC, I'm not about
to claim theoretical long-term advantages for any point-of-view.
I won't suggest that all of the big-time hacks employed to make old
commercial DBs like Oracle are necessary in today's hardware/OS climate
(raw I/O in particular falls into that category, IMH-tentative-O)
But, still...as long as we've had movable head disk drives (and my
first disk drive was head-per-track, believe it or not) minimizing
head movement has been an optimization goal. I've written complex
scheduling disk drivers in the past, and they can be good. Still,
nothing beats coalescing one spindle's I/O into a narrow number of
tracks, minimizing head movement. That's a constant that hasn't
changed for 30 years, and won't change next week.
Heck, it even lowers your downtime due to blown drives.
I might also add that the kind of systems Oracle doc writers were
thinking of 10 years ago just aren't in the Postgres universe of
possible DB clients...
But, it is changing. One impact - like it or not - of the good work
you folks have done over the past couple of (3 or 4 or I'm not personally
sure how much) years and the fact that you continue to push the db into
being more and more capable, more and more stable, more and more
feature-filled with SQL-92 stuff is that folks being asked to pay
$25,000 for a fully-paid up license on a PIII500 X86 system (<$2000
in hardware without even shopping, a greater than 10-1 software to
hardware ratio) are going to be looking for a cheaper alternative.
Of which you folks are one.
So, what's the deal, here...is the goal the Big Time or not?
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 00:39:46 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA53445
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 00:38:23 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA02826;
Thu, 13 Jan 2000 21:37:23 -0800 (PST)
Message-Id: <3.0.1.32.20000113212111.010834c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 13 Jan 2000 21:21:11 -0800
To: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed
Cc: Xun Cheng <xun@cs.ucsb.edu>, pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.BSF.4.21.0001140016150.46499-100000@thelab.hub.org>
References: <26429.947815297@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:21 AM 1/14/00 -0400, The Hermit Hacker wrote:
All the major OSs out there have "disk management tools" that allow you to
build "large file systems" out of smaller ones... Solaris has DiskSuite,
FreeBSD has vinum, Linux has ??... why are we looking/investigating adding
a level of complexity to PostgreSQL to handle something that, as far as I
know, each of the OSs out there already has a way of dealing with?
If the resident OS can handle the issue, sure, it is worth investigating.
Linux today does not (at least, the one I'm running).
One godliness-over-utility issue is the fact that doing such things in
the operating system ("ln" also works...) kinda violates the RDBMS ideal
of having everything about a database, including metadata, stored in
the database.
In the case of "CREATE TABLESPACE" having Postgres handle placement
places the burden of operating system specifics where it belongs - on the
implementation. This is why we say things like "integer" or "numeric",
come to think of it...
The word "portability" comes to mind, though of course things like
spindle numbers and the like are extremely variable.
Some aren't necessarily mature yet...Solaris's is the only one that I'm
aware of that has a *beautiful* growfs program that allows you to add a
new drive to an existing "pack" and grow the file system into that new
drive while the system is live...but the utilities are there...I think the major problem that I'm worried about isn't spreading tables
across drives, but its when that *one* table grows to the point that its
about to overflow my drive...I'd rather add a 9gig drive on, make it an
18gig file system, and let it continue to grow...
These aren't mutally exclusive problems, which is one reason why Oracle
allows you to control things so minutely. I think they let you spill
a table onto multiple drives, though I'd have to look at one of my
manuals hidden in my piles of more interesting things (I'm no Oracle
expert, I just read manuals :)
There is definitely a sort of tension between the operating systems,
which continue to grow in capability such as you're pointing out,
and commercial systems like Oracle that have to work TODAY regardless
of where operating systems sit on the capability yardstick.
Thus Oracle includes built-in mirroring, while today under Linux
you might as well do software RAID 1, or you can buy a hardware
device that does RAID 1 behind your back and looking like a single
drive no matter how many platter you stuff it with, etc etc.
So...you'll never hear me argue that Postgres should include
a mirroring storage manager. There is no longer the need for an
application to do it on its own in the supported OS space (hmmm...I'm
assuming FreeBSD is there, too, right?)
So maybe the notion of application placement of files on particular
spindles is becoming obsolete, too. It isn't today on Linux...
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 00:39:05 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA53664
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 00:38:31 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA02836;
Thu, 13 Jan 2000 21:37:24 -0800 (PST)
Message-Id: <3.0.1.32.20000113212532.01085600@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 13 Jan 2000 21:25:32 -0800
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>, "Tatsuo Ishii" <t-ishii@sra.co.jp>,
<tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: RE: [HACKERS] [hackers]development suggestion needed
Cc: <xun@cs.ucsb.edu>, <pgsql-hackers@postgreSQL.org>
In-Reply-To: <000401bf5e48$aecd2740$2801007e@tpf.co.jp>
References: <20000114114203R.t-ishii@sra.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 01:34 PM 1/14/00 +0900, Hiroshi Inoue wrote:
I agree with Tatsuo though I prefer
create table t1 (i int) tablespace foo;
.
Isn't it preferable to encapsulate the table location and storage type ?
Encapsulation is almost always preferable, but I don't think Tatsuo was
saying otherwise, merely pointing out a clever trick that I hadn't
though of (I didn't realize that "/foo" would be rooted rather than
just put under PGDATA, in fact I stay away from quoted non-SQL non-"normal
language" identifiers altogether, being somewhat interested in portability
of my application code).
And it is a clever trick...obvious to an insider, but not to me.
At first,a tablespace would only correspond to a directory and it won't
be so difficult to implment. But we would gain a lot with the feature.
In the future,the tablespace may be changed to mean real(??)
tablespace.
I think the decision to keep the mechanism for providing separate
storage mangers was a good one (if I understand correctly that there
was once consideration of removing it). Even if it is never used in
mainstream Postgres, some specialty application may use it, one of
the potentials that comes from open source software.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 00:39:05 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA53493
for <pgsql-hackers@postgresql.org>;
Fri, 14 Jan 2000 00:38:25 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA02854;
Thu, 13 Jan 2000 21:37:27 -0800 (PST)
Message-Id: <3.0.1.32.20000113213141.01081b00@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 13 Jan 2000 21:31:41 -0800
To: The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: Multiple Spindles ( Was: Re: [HACKERS]
[hackers]development suggestion needed )
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Xun Cheng <xun@cs.ucsb.edu>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.BSF.4.21.0001140022380.46499-100000@thelab.hub.org>
References: <3.0.1.32.20000113181933.010771d0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:31 AM 1/14/00 -0400, The Hermit Hacker wrote:
This would give you the ability to put all table from all databass onto
one file system, and all indexes onto another, and all system files onto a
third...I don't know, I'm oversimplying and spewing thoughts out
again...but...*shrug*
This kind of hack would certainly be doable, but I guess the question
arises once again - is PostgreSQL shooting to be the Big Time or not?
I mean, the mere use of words like "Bronze Support" and "Silver Support"
remind one of Oracle :)
This particular issue of the placement of tables and indices pales
in importance compared to outer joins, for instance. But once all
the big things are implemented, folks doing BIG JOBS will look at
Postgres as being a viable alternative. And they'll then be disappointed
if they don't have the kind of control over files that they do with
Oracle or other big-time commercial DBs...the folks talking about
replication are coming from the same space, though much more ambitiously
(since a simple tablespace feature could be simple, while I can't
think of any simple replication hacks).
I'd like to see Postgres succeed in a big way. I don't see it toppling
Oracle, but heck I can't see why Interbase can't be ground into dust.
Open Source, great functionality, maybe B+ on scalability etc (thus not
toppling Oracle but equal to most others) ... that's not too ambitious
a goal, is it?
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 00:40:05 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA54802
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 00:39:08 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA02870;
Thu, 13 Jan 2000 21:37:28 -0800 (PST)
Message-Id: <3.0.1.32.20000113213523.010865d0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 13 Jan 2000 21:35:23 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>,
The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: Multiple Spindles ( Was: Re: [HACKERS]
[hackers]development suggestion needed )
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Xun Cheng <xun@cs.ucsb.edu>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <200001140441.XAA29967@candle.pha.pa.us>
References: <Pine.BSF.4.21.0001140022380.46499-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:41 PM 1/13/00 -0500, Bruce Momjian wrote:
And put sort and large objects somewhere separate too.
Yeah, very very good point! Though toasted or roasted or toasty or
whatever large objects (I unsubscribed for a few crucial days when
I was back east travelling around with my girlfriend) might make
the large-object issue less important?
Also, for sorting, many sites will just load down with RAM, and this
will increase rapidly over the next few years (despite current
SDRAM high prices and the whole RDRAM fiasco). But really really
big sites might appreciate such a feature...
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 00:56:06 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA58348;
Fri, 14 Jan 2000 00:55:16 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id AAA07720;
Fri, 14 Jan 2000 00:39:30 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA28372;
Fri, 14 Jan 2000 00:38:54 -0500 (EST)
To: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
Subject: Does SSL code still work after async-connection changes?
Date: Fri, 14 Jan 2000 00:38:54 -0500
Message-ID: <28369.947828334@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Can anyone who uses SSL check whether libpq current sources still
work for SSL connections?
It looks to me like it's completely broken --- surely trying to
negotiate SSL before doing connect() isn't going to work too well?
But I don't know anything about SSL, nor have it installed,
so I'm not eager to touch it...
regards, tom lane
From bouncefilter Fri Jan 14 00:44:05 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA56511
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 00:43:33 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA04407;
Thu, 13 Jan 2000 21:42:20 -0800 (PST)
Message-Id: <3.0.1.32.20000113214023.01085600@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 13 Jan 2000 21:40:23 -0800
To: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: Multiple Spindles ( Was: Re: [HACKERS]
[hackers]development suggestion needed )
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Xun Cheng <xun@cs.ucsb.edu>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.BSF.4.21.0001140048230.46499-100000@thelab.hub.org>
References: <200001140441.XAA29967@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:59 AM 1/14/00 -0400, The Hermit Hacker wrote:
if tables/indexs were in different subdirectories, it would be too easy
for me, at some point in the future, to take just the tables directory and
put them on their own dedicated drive, halving the space used on either
drive...I don't know...IMHO, it sounds like the simplist solution that provides
the multi-spindle benefits ppl are suggesting...
Splitting tables/indexes seems to be the first-order optimization, from
my talking to folks who are far more experienced with databases than
I (I did mention I wrote my first query less than a year ago, didn't
I?)
Still...encapsulation within the RDBMS itself seems to be in the
spirit of what RDBMS's are all about...such encapsulation could
be expressed in very simple external form and still be useful, but
I think it should be encapsulated...
Among other things, if CREATE TABLESPACE were dumped by pg_dump,
I could move from V7.0 to V8.0 and beyond without having to
rebuild my distribution structure by hand :)
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 00:47:05 2000
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 AAA56897
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 00:46:16 -0500 (EST) (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 OAA00788; Fri, 14 Jan 2000 14:46:02 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Xun Cheng" <xun@cs.ucsb.edu>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] [hackers]development suggestion needed
Date: Fri, 14 Jan 2000 14:51:35 +0900
Message-ID: <000601bf5e53$6a841200$2801007e@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
In-Reply-To: <25266.947813004@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lanexun@cs.ucsb.edu (Xun Cheng) writes:
I want to experiment with some new fast join algorithms.
Cool. Welcome aboard!
Could anyone tell me if
the directory /docs/pgsql/src/backend/executor is the
right place to startThe executor is only half the problem: you must also teach the
planner/optimizer how and when to use the new join type.Hiroshi Inoue has recently been down this path (adding support
for TID-based scans), and might be able to give you more specific
advice.
Hmm,un(??)fortunately,I didn't have to understand details about join
to implement Tidscan. It's a basic scan and is used to scan one relation.
I don't know about document well either,sorry. AFAIK,Tom is
decidedly superior to me in understanding planner/optimizer.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Fri Jan 14 00:55:05 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA58274
for <pgsql-hackers@postgresql.org>;
Fri, 14 Jan 2000 00:54:49 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id BAA83169
for <pgsql-hackers@postgresql.org>;
Fri, 14 Jan 2000 01:54:53 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 14 Jan 2000 01:54:53 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Why must -N be >= 16?
Message-ID: <Pine.BSF.4.21.0001140152410.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Just trying to start up a 'mini-process' of -B 8 -N 4, and it tells me
that -N must be >= 16 ... why?
documentation doesn't seem to imply/indicate this, should it?
-N n_backends
n_backends is the maximum number of backend server
processes that this postmaster is allowed to start.
In the stock configuration, this value defaults to
32, and can be set as high as 1024 if your system
will support that many processes. Both the default
and upper limit values can be altered when building
Postgres (see src/include/config.h).
For security reasons, I have a server running on its own port, and I want
to restrict the amount of shared memory that it uses, and I know the app
will never open more then 4 backends (it would be lucky to hit 2), so
figured 8/4 would be nice and safe...
Thanks...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 14 01:00:05 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA59267
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 00:59:27 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA28541;
Fri, 14 Jan 2000 00:59:08 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, Xun Cheng <xun@cs.ucsb.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-reply-to: <200001140232.VAA26708@candle.pha.pa.us>
References: <200001140232.VAA26708@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Thu, 13 Jan 2000 21:32:44 -0500"
Date: Fri, 14 Jan 2000 00:59:08 -0500
Message-ID: <28538.947829548@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
...
Or we could continue to use symlinks, and just create them ourselves in
the backend.
But you'd still need some built-in understanding about where the table
is Really Supposed To Be, because you'd need to be able to create and
delete the symlinks on the fly when the table grows past a 1-Gb segment
boundary (or is shrunk back again by vacuum!).
AFAICS, a reasonable solution still requires storing a location path
for each table --- so you might as well just use that path directly.
regards, tom lane
From bouncefilter Fri Jan 14 01:05:05 2000
Received: from corvette.mascari.com (dhcp26142035.columbus.rr.com
[24.26.142.35]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA62235
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 01:04:49 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id BAA03860;
Fri, 14 Jan 2000 01:02:01 -0500
Message-ID: <387EBB99.7D35BA7D@mascari.com>
Date: Fri, 14 Jan 2000 01:00:57 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
Xun Cheng <xun@cs.ucsb.edu>, pgsql-hackers@postgreSQL.org
Subject: Re: Multiple Spindles ( Was: Re: [HACKERS][hackers]development
suggestion needed )
References: <3.0.1.32.20000113181933.010771d0@mail.pacifier.com>
<3.0.1.32.20000113213141.01081b00@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
I'd like to see Postgres succeed in a big way. I don't see it toppling
Oracle, but heck I can't see why Interbase can't be ground into dust.
Open Source, great functionality, maybe B+ on scalability etc (thus not
toppling Oracle but equal to most others) ... that's not too ambitious
a goal, is it?
Shoot for the sky you hit the eagle, shoot for the eagle you hit
the ground....
Mike Mascari
From bouncefilter Fri Jan 14 01:38:05 2000
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 BAA70947
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 01:37:13 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA04275;
Fri, 14 Jan 2000 01:16:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001140616.BAA04275@candle.pha.pa.us>
Subject: Re: Multiple Spindles ( Was: Re: [HACKERS] [hackers]development
suggestion needed )
In-Reply-To: <3.0.1.32.20000113213141.01081b00@mail.pacifier.com> from Don
Baccus at "Jan 13, 2000 09:31:41 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Fri, 14 Jan 2000 01:16:17 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
Xun Cheng <xun@cs.ucsb.edu>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I'd like to see Postgres succeed in a big way. I don't see it toppling
Oracle, but heck I can't see why Interbase can't be ground into dust.
Open Source, great functionality, maybe B+ on scalability etc (thus not
toppling Oracle but equal to most others) ... that's not too ambitious
a goal, is it?
We don't block people for working on ietms. However, we do try and set
priorities based on the open items we have. I hope we don't appear
heavy-handed in this regard.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 14 01:37:06 2000
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 BAA70885
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 01:36:53 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA04371;
Fri, 14 Jan 2000 01:20:22 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001140620.BAA04371@candle.pha.pa.us>
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: <28538.947829548@sss.pgh.pa.us> from Tom Lane at "Jan 14,
2000 00:59:08 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 14 Jan 2000 01:20:22 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>, Xun Cheng <xun@cs.ucsb.edu>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
...
Or we could continue to use symlinks, and just create them ourselves in
the backend.But you'd still need some built-in understanding about where the table
is Really Supposed To Be, because you'd need to be able to create and
delete the symlinks on the fly when the table grows past a 1-Gb segment
boundary (or is shrunk back again by vacuum!).AFAICS, a reasonable solution still requires storing a location path
for each table --- so you might as well just use that path directly.
Makes sense. The only advantage to symlinks is that you could use that
information in places you need it, and for normal access use the
symlinks. You wouldn't have to carry around that info as much.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 14 01:37:06 2000
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 BAA70852
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 01:36:35 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA04385;
Fri, 14 Jan 2000 01:22:29 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001140622.BAA04385@candle.pha.pa.us>
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: <3.0.1.32.20000113210831.01081270@mail.pacifier.com> from Don
Baccus at "Jan 13, 2000 09:08:31 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Fri, 14 Jan 2000 01:22:29 -0500 (EST)
CC: Mike Mascari <mascarm@mascari.com>, Tatsuo Ishii <t-ishii@sra.co.jp>,
tgl@sss.pgh.pa.us, xun@cs.ucsb.edu, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Look - in case there's any doubt, I'm not trying to toast Postgres,
I'm a fan, interested in getting more involved in the development
scenario. I raised this issue because Xun raised some "really big
database issues which I as a database theorist have an interest in".
My biggest sin if any is to try to paint the horizon, at this point.
Philip Greenspun still says that those of us (including employee
#3 or so of his company, Ben) who are interested in Postgres are "losers"
by definition (Ben no longer works there). Meanwhile, folks like Ben
I thought Phil was a big fan of ours.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 14 01:23:07 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA66060
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 01:22:53 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA28715;
Fri, 14 Jan 2000 01:22:46 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Why must -N be >= 16?
In-reply-to: <Pine.BSF.4.21.0001140152410.46499-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001140152410.46499-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Fri, 14 Jan 2000 01:54:53 -0400"
Date: Fri, 14 Jan 2000 01:22:46 -0500
Message-ID: <28712.947830966@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Just trying to start up a 'mini-process' of -B 8 -N 4, and it tells me
that -N must be >= 16 ... why?
You misread it --- -N can be as small as you like, but we don't allow
a really tiny -B. To quote the code:
if (NBuffers < 2 * MaxBackends || NBuffers < 16)
{
/* Do not accept -B so small that backends are likely to starve for
* lack of buffers. The specific choices here are somewhat arbitrary.
*/
fprintf(stderr, "%s: -B must be at least twice -N and at least 16.\n",
progname);
exit(1);
}
I'm not even real sure that -B 16 is going to work well if you throw
complex queries at it --- we've not stressed the system with small
numbers of buffers.
regards, tom lane
From bouncefilter Fri Jan 14 01:27:06 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA66423
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 01:26:33 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA28743;
Fri, 14 Jan 2000 01:26:30 -0500 (EST)
To: admin <admin@wtbwts.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] SPI_fnumber can't see oid
In-reply-to: <Pine.BSF.4.10.10001132307050.75240-100000@server.b0x.com>
References: <Pine.BSF.4.10.10001132307050.75240-100000@server.b0x.com>
Comments: In-reply-to admin <admin@wtbwts.com>
message dated "Thu, 13 Jan 2000 23:16:04 +0000"
Date: Fri, 14 Jan 2000 01:26:30 -0500
Message-ID: <28740.947831190@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
admin <admin@wtbwts.com> writes:
ERROR: check_foreign_key: there is no attribute oid in relation product
Looking at src/backend/executor/spi.c, I noticed SPI_fnumber started
counting at 0. Is this normal or should it be -1, assuming oid might be
just before 0?
I think the SPI code is deliberately set up to prevent access to
the system attributes. Jan Wieck is probably the only one who knows
exactly why, but I'll bet that something will break if you bypass
that restriction :-(
regards, tom lane
From bouncefilter Fri Jan 14 01:44:06 2000
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 BAA71630
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 01:43:38 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <CZZ0L896>; Fri, 14 Jan 2000 08:40:17 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C440@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'The Hermit Hacker'" <scrappy@hub.org>, Don Baccus <dhogaza@pacifier.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Xun Cheng <xun@cs.ucsb.edu>,
pgsql-hackers@postgreSQL.org
Subject: RE: Multiple Spindles ( Was: Re: [HACKERS] [hackers]development
suggestion needed )
Date: Fri, 14 Jan 2000 08:34:12 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
But it's not quite this simple. In our production system, we have reference
data in one tablespace, reference indices in another, working data in a
third space, and work indices in a fourth. This is because the amount of
working data throughput is extremely high, while the reference data,
although changing reasonably frequently, changes significantly less than the
working data. This is then normally spread across five spindles, with
Oracle being in the fifth. On a 32-processor HP.
I think a good solution is to be able to specify where on the disk the table
is created (absolute paths only), and then postgres symlinks that file in
the main data directory, so from that point on it referenced without the
path name. That's probably a significant start.
Alternatively, we could create "directoryspaces", which treats a directory
as a tablespace. Then you do this:
CREATE TABLE foo (id_foo int, name varchar(30)) TABLESPACE
"/data/pgdata/sys1ref";
to create the new file /data/pgdata/sys1ref/foo, and a symlink is created in
the main db directory, so that you can just SELECT * FROM foo;
This is not difficult at all, or am I missing something? Only real issue
(possibly) is security regarding the tablespace. It might be an idea to
allow only the superuser to add allowed directories (i.e.: "create"
tablespaces), and assign user access to those tablespaces.
MikeA
-----Original Message-----
From: The Hermit Hacker [mailto:scrappy@hub.org]
Sent: Friday, January 14, 2000 6:32 AM
To: Don Baccus
Cc: Tom Lane; Xun Cheng; pgsql-hackers@postgreSQL.org
Subject: Multiple Spindles ( Was: Re: [HACKERS] [hackers]development
suggestion needed )On Thu, 13 Jan 2000, Don Baccus wrote:
My site's still in the experimental stage, being used by a couple
dozen folks to record bird distribution data in the Pacific NW, so
I don't personally have real-world data to get a feeling for how
important this might become. Still, Oracle DBA docs talk a lot
about it so in some real-world scenarios being able to distribute
tables and indices on different spindles must pay off.What would it take to break the data/base/<database>
directory down? To
something like, maybe:data/base/<database>/pg_*
/tables/*
/indices/*Then, one could easily mount a drive as /tables and another one as
/indices ...We know the difference between a table and an index, so I
wouldn't think
it would be *too* hard add /tables/ internally to the existing
path...would it?You'd basically have somethign like:
sprintf("%s/data/base/%s/tables/%s", data_dir, database, tablename);
Instead of:
sprintf("%s/data/base/%s/%s", data_dir, database, tablename);
I know, I'm being simplistic here, but...
Or, a different way:
if(table) sprintf("%s/data/base/table/%s/%s",
data_dir,database,tablename);
else if(index) sprintf("%s/data/base/index/%s/%s",
data_dir,database,tablename);
else sprintf("%s/data/base/sys/%s/%s", data_dir,database,sysfile);This would give you the ability to put all table from all
databass onto
one file system, and all indexes onto another, and all
system files onto a
third...I don't know, I'm oversimplying and spewing thoughts out
again...but...*shrug*Marc G. Fournier ICQ#7615664
IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary:
scrappy@{freebsd|postgresql}.org************
From bouncefilter Fri Jan 14 01:56:06 2000
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 BAA73515
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 01:55:59 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <CZZ0L800>; Fri, 14 Jan 2000 08:52:43 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C441@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'The Hermit Hacker'" <scrappy@hub.org>, Bruce Momjian
<pgman@candle.pha.pa.us>
Cc: Don Baccus <dhogaza@pacifier.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Xun Cheng <xun@cs.ucsb.edu>, pgsql-hackers@postgreSQL.org
Subject: RE: Multiple Spindles ( Was: Re: [HACKERS] [hackers]development
suggestion needed )
Date: Fri, 14 Jan 2000 08:43:42 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Yes, but what if it's just your data that's a problem, and not so much the
index space. Then you are more likely to want to split the table data than
split tables from index data.
MikeA
-----Original Message-----
From: The Hermit Hacker [mailto:scrappy@hub.org]
Sent: Friday, January 14, 2000 6:59 AM
To: Bruce Momjian
Cc: Don Baccus; Tom Lane; Xun Cheng; pgsql-hackers@postgreSQL.org
Subject: Re: Multiple Spindles ( Was: Re: [HACKERS]
[hackers]development
suggestion needed )On Thu, 13 Jan 2000, Bruce Momjian wrote:
On Thu, 13 Jan 2000, Don Baccus wrote:
My site's still in the experimental stage, being used
by a couple
dozen folks to record bird distribution data in the
Pacific NW, so
I don't personally have real-world data to get a
feeling for how
important this might become. Still, Oracle DBA docs talk a lot
about it so in some real-world scenarios being able todistribute
tables and indices on different spindles must pay off.
What would it take to break the data/base/<database>
directory down? To
something like, maybe:
data/base/<database>/pg_*
/tables/*
/indices/*And put sort and large objects somewhere separate too.
why not? by default, one drive, it would make no difference
except for
file layout, but it would *really* give room to expand...Right now, the udmsearch database contains (approx):
tables:
10528 dict10
5088 dict11
2608 dict12
3232 dict16
64336 dict2
47960 dict3
3096 dict32
65952 dict4
42944 dict5
36384 dict6
34792 dict7
21008 dict8
14120 dict9
31912 urlindexs:
5216 url_id10
2704 url_id11
1408 url_id12
1648 url_id16
36440 url_id2
27128 url_id3
1032 url_id32
37416 url_id4
22600 url_id5
19096 url_id6
18248 url_id7
10880 url_id8
6920 url_id9
6464 word10
3256 word11
1672 word12
2280 word16
26344 word2
21200 word3
2704 word32
28720 word4
21880 word5
19240 word6
18464 word7
11952 word8
8864 word9if tables/indexs were in different subdirectories, it would
be too easy
for me, at some point in the future, to take just the tables
directory and
put them on their own dedicated drive, halving the space
used on either
drive...I don't know...IMHO, it sounds like the simplist solution
that provides
the multi-spindle benefits ppl are suggesting...************
From bouncefilter Fri Jan 14 01:50:06 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id BAA72635
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 01:49:25 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 32571 invoked from network); 14 Jan 2000 06:49:22 -0000
Received: from h-62.96.159.96.host.de.colt.net (root@62.96.159.96)
by pille.addcom.de with SMTP; 14 Jan 2000 06:49:22 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id HAA00466
for pgsql-hackers@postgreSQL.org; Fri, 14 Jan 2000 07:47:17 +0100
Date: Fri, 14 Jan 2000 07:47:17 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FETCH without FROM/IN
Message-ID: <20000114074717.A437@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000112161216.A334@fam-meskes.de> <9917.947693351@sss.pgh.pa.us>
<20000112175326.A2376@fam-meskes.de>
<11241.947725982@sss.pgh.pa.us>
<20000113084816.A7433@fam-meskes.de>
<12925.947781271@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <12925.947781271@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Thu, Jan 13, 2000 at 11:34:31AM -0500
On Thu, Jan 13, 2000 at 11:34:31AM -0500, Tom Lane wrote:
FETCH [ [ direction ] [ how_many ] FROM/IN ] portal_name
Looks good to me.
Certainly we currently accept a how_many clause without a preceding
direction, so if the patch removes that possibility then it's wrong.
Sure. Rene already send me a fix.
If you do it like that (ie, the portal name is now required), I *think*
it will work without shift-reduce conflicts in the current grammar,
but we may regret it later when we try to do more of SQL92. I would
recommend sticking to an SQL92-like syntax, in which FROM/IN is not
optional if direction and/or how_many appear.The reason I'm concerned about this is that all of the direction and
howmany keywords are considered valid ColIds (and if we take them out
of the ColIds list, we risk breaking databases that work at present).
That means that the parser has some difficulty in figuring out whether
an apparent keyword is really a keyword, or a portal name that happens
to be the same as a keyword. For example, considerFETCH NEXT;
If both FROM and portal_name were optional, this statement would
actually be ambiguous: is it FETCH NEXT from the default portal,
Do we have a default portal?
or FETCH with default options from a cursor named NEXT?
...
What I'm concerned about is that SQL92 allows other options *after*
the cursor name, and we may someday want to support those. We could
easily find that the grammar is no longer LR(1) (ie, it takes more than
one token lookahead to decide whether we have the portal name or not);
and then we've got trouble. If FROM is required after FETCH options
then this risk is much reduced.
Yes, I completely agree on this one.
I will try to change the syntax to what you proposed.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Fri Jan 14 02:39:06 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA84125;
Fri, 14 Jan 2000 02:38:13 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA28902;
Fri, 14 Jan 2000 02:38:04 -0500 (EST)
To: Michael Meskes <meskes@postgreSQL.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FETCH without FROM/IN
In-reply-to: <20000114074717.A437@fam-meskes.de>
References: <20000112161216.A334@fam-meskes.de> <9917.947693351@sss.pgh.pa.us>
<20000112175326.A2376@fam-meskes.de>
<11241.947725982@sss.pgh.pa.us>
<20000113084816.A7433@fam-meskes.de>
<12925.947781271@sss.pgh.pa.us> <20000114074717.A437@fam-meskes.de>
Comments: In-reply-to Michael Meskes <meskes@postgreSQL.org>
message dated "Fri, 14 Jan 2000 07:47:17 +0100"
Date: Fri, 14 Jan 2000 02:38:04 -0500
Message-ID: <28898.947835484@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Meskes <meskes@postgreSQL.org> writes:
FETCH NEXT;
If both FROM and portal_name were optional, this statement would
actually be ambiguous: is it FETCH NEXT from the default portal,
Do we have a default portal?
Darn if I know, but the current gram.y thinks so. If I try it
without any preparation, I get:
regression=# fetch;
NOTICE: PerformPortalFetch: blank portal unsupported
FETCH
but maybe with some magic DECLARE beforehand, it'd work?
Anyone know?
Since the SQL92 spec clearly requires a cursor name to be provided,
I'd be willing to see us remove the option of defaulting the cursor
name. Is there anyone out there who knows what it does and wants
to argue we should keep it?
regards, tom lane
From bouncefilter Fri Jan 14 02:59:07 2000
Received: from cap-ferrat.albourne.com (cap-ferrat.albourne.com
[195.89.178.227]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA86533
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 02:58:54 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (bishop-rock.albourne.com [195.89.178.230])
by cap-ferrat.albourne.com (8.9.3/8.9.3/Albourne/UKS/2.9/MAPS) with
ESMTP id HAA31089; Fri, 14 Jan 2000 07:58:34 GMT
Sender: a.joubert@albourne.com
Message-ID: <387ED731.DCEA1092@albourne.com>
Date: Fri, 14 Jan 2000 07:58:41 +0000
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Xun Cheng <xun@cs.ucsb.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
References: <200001140046.QAA17082@brubeck.cs.ucsb.edu>
<200001140046.QAA17082@brubeck.cs.ucsb.edu>
<3.0.1.32.20000113174339.01078360@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
You don't get to do either of the latter two unless you write a
raw-device storage manager
Not within a single filesystem, but scattering things across spindles
could be done without a raw-device storage manager :)
Yes, but seen how cheap RAID arrays have become? I know disks are getting
bigger as well, and many people will opt for a single disk, but there may
be more urgent things to fix than something for which a hardware solution
already exists. And lets face it: a database ought to be on RAID
anyway,unless somebody wants to write Tandem-style mirrored disks.... ;-)
Adriaan
From bouncefilter Fri Jan 14 04:09:07 2000
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 EAA19795
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 04:08:14 -0500 (EST) (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 MAA07633;
Fri, 14 Jan 2000 12:04:32 +0300 (GMT)
Date: Fri, 14 Jan 2000 12:04:32 +0300 (GMT)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Don Baccus <dhogaza@pacifier.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: <3.0.1.32.20000113181933.010771d0@mail.pacifier.com>
Message-ID: <Pine.GSO.3.96.SK.1000114120043.6554G-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Don Baccus wrote:
Date: Thu, 13 Jan 2000 18:19:33 -0800
From: Don Baccus <dhogaza@pacifier.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Xun Cheng <xun@cs.ucsb.edu>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
...skipped...
The selects that such sites spew forth are handled wonderfully
by Postgres now, with MVCC and the change that stops the update
of pg_log after read-only selects.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Just curious,
Does plain 6.5.3 handle read-only selects in this way ?
Regards,
Oleg
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.************
_____________________________________________________________
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 Fri Jan 14 05:36:08 2000
Received: from oxmail.ox.ac.uk (oxmail2.ox.ac.uk [163.1.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA41531
for <pgsql-hackers@postgresql.org>;
Fri, 14 Jan 2000 05:35:30 -0500 (EST)
(envelope-from mbeattie@sable.ox.ac.uk)
Received: from sable.ox.ac.uk ([163.1.2.4])
by oxmail.ox.ac.uk with esmtp (Exim 2.10 #1) id 12944l-0007HX-00
for pgsql-hackers@postgresql.org; Fri, 14 Jan 2000 10:35:27 +0000
Received: from mbeattie by sable.ox.ac.uk with local (Exim 3.12 #1)
id 12944k-0004gn-00
for pgsql-hackers@postgreSQL.org; Fri, 14 Jan 2000 10:35:26 +0000
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: <3.0.1.32.20000113212111.010834c0@mail.pacifier.com> from Don
Baccus at "Jan 13, 2000 09:21:11 pm"
To: pgsql-hackers@postgresql.org
Date: Fri, 14 Jan 2000 10:35:26 +0000 (GMT)
From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <E12944k-0004gn-00@sable.ox.ac.uk>
Don Baccus writes:
At 12:21 AM 1/14/00 -0400, The Hermit Hacker wrote:
All the major OSs out there have "disk management tools" that allow you to
build "large file systems" out of smaller ones... Solaris has DiskSuite,
FreeBSD has vinum, Linux has ??... why are we looking/investigating adding
a level of complexity to PostgreSQL to handle something that, as far as I
know, each of the OSs out there already has a way of dealing with?If the resident OS can handle the issue, sure, it is worth investigating.
Linux today does not (at least, the one I'm running).
Linux has software raid (often called "md") with most of the usual
bells and whistles (RAID0, RAID1, RAID5, RAID0+1, hot spares,
background reconstruction). You can patch in LVM (logical volume
management) although the distributions of which I am aware don't ship
it ready-patched. That's the equivalent of Digi^H^H^H^HTru64 UNIX LSM
and AIX and so on have similar things. Basically, join together
physical disk units into logical block devices with additions being
possible on the fly. If you put an ext2 filesystem on one of those,
then you can dynamically resize it with e2resize, although that is not
completely production quality yet and last I heard you could currently
only increase the filesystem size on the fly and not decrease it. ISTR
the competition tend only to allow increase and not shrink but the
ext2 one is designed to allow shrink too. The complexity isn't so much
in the basics ("simply" throw in more block groups and be carefuly
about atomicity if the system is live); it's in stuff like making sure
that the system is robust against fragmentation, goal allocation needs
tweaking (I think) and how you gather together admin information about
where all the bits are. If you break apart the separate disks of a
live filesystem, it's nice to know where all the bits go.
Even with all that underlying stuff, it's *still* important for higher
level configuration at the database level to be possible. Even if from
the theoretical point of view it's all one big page space, it matters
a great deal in practice to be able to spread different bits out over
different table spaces/volumes/files/block devices/whatever.
I think that means I'm in violent agreement with you on the db side
but this reply does give me a chance to point out that Linux isn't
missing the functionality you haven't noticed in it :-).
--Malcolm
--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services
From bouncefilter Fri Jan 14 09:09:11 2000
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA84867
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 09:08:56 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA00450
for <pgsql-hackers@postgreSQL.org>; Fri, 14 Jan 2000 15:08:52 +0100
Date: Fri, 14 Jan 2000 15:08:52 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: locale vs. regress
Message-ID: <Pine.LNX.3.96.1000114150132.17403F-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
I look at current PG's regress tests and I'm not sure if before test
start anything set LANG/Locale. How is it?
Now it is not interesting (probably), but in future...
(Example to_char() has locale depend output.)
Karel
----------------------------------------------------------------------
Karel Zak <zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/
Docs: http://docs.linux.cz (big docs archive)
Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
-----------------------------------------------------------------------
From bouncefilter Fri Jan 14 14:13:14 2000
Received: from pcr.ca (www.pcr.ca [207.139.158.13] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id OAA61120
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 14:12:57 -0500 (EST)
(envelope-from admin@wtbwts.com)
Received: by pcr.ca (Postfix, from userid 1000)
id E9C831FE8; Fri, 14 Jan 2000 14:11:52 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1]) by pcr.ca (Postfix) with
ESMTP
id CFD8A1F91; Fri, 14 Jan 2000 14:11:52 +0000 (GMT)
Date: Fri, 14 Jan 2000 14:11:52 +0000 (GMT)
From: admin <admin@wtbwts.com>
X-Sender: admin@server.b0x.com
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Don Baccus <dhogaza@pacifier.com>,
pgsql-hackers@postgreSQL.org, scrappy@hub.org
Subject: Re: [HACKERS] Revised nonblocking patches + quasi docs
In-Reply-To: <20000114111430.A824@fw.wintelcom.net>
Message-ID: <Pine.BSF.4.10.10001141401330.84869-100000@server.b0x.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
The FreeBSD Documentation Project (FDP) has excellent references to get a
general idea on building sgml docs. First, you can install the
textproc/docproj port or, if you're not running freebsd, refer to the
website to see which programs you need. Second, you can read the FDP
Primer which details how everything comes together:
http://www.freebsd.org/tutorials/docproj-primer/
Furthermore, again if you happen to be running FreeBSD, you can grab the
doc src using cvsup. The proper reference is also documented somewhere in
the Primer or in the Synchronisation chapter in the Handbook.
Keep at it, sgml and the docbook stylesheets are really worthwhile when
you start getting the hang of it.
Marc
* Tom Lane <tgl@sss.pgh.pa.us> [000109 08:18] wrote:
Don Baccus <dhogaza@pacifier.com> writes:
At 05:27 PM 1/8/00 -0500, Tom Lane wrote:
I also object strongly to the lack of documentation.
... I know there are some folks who aren't native-english speakers, so
perhaps you don't want to require that the implementor of such patches
provide the final documentation wording. But the information should
be there and spelled out in a form that can be very easily moved to
the docs.Oh, absolutely. Thomas, our master of the docs, has always had the
policy of "give me some words, I'll take care of formatting and
editing..."I was probably too harsh on Alfred last night, since in fact his code
was fairly well commented, and some minimal doco could have been
extracted from the routine headers. But on a change like this, I think
some paragraphs of coherent high-level explanation are needed: what it
does, when and why you'd use it. I didn't see that anywhere...I've actually been trying to work on the sgml and failing miserably,
I have no clue how this stuff works (sgml compilation) are you asking
for a couple of paragraphs that describe the proposed changes?If so I hope this suffices, if not some help on building the sgml
would be much appreciated:--------
Summary:
First and foremost, great pains have been taken so that there
are _no_ compatibility issues.If a 6.5.3 libpq program should not behave any differently
with this patches in place, all they do is offer a step closer
to a truly non-blocking connection to the backend and address
some issues with non-blocking connections.----
Added functions:
int PQisnonblocking(static PGconn *conn);
returns whether or not the socket is in blocking mode, however...
it doesn't actually check the socket flags, it relies on the user
to call 'PQsetnonblocking()' to keep the internal state of libpq
sane. users should no longer use 'PQsocket()' to retrieve the
socket and 'manually' ioctl/fcntl it to non-blockingreturns TRUE if the socket has been set to blocking more, FALSE
if the socket is blockingint PQflush(PGconn *conn);
flush the send-queue to the backend, just make this visible to the
user for convience, as the internal function works, 0 for success,
EOF for any failure.int PQsetnonblocking(PGconn *conn, int arg);
actually set the connection to the backend to blocking or
non-blocking arg should be set to TRUE to set the connection to
non-blocking or FALSE to set it blocking.there's an implied blocking flush of the send-queue which is
really ok as the user is either 'going into' or 'returning from'
a blocking statereturns 0 for success, -1 for failure
---
New functionality:
PQsetblocking() allows libpq to know what behavior the user really
wants, the user will not block sending data to the backend,
potentially if i had a constant stream of data and was doing a
COPYIN it'd never finish because unless the backend lost the
connection I would block while sending until the backend can take
more data.---
Implementation changes:
none should be visible to programs based on 6.5.3's libpq.
programs based on later versions of libpq will notice that
the non-blocking connection functions will set the state of
the connection to non-blocking automatically.when the connection is set non-blocking pqFlush() will not block
if the sendqueue would be filled by new data inserted into the
the queue.functions that poll for data from the backend implicitly _try_
flush the send queue if set to non-blocking. This allows the
polling to act as a context for pushing queued data to the backend.---
Problems:
We need some sort of send-queue commit reservations so that
there's no chance of us sending a partial queury down the pipe
to the backend, right now this is hacked around by potentially
blocking in non-blocking mode if something 'goes terribly wrong'
I plan to fix this.---
Quirks:
PQexec() assumes the caller wants blocking behavior and will set the
connection to blocking for the duration of the PQexec() call, it will
then restore it---
Internal changes:
new field in PGconn 'int nonblocking' set to 1 if the connection is
nonblocking, 0 if blocking (default)macro pqIsnonblocking(PGconn) to avoid a function call to check blocking
status (only visible if libpq-int.h is included)the internal function connectMakeNonblocking() has been replaced with
PQsetblocking()restart a send if EINTR is reported during a flush.
---
Lastly:
This is work in progress, I will be working towards making libpq
better at not blocking.here are the diffs:
Index: fe-connect.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-connect.c,v retrieving revision 1.109 diff -u -c -IHeader -I$Id: -r1.109 fe-connect.c cvs diff: conflicting specifications of output style *** fe-connect.c 2000/01/14 05:33:15 1.109 --- fe-connect.c 2000/01/14 18:36:54 *************** *** 594,624 **** return 0; }- - /* ---------- - * connectMakeNonblocking - - * Make a connection non-blocking. - * Returns 1 if successful, 0 if not. - * ---------- - */ - static int - connectMakeNonblocking(PGconn *conn) - { - #ifndef WIN32 - if (fcntl(conn->sock, F_SETFL, O_NONBLOCK) < 0) - #else - if (ioctlsocket(conn->sock, FIONBIO, &on) != 0) - #endif - { - printfPQExpBuffer(&conn->errorMessage, - "connectMakeNonblocking -- fcntl() failed: errno=%d\n%s\n", - errno, strerror(errno)); - return 0; - } - - return 1; - } - /* ---------- * connectNoDelay - * Sets the TCP_NODELAY socket option. --- 594,599 ---- *************** *** 789,795 **** * Ewan Mellor <eem21@cam.ac.uk>. * ---------- */ #if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL) ! if (!connectMakeNonblocking(conn)) goto connect_errReturn; #endif--- 764,770 ---- * Ewan Mellor <eem21@cam.ac.uk>. * ---------- */ #if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL) ! if (PQsetnonblocking(conn, TRUE) != 0) goto connect_errReturn; #endif***************
*** 898,904 ****
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (!connectMakeNonblocking(conn))
goto connect_errReturn;
#endif--- 873,879 ---- /* This makes the connection non-blocking, for all those cases which forced us not to do it above. */ #if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL) ! if (PQsetnonblocking(conn, TRUE) != 0) goto connect_errReturn; #endif*************** *** 1702,1707 **** --- 1677,1683 ---- conn->inBuffer = (char *) malloc(conn->inBufSize); conn->outBufSize = 8 * 1024; conn->outBuffer = (char *) malloc(conn->outBufSize); + conn->nonblocking = FALSE; initPQExpBuffer(&conn->errorMessage); initPQExpBuffer(&conn->workBuffer); if (conn->inBuffer == NULL || *************** *** 1812,1817 **** --- 1788,1794 ---- conn->lobjfuncs = NULL; conn->inStart = conn->inCursor = conn->inEnd = 0; conn->outCount = 0; + conn->nonblocking = FALSE;}
Index: fe-exec.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-exec.c,v retrieving revision 1.86 diff -u -c -IHeader -I$Id: -r1.86 fe-exec.c cvs diff: conflicting specifications of output style *** fe-exec.c 1999/11/11 00:10:14 1.86 --- fe-exec.c 2000/01/14 22:47:07 *************** *** 13,18 **** --- 13,19 ---- */ #include <errno.h> #include <ctype.h> + #include <fcntl.h>#include "postgres.h"
#include "libpq-fe.h"
***************
*** 24,30 ****
#include <unistd.h>
#endif- /* keep this in same order as ExecStatusType in libpq-fe.h */ const char *const pgresStatus[] = { "PGRES_EMPTY_QUERY", --- 25,30 ---- *************** *** 514,526 **** conn->curTuple = NULL;/* send the query to the backend; */
! /* the frontend-backend protocol uses 'Q' to designate queries */
! if (pqPutnchar("Q", 1, conn) ||
! pqPuts(query, conn) ||
! pqFlush(conn))
{
! handleSendFailure(conn);
! return 0;
}/* OK, it's launched! */ --- 514,566 ---- conn->curTuple = NULL;/* send the query to the backend; */
!
! /*
! * in order to guarantee that we don't send a partial query
! * where we would become out of sync with the backend and/or
! * block during a non-blocking connection we must first flush
! * the send buffer before sending more data
! *
! * an alternative is to implement 'queue reservations' where
! * we are able to roll up a transaction
! * (the 'Q' along with our query) and make sure we have
! * enough space for it all in the send buffer.
! */
! if (pqIsnonblocking(conn))
{
! /*
! * the buffer must have emptied completely before we allow
! * a new query to be buffered
! */
! if (pqFlush(conn))
! return 0;
! /* 'Q' == queries */
! /* XXX: if we fail here we really ought to not block */
! if (pqPutnchar("Q", 1, conn) ||
! pqPuts(query, conn))
! {
! handleSendFailure(conn);
! return 0;
! }
! /*
! * give the data a push, ignore the return value as
! * ConsumeInput() will do any aditional flushing if needed
! */
! (void) pqFlush(conn);
! }
! else
! {
! /*
! * the frontend-backend protocol uses 'Q' to
! * designate queries
! */
! if (pqPutnchar("Q", 1, conn) ||
! pqPuts(query, conn) ||
! pqFlush(conn))
! {
! handleSendFailure(conn);
! return 0;
! }
}/* OK, it's launched! */ *************** *** 574,580 **** --- 614,630 ---- * we will NOT block waiting for more input. */ if (pqReadData(conn) < 0) + { + /* + * for non-blocking connections + * try to flush the send-queue otherwise we may never get a + * responce for something that may not have already been sent + * because it's in our write buffer! + */ + if (pqIsnonblocking(conn)) + (void) pqFlush(conn); return 0; + } /* Parsing of the data waits till later. */ return 1; } *************** *** 1088,1093 **** --- 1138,1153 ---- { PGresult *result; PGresult *lastResult; + bool savedblocking; + + /* + * we assume anyone calling PQexec wants blocking behaviour, + * we force the blocking status of the connection to blocking + * for the duration of this function and restore it on return + */ + savedblocking = pqIsnonblocking(conn); + if (PQsetnonblocking(conn, FALSE) == -1) + return NULL;/*
* Silently discard any prior query result that application didn't
***************
*** 1102,1115 ****
PQclear(result);
printfPQExpBuffer(&conn->errorMessage,
"PQexec: you gotta get out of a COPY state yourself.\n");
! return NULL;
}
PQclear(result);
}/* OK to send the message */
if (!PQsendQuery(conn, query))
! return NULL;/* * For backwards compatibility, return the last result if there are --- 1162,1176 ---- PQclear(result); printfPQExpBuffer(&conn->errorMessage, "PQexec: you gotta get out of a COPY state yourself.\n"); ! /* restore blocking status */ ! goto errout; } PQclear(result); }/* OK to send the message */
if (!PQsendQuery(conn, query))
! goto errout; /* restore blocking status *//* * For backwards compatibility, return the last result if there are *************** *** 1142,1148 **** --- 1203,1217 ---- result->resultStatus == PGRES_COPY_OUT) break; } + + if (PQsetnonblocking(conn, savedblocking) == -1) + return NULL; return lastResult; + + errout: + if (PQsetnonblocking(conn, savedblocking) == -1) + return NULL; + return NULL; }***************
*** 1431,1438 ****
"PQendcopy() -- I don't think there's a copy in progress.\n");
return 1;
}! (void) pqFlush(conn); /* make sure no data is waiting to be sent */
/* Return to active duty */ conn->asyncStatus = PGASYNC_BUSY; --- 1500,1516 ---- "PQendcopy() -- I don't think there's a copy in progress.\n"); return 1; } + + /* + * make sure no data is waiting to be sent, + * abort if we are non-blocking and the flush fails + */ + if (pqFlush(conn) && pqIsnonblocking(conn)) + return (1);! /* non blocking connections may have to abort at this point. */
! if (pqIsnonblocking(conn) && PQisBusy(conn))
! return (1);/* Return to active duty */ conn->asyncStatus = PGASYNC_BUSY; *************** *** 2025,2028 **** --- 2103,2192 ---- return 1; else return 0; + } + + /* PQsetnonblocking: + sets the PGconn's database connection non-blocking if the arg is TRUE + or makes it non-blocking if the arg is FALSE, this will not protect + you from PQexec(), you'll only be safe when using the non-blocking + API + Needs to be called only on a connected database connection. + */ + + int + PQsetnonblocking(PGconn *conn, int arg) + { + int fcntlarg; + + arg = (arg == TRUE) ? 1 : 0; + /* early out if the socket is already in the state requested */ + if (arg == conn->nonblocking) + return (0); + + /* + * to guarantee constancy for flushing/query/result-polling behavior + * we need to flush the send queue at this point in order to guarantee + * proper behavior. + * this is ok because either they are making a transition + * _from_ or _to_ blocking mode, either way we can block them. + */ + /* if we are going from blocking to non-blocking flush here */ + if (!pqIsnonblocking(conn) && pqFlush(conn)) + return (-1); + + + #ifdef USE_SSL + if (conn->ssl) + { + printfPQExpBuffer(&conn->errorMessage, + "PQsetnonblocking() -- not supported when using SSL\n"); + return (-1); + } + #endif /* USE_SSL */ + + #ifndef WIN32 + fcntlarg = fcntl(conn->sock, F_GETFL, 0); + if (fcntlarg == -1) + return (-1); + + if ((arg == TRUE && + fcntl(conn->sock, F_SETFL, fcntlarg | O_NONBLOCK) == -1) || + (arg == FALSE && + fcntl(conn->sock, F_SETFL, fcntlarg & ~O_NONBLOCK) == -1)) + #else + fcntlarg = arg; + if (ioctlsocket(conn->sock, FIONBIO, &fcntlarg) != 0) + #endif + { + printfPQExpBuffer(&conn->errorMessage, + "PQsetblocking() -- unable to set nonblocking status to %s\n", + arg == TRUE ? "TRUE" : "FALSE"); + return (-1); + } + + conn->nonblocking = arg; + + /* if we are going from non-blocking to blocking flush here */ + if (pqIsnonblocking(conn) && pqFlush(conn)) + return (-1); + + return (0); + } + + /* return the blocking status of the database connection, TRUE == nonblocking, + FALSE == blocking + */ + int + PQisnonblocking(const PGconn *conn) + { + + return (pqIsnonblocking(conn)); + } + + /* try to force data out, really only useful for non-blocking users */ + int + PQflush(PGconn *conn) + { + + return (pqFlush(conn)); } Index: fe-misc.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-misc.c,v retrieving revision 1.33 diff -u -c -IHeader -I$Id: -r1.33 fe-misc.c cvs diff: conflicting specifications of output style *** fe-misc.c 1999/11/30 03:08:19 1.33 --- fe-misc.c 2000/01/12 03:12:14 *************** *** 86,91 **** --- 86,122 ---- { size_t avail = Max(conn->outBufSize - conn->outCount, 0);+ /* + * if we are non-blocking and the send queue is too full to buffer this + * request then try to flush some and return an error + */ + if (pqIsnonblocking(conn) && nbytes > avail && pqFlush(conn)) + { + /* + * even if the flush failed we may still have written some + * data, recalculate the size of the send-queue relative + * to the amount we have to send, we may be able to queue it + * afterall even though it's not sent to the database it's + * ok, any routines that check the data coming from the + * database better call pqFlush() anyway. + */ + if (nbytes > Max(conn->outBufSize - conn->outCount, 0)) + { + printfPQExpBuffer(&conn->errorMessage, + "pqPutBytes -- pqFlush couldn't flush enough" + " data: space available: %d, space needed %d\n", + Max(conn->outBufSize - conn->outCount, 0), nbytes); + return EOF; + } + } + + /* + * is the amount of data to be sent is larger than the size of the + * output buffer then we must flush it to make more room. + * + * the code above will make sure the loop conditional is never + * true for non-blocking connections + */ while (nbytes > avail) { memcpy(conn->outBuffer + conn->outCount, s, avail); *************** *** 548,553 **** --- 579,592 ---- return EOF; }+ /* + * don't try to send zero data, allows us to use this function + * without too much worry about overhead + */ + if (len == 0) + return (0); + + /* while there's still data to send */ while (len > 0) { /* Prevent being SIGPIPEd if backend has closed the connection. */ *************** *** 556,561 **** --- 595,601 ---- #endifint sent; + #ifdef USE_SSL if (conn->ssl) sent = SSL_write(conn->ssl, ptr, len); *************** *** 585,590 **** --- 625,632 ---- case EWOULDBLOCK: break; #endif + case EINTR: + continue;case EPIPE:
#ifdef ECONNRESET
***************
*** 616,628 ****
ptr += sent;
len -= sent;
}
if (len > 0)
{
/* We didn't send it all, wait till we can send more */- /* At first glance this looks as though it should block. I think - * that it will be OK though, as long as the socket is - * non-blocking. */ if (pqWait(FALSE, TRUE, conn)) return EOF; } --- 658,688 ---- ptr += sent; len -= sent; } + if (len > 0) { /* We didn't send it all, wait till we can send more */ + + /* + * if the socket is in non-blocking mode we may need + * to abort here + */ + #ifdef USE_SSL + /* can't do anything for our SSL users yet */ + if (conn->ssl == NULL) + { + #endif + if (pqIsnonblocking(conn)) + { + /* shift the contents of the buffer */ + memmove(conn->outBuffer, ptr, len); + conn->outCount = len; + return EOF; + } + #ifdef USE_SSL + } + #endifif (pqWait(FALSE, TRUE, conn)) return EOF; } Index: libpq-fe.h =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-fe.h,v retrieving revision 1.54 diff -u -c -IHeader -I$Id: -r1.54 libpq-fe.h cvs diff: conflicting specifications of output style *** libpq-fe.h 2000/01/14 05:33:15 1.54 --- libpq-fe.h 2000/01/14 22:45:33 *************** *** 261,266 **** --- 261,273 ---- extern int PQgetlineAsync(PGconn *conn, char *buffer, int bufsize); extern int PQputnbytes(PGconn *conn, const char *buffer, int nbytes); extern int PQendcopy(PGconn *conn); + + /* Set blocking/nonblocking connection to the backend */ + extern int PQsetnonblocking(PGconn *conn, int arg); + extern int PQisnonblocking(const PGconn *conn); + + /* Force the write buffer to be written (or at least try) */ + extern int PQflush(PGconn *conn);/* * "Fast path" interface --- not really recommended for application Index: libpq-int.h =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-int.h,v retrieving revision 1.15 diff -u -c -IHeader -I$Id: -r1.15 libpq-int.h cvs diff: conflicting specifications of output style *** libpq-int.h 2000/01/14 05:33:15 1.15 --- libpq-int.h 2000/01/14 18:32:51 *************** *** 214,219 **** --- 214,222 ---- int inEnd; /* offset to first position after avail * data */+ int nonblocking; /* whether this connection is using a blocking + * socket to the backend or not */ + /* Buffer for data not yet sent to backend */ char *outBuffer; /* currently allocated buffer */ int outBufSize; /* allocated size of buffer */ *************** *** 297,301 **** --- 300,310 ---- #define strerror(A) (sys_errlist[(A)]) #endif /* sunos4 */ #endif /* !strerror */ + + /* + * this is so that we can check is a connection is non-blocking internally + * without the overhead of a function call + */ + #define pqIsnonblocking(conn) (conn->nonblocking)#endif /* LIBPQ_INT_H */
on a side note miscadmin.h causes problems on FreeBSD because it uses
pid_t without having included sys/types.hthanks!
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]************
From bouncefilter Fri Jan 14 10:07:16 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA98045
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 10:06:34 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id LAA86227;
Fri, 14 Jan 2000 11:05:53 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 14 Jan 2000 11:05:53 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Mike Mascari <mascarm@mascari.com>,
Bruce Momjian <pgman@candle.pha.pa.us>,
Tatsuo Ishii <t-ishii@sra.co.jp>, tgl@sss.pgh.pa.us, xun@cs.ucsb.edu,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: <3.0.1.32.20000113210831.01081270@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0001141057590.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 Jan 2000, Don Baccus wrote:
So, what's the deal, here...is the goal the Big Time or not?
If it means adopting one vendors concept of what the world should look
like...not.
I *hate* the way Oracle sets up tablespaces ... where i have to pre-guess
the size of my data and allocate space accordingly...what if my table
never does reach that critical mass? I've just wasted X meg of space ...
I hate the way that Oracle starts up something like 4 processes for every
database, when the server is started...
I think the route we've taken since day one, and hope that we continue
along it...we've created "hacks" along the way to appease users of the
different vendors for SQL relateed issues, but our underlying structure
has stayed, I think, pretty unique...
We haven't been designing a FreeOracle...we've been working on and
designing a Free, full featured RDBMS that follows the specifications laid
down ... with our own PostgreSQLism's thrown in here and there ...
If that happens to follow what one vendor happens to have done as far as
their implementation, great...but there has been no conscious effort to do
so that I'm aware of...
Just look at the whole OUTER JOIN issue ... *shrug*
I *like* the fact that we come up with original ideas/solutions to
problems, that make use of *existing* technologies ...
I liked the thread about moving indexes and tables to seperate file
systems, and hope we can implement something that will make it something
that does't require 'ln's, but I definitely don't like Oracle's way of
doing things ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 14 10:13:12 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA98914
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 10:12:20 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA29357;
Fri, 14 Jan 2000 10:11:26 -0500 (EST)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-reply-to: <Pine.GSO.3.96.SK.1000114120043.6554G-100000@ra>
References: <Pine.GSO.3.96.SK.1000114120043.6554G-100000@ra>
Comments: In-reply-to Oleg Bartunov <oleg@sai.msu.su>
message dated "Fri, 14 Jan 2000 12:04:32 +0300"
Date: Fri, 14 Jan 2000 10:11:26 -0500
Message-ID: <29354.947862686@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Oleg Bartunov <oleg@sai.msu.su> writes:
The selects that such sites spew forth are handled wonderfully
by Postgres now, with MVCC and the change that stops the update
of pg_log after read-only selects.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Does plain 6.5.3 handle read-only selects in this way ?
AFAIR that logic is in 6.5.*. (Vadim would remember better, since he
put it in.) But keep in mind that a SELECT is read-only just to the
extent that it is hitting previously committed tuples. The first visit
to a newly committed-good or newly committed-dead tuple will cause an
update and write-back of the tuple's status flags --- whether that visit
happens in SELECT or anything else.
It occurs to me that the no-log-update logic could probably be improved
on. The test to see whether a log update is needed looks at whether any
buffers have been written. A SELECT that marks someone else's tuples as
known-committed will look like it needs to be committed in pg_log
... but it doesn't really need it. Perhaps Vadim is planning to fix
this in the WAL rewrite.
regards, tom lane
From bouncefilter Fri Jan 14 10:04:11 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA97693
for <pgsql-hackers@hub.org>; Fri, 14 Jan 2000 10:03:34 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA09078;
Fri, 14 Jan 2000 15:12:06 GMT
Sender: lockhart@hub.org
Message-ID: <387F3CC6.73F6BA7C@alumni.caltech.edu>
Date: Fri, 14 Jan 2000 15:12:06 +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: Michael Robinson <robinson@netrinsics.com>
CC: pgsql-hackers@hub.org
Subject: Re: [HACKERS] Copy from/to asymmetry
References: <200001130551.NAA77189@netrinsics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The GMT+8 format is part of the POSIX standard (at least according to
the zoneinfo source file). In the meantime, I've created a new zoneinfo
file with ISO "+0800" format, as a workaround. (To make matters worse, I
discovered that POSIX GMT+8 == ISO -0800 ; in other words, the semantics of
the sign character are reversed in the two standards.)
Yuck.
Perhaps, if the system supports strptime(), this function could be used as
a last-ditch effort by ParseDateTime before returning an error. That would
solve all cases where the datetime_in timezone equals the system timezone
setting.
How? strptime() needs a formatting string, so you would somehow need
to set it beforehand to *exactly* the correct value. And...
Or, maybe just use strptime() outright. I don't know, it's just a suggestion.
The other problem with using system-supplied routines for this is that
they invariably fail for years outside the Unix system time range. So
we need to do enough parsing to figure out what the year might be, and
by that time we may as well finish it ourselves...
Anyway, I'll be looking at it sometime soon.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 14 10:07:11 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA98038
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 10:06:30 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA09085;
Fri, 14 Jan 2000 15:14:22 GMT
Sender: lockhart@hub.org
Message-ID: <387F3D4E.AE8A8CB4@alumni.caltech.edu>
Date: Fri, 14 Jan 2000 15:14: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: Don Baccus <dhogaza@pacifier.com>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Informix and OUTER join syntax
References: <From "(env:" "pgman)" at "Jan 12, 2000 03:38:10 pm">
<3.0.1.32.20000112131308.01051970@mail.pacifier.com>
<3.0.1.32.20000113065514.01066e10@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
And if I understand SQL92 correctly, if tab1, tab2, and tab3 only
share col1 in common, then you can further simplify:
SELECT *
FROM tab1 NATURAL RIGHT JOIN (tab2 NATURAL RIGHT JOIN tab3)
Is that right? ...and some
might argue this is less clear than explicitly listing the column(s)
to join on.
But this is "natural", right? ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 14 10:07:11 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA98061
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 10:06:40 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA09092;
Fri, 14 Jan 2000 15:15:01 GMT
Sender: lockhart@hub.org
Message-ID: <387F3D75.2142E2A0@alumni.caltech.edu>
Date: Fri, 14 Jan 2000 15:15:01 +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: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Status request for 7.0
References: <Pine.LNX.3.96.1000113105655.8168F-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm finishing to_char()'s family routines now (it is 8 routines).
I'd like remove it to main tree next week (I will send patch).
Agree Thomas?
Should be fine.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 14 10:53:12 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA08830
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 10:52:54 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA09142;
Fri, 14 Jan 2000 16:00:32 GMT
Sender: lockhart@hub.org
Message-ID: <387F4820.10097FAB@alumni.caltech.edu>
Date: Fri, 14 Jan 2000 16:00:32 +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 <pgman@candle.pha.pa.us>
CC: Don Baccus <dhogaza@pacifier.com>, Mike Mascari <mascarm@mascari.com>,
Tatsuo Ishii <t-ishii@sra.co.jp>, tgl@sss.pgh.pa.us, xun@cs.ucsb.edu,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
References: <200001140622.BAA04385@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I thought Phil was a big fan of ours.
He wants to be. But ihho we are not yet worthy :))
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 14 11:42:22 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA22804
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 11:41:54 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA19743;
Fri, 14 Jan 2000 08:39:49 -0800 (PST)
Message-Id: <3.0.1.32.20000114080624.010729c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 14 Jan 2000 08:06:24 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed
Cc: Mike Mascari <mascarm@mascari.com>, Tatsuo Ishii <t-ishii@sra.co.jp>,
tgl@sss.pgh.pa.us, xun@cs.ucsb.edu, pgsql-hackers@postgreSQL.org
In-Reply-To: <200001140622.BAA04385@candle.pha.pa.us>
References: <3.0.1.32.20000113210831.01081270@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 01:22 AM 1/14/00 -0500, Bruce Momjian wrote:
Look - in case there's any doubt, I'm not trying to toast Postgres,
I'm a fan, interested in getting more involved in the development
scenario. I raised this issue because Xun raised some "really big
database issues which I as a database theorist have an interest in".
My biggest sin if any is to try to paint the horizon, at this point.
Philip Greenspun still says that those of us (including employee
#3 or so of his company, Ben) who are interested in Postgres are "losers"
by definition (Ben no longer works there). Meanwhile, folks like BenI thought Phil was a big fan of ours.
He's moderated his opinion considerably over the past several
months. To some extent you might say he's had his opinion
moderated for him. Feel free to extrapolate :)
(not just me, or even primarily me, but folks like Ben Adida who've
worked with Philip at MIT and then Ars Digita are deeply interested
in seeing a successful version of the Ars Digita toolkit based on
Postgres, Ben also coordinates AOLserver releases for Ars Digita/MIT)
Still, as recently as six months ago Philip flamed some English gent
in public for suggesting an ACS port to Postgres or another free
or cheap RDBMS, and went on the e-mail the guy nasty notes in private.
Or so the gent sez.
I know Philip was surprised and impressed by the great leap forward
embodied by 6.5.
As was I - I'd given up on 6.4.
But Philip is mostly concerned with the clients that feed his very
rapidly growing company, and while he'll release his toolkit sources
still tells folks you really need Oracle. His most recent criticism
of Postgres shrunk to two items (not referential integrity, no outer
joins), one of which has disappeared in current sources.
Apparently he doesn't know how weak large object support is, I won't
tell him, either...
Anyway, this isn't about Philip's opinions so much as the fact that
Postgres has had a very spotty reputation in the past, but is improving
so quickly and predictably that its reputation is also steadily
improving. He serves as an example of someone who's convinced that
Postgres has greatly improved but remains skeptical that it's improved
enough to do serious work with.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 11:42:16 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA22729
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 11:41:23 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA19748;
Fri, 14 Jan 2000 08:39:50 -0800 (PST)
Message-Id: <3.0.1.32.20000114080811.01072620@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 14 Jan 2000 08:08:11 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: Multiple Spindles ( Was: Re: [HACKERS]
[hackers]development suggestion needed )
Cc: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
Xun Cheng <xun@cs.ucsb.edu>, pgsql-hackers@postgreSQL.org
In-Reply-To: <200001140616.BAA04275@candle.pha.pa.us>
References: <3.0.1.32.20000113213141.01081b00@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 01:16 AM 1/14/00 -0500, Bruce Momjian wrote:
We don't block people for working on ietms. However, we do try and set
priorities based on the open items we have. I hope we don't appear
heavy-handed in this regard.
Not at all. And though I've triggered this dicussion, I'd be the
first to agree it is minor in importance compared to things like
outer joins, the WAL implementation, and Jan's large object work.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 11:41:22 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA22600
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 11:40:52 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA19756;
Fri, 14 Jan 2000 08:39:50 -0800 (PST)
Message-Id: <3.0.1.32.20000114081444.010896f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 14 Jan 2000 08:14:44 -0800
To: Adriaan Joubert <a.joubert@albourne.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Xun Cheng <xun@cs.ucsb.edu>,
pgsql-hackers@postgresql.org
In-Reply-To: <387ED731.DCEA1092@albourne.com>
References: <200001140046.QAA17082@brubeck.cs.ucsb.edu>
<200001140046.QAA17082@brubeck.cs.ucsb.edu>
<3.0.1.32.20000113174339.01078360@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 07:58 AM 1/14/00 +0000, Adriaan Joubert wrote:
You don't get to do either of the latter two unless you write a
raw-device storage manager
Not within a single filesystem, but scattering things across spindles
could be done without a raw-device storage manager :)Yes, but seen how cheap RAID arrays have become? I know disks are getting
bigger as well, and many people will opt for a single disk, but there may
be more urgent things to fix than something for which a hardware solution
already exists. And lets face it: a database ought to be on RAID
anyway,unless somebody wants to write Tandem-style mirrored disks.... ;-)
Don't need to write Tandem-style mirrored disks, the Linux kernal
implements mirrored file systems for me. I can mirror UW2 disks in
software for $189/spindle (current cost of an IBM Deskstar UW2 7200 RPM
4.5 GB spindle here in Oregon), the fancier RAID arrays still aren't that
cheap.
The cheapest RAID interfaces just hide the mirroring from you. There's
a tier up that take a cluster of mirrored (or RAID 5'd) platters and
present them to you as a single large disk - these remove a lot of
one's control over spindle placement, sure. My guess is that some
folks don't view this as a plus...
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 11:41:17 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA22606
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 11:40:59 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA19768;
Fri, 14 Jan 2000 08:39:52 -0800 (PST)
Message-Id: <3.0.1.32.20000114081533.0108f8d0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 14 Jan 2000 08:15:33 -0800
To: Oleg Bartunov <oleg@sai.msu.su>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
In-Reply-To: <Pine.GSO.3.96.SK.1000114120043.6554G-100000@ra>
References: <3.0.1.32.20000113181933.010771d0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:04 PM 1/14/00 +0300, Oleg Bartunov wrote:
The selects that such sites spew forth are handled wonderfully
by Postgres now, with MVCC and the change that stops the update
of pg_log after read-only selects.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Just curious,
Does plain 6.5.3 handle read-only selects in this way ?
Yes.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 11:41:18 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA22578
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 11:40:44 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA19780;
Fri, 14 Jan 2000 08:39:54 -0800 (PST)
Message-Id: <3.0.1.32.20000114082201.010917b0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 14 Jan 2000 08:22:01 -0800
To: Malcolm Beattie <mbeattie@sable.ox.ac.uk>, pgsql-hackers@postgresql.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed
In-Reply-To: <E12944k-0004gn-00@sable.ox.ac.uk>
References: <3.0.1.32.20000113212111.010834c0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:35 AM 1/14/00 +0000, Malcolm Beattie wrote:
Linux has software raid (often called "md") with most of the usual
bells and whistles (RAID0, RAID1, RAID5, RAID0+1, hot spares,
background reconstruction).
Yes, I know.
You can patch in LVM (logical volume
management) although the distributions of which I am aware don't ship
it ready-patched.
Right.
I think that means I'm in violent agreement with you on the db side
but this reply does give me a chance to point out that Linux isn't
missing the functionality you haven't noticed in it :-).
Linux also has a journaling filesystem available, if you're brave and
wanting to be at the bleeding edge. That's sort of like using next
week's Postgres development sources in yesterday's production environment,
though - a bit risky :)
I should've made it clear that when I was talking about the current,
widespread releases that I'm familiar with. RedHat, in particular.
The RAID stuff is out-of-the-box supported today, fancier stuff
like the journaling file-system will be out-of-the-box supported before
too much longer. It's exciting to see Linux improve steadily just as it's
exciting to see Postgres improve steadily.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 11:42:19 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA22801
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 11:41:49 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA19806;
Fri, 14 Jan 2000 08:39:56 -0800 (PST)
Message-Id: <3.0.1.32.20000114083030.01095170@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 14 Jan 2000 08:30:30 -0800
To: The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed
Cc: Mike Mascari <mascarm@mascari.com>,
Bruce Momjian <pgman@candle.pha.pa.us>,
Tatsuo Ishii <t-ishii@sra.co.jp>, tgl@sss.pgh.pa.us, xun@cs.ucsb.edu,
pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.BSF.4.21.0001141057590.46499-100000@thelab.hub.org>
References: <3.0.1.32.20000113210831.01081270@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:05 AM 1/14/00 -0400, The Hermit Hacker wrote:
On Thu, 13 Jan 2000, Don Baccus wrote:
So, what's the deal, here...is the goal the Big Time or not?
If it means adopting one vendors concept of what the world should look
like...not.
I *hate* the way Oracle sets up tablespaces ... where i have to pre-guess
the size of my data and allocate space accordingly...what if my table
never does reach that critical mass? I've just wasted X meg of space ...
And I'm not suggesting that anything like this level of (as I described
it in my previous note) anal retentive control be implemented. Anal
retentive IT managers won't be happy unless they're paying Oracle
$25/power unit anyway.
But being able to spread tables and indices around several spindles
would improve scalability. I think the very simple approach that's
been kicked around would work for anyone we care about (me!:)
I mentioned the Oracle details in part because it's not clear to me
how much folks here know about Oracle. I don't know all that much,
only enough to know that any database that initializes its defaults
to useless values is a pain in the ass in ways that customers shouldn't
put up with. I don't understand Oracle's approach, there, seducing you
into letting it build a default installation which is then virtually
useless.
We haven't been designing a FreeOracle...
I'm certainly not arguing for this...remember, I did argue against
"(+)" in favor of SQL 92 outer joins :)
I liked the thread about moving indexes and tables to seperate file
systems, and hope we can implement something that will make it something
that does't require 'ln's, but I definitely don't like Oracle's way of
doing things ...
I agree...I was simply providing a datapoint, not suggesting it was one
Postgres should emulate.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 11:42:18 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA22814
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 11:42:01 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA19811;
Fri, 14 Jan 2000 08:39:57 -0800 (PST)
Message-Id: <3.0.1.32.20000114083341.010954c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 14 Jan 2000 08:33:41 -0800
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: Informix and OUTER join syntax
Cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <387F3D4E.AE8A8CB4@alumni.caltech.edu>
References: <From "(env:" "pgman)" at "Jan 12, 2000 03:38:10 pm">
<3.0.1.32.20000112131308.01051970@mail.pacifier.com>
<3.0.1.32.20000113065514.01066e10@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 03:14 PM 1/14/00 +0000, Thomas Lockhart wrote:
And if I understand SQL92 correctly, if tab1, tab2, and tab3 only
share col1 in common, then you can further simplify:
SELECT *
FROM tab1 NATURAL RIGHT JOIN (tab2 NATURAL RIGHT JOIN tab3)
Is that right? ...and some
might argue this is less clear than explicitly listing the column(s)
to join on.But this is "natural", right? ;)
Cute! I have no experience trying to read and understand other
people's queries using SQL 92 outer joins so can't really say
whether the "natural" style is more clear than the more cumbersome
explicit notation.
I think both forms are quite readable, though.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 11:41:20 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA22605
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 11:40:59 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA19821;
Fri, 14 Jan 2000 08:39:58 -0800 (PST)
Message-Id: <3.0.1.32.20000114083722.01094010@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 14 Jan 2000 08:37:22 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, Oleg Bartunov <oleg@sai.msu.su>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed
Cc: pgsql-hackers@postgresql.org
In-Reply-To: <29354.947862686@sss.pgh.pa.us>
References: <Pine.GSO.3.96.SK.1000114120043.6554G-100000@ra>
<Pine.GSO.3.96.SK.1000114120043.6554G-100000@ra>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:11 AM 1/14/00 -0500, Tom Lane wrote:
Oleg Bartunov <oleg@sai.msu.su> writes:
The selects that such sites spew forth are handled wonderfully
by Postgres now, with MVCC and the change that stops the update
of pg_log after read-only selects.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Does plain 6.5.3 handle read-only selects in this way ?AFAIR that logic is in 6.5.*. (Vadim would remember better, since he
put it in.)
It is. I'd notice right away if it wasn't, the decibel level on my
little database server would go 'way up because it went 'way down when
I applied the patch to my 6.5 beta. It sits six inches from me so
I'd know for sure!
It occurs to me that the no-log-update logic could probably be improved
on. The test to see whether a log update is needed looks at whether any
buffers have been written. A SELECT that marks someone else's tuples as
known-committed will look like it needs to be committed in pg_log
... but it doesn't really need it. Perhaps Vadim is planning to fix
this in the WAL rewrite.
No idea if he is or isn't, but the patch is very simple and is based
on whether or not buffers got dirty, not whether or not the select
itself changed anything, IIRC.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 13:54:16 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA55430
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 13:53:23 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id LAA11552;
Fri, 14 Jan 2000 11:14:30 -0800 (PST)
Date: Fri, 14 Jan 2000 11:14:30 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org,
scrappy@hub.org
Subject: Revised nonblocking patches + quasi docs
Message-ID: <20000114111430.A824@fw.wintelcom.net>
References: <Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
<Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
<3.0.1.32.20000109070102.0101d7b0@mail.pacifier.com>
<10004.947433028@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <10004.947433028@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Sun, Jan 09, 2000 at 10:50:28AM -0500
* Tom Lane <tgl@sss.pgh.pa.us> [000109 08:18] wrote:
Don Baccus <dhogaza@pacifier.com> writes:
At 05:27 PM 1/8/00 -0500, Tom Lane wrote:
I also object strongly to the lack of documentation.
... I know there are some folks who aren't native-english speakers, so
perhaps you don't want to require that the implementor of such patches
provide the final documentation wording. But the information should
be there and spelled out in a form that can be very easily moved to
the docs.Oh, absolutely. Thomas, our master of the docs, has always had the
policy of "give me some words, I'll take care of formatting and
editing..."I was probably too harsh on Alfred last night, since in fact his code
was fairly well commented, and some minimal doco could have been
extracted from the routine headers. But on a change like this, I think
some paragraphs of coherent high-level explanation are needed: what it
does, when and why you'd use it. I didn't see that anywhere...
I've actually been trying to work on the sgml and failing miserably,
I have no clue how this stuff works (sgml compilation) are you asking
for a couple of paragraphs that describe the proposed changes?
If so I hope this suffices, if not some help on building the sgml
would be much appreciated:
--------
Summary:
First and foremost, great pains have been taken so that there
are _no_ compatibility issues.
If a 6.5.3 libpq program should not behave any differently
with this patches in place, all they do is offer a step closer
to a truly non-blocking connection to the backend and address
some issues with non-blocking connections.
----
Added functions:
int PQisnonblocking(static PGconn *conn);
returns whether or not the socket is in blocking mode, however...
it doesn't actually check the socket flags, it relies on the user
to call 'PQsetnonblocking()' to keep the internal state of libpq
sane. users should no longer use 'PQsocket()' to retrieve the
socket and 'manually' ioctl/fcntl it to non-blocking
returns TRUE if the socket has been set to blocking more, FALSE
if the socket is blocking
int PQflush(PGconn *conn);
flush the send-queue to the backend, just make this visible to the
user for convience, as the internal function works, 0 for success,
EOF for any failure.
int PQsetnonblocking(PGconn *conn, int arg);
actually set the connection to the backend to blocking or
non-blocking arg should be set to TRUE to set the connection to
non-blocking or FALSE to set it blocking.
there's an implied blocking flush of the send-queue which is
really ok as the user is either 'going into' or 'returning from'
a blocking state
returns 0 for success, -1 for failure
---
New functionality:
PQsetblocking() allows libpq to know what behavior the user really
wants, the user will not block sending data to the backend,
potentially if i had a constant stream of data and was doing a
COPYIN it'd never finish because unless the backend lost the
connection I would block while sending until the backend can take
more data.
---
Implementation changes:
none should be visible to programs based on 6.5.3's libpq.
programs based on later versions of libpq will notice that
the non-blocking connection functions will set the state of
the connection to non-blocking automatically.
when the connection is set non-blocking pqFlush() will not block
if the sendqueue would be filled by new data inserted into the
the queue.
functions that poll for data from the backend implicitly _try_
flush the send queue if set to non-blocking. This allows the
polling to act as a context for pushing queued data to the backend.
---
Problems:
We need some sort of send-queue commit reservations so that
there's no chance of us sending a partial queury down the pipe
to the backend, right now this is hacked around by potentially
blocking in non-blocking mode if something 'goes terribly wrong'
I plan to fix this.
---
Quirks:
PQexec() assumes the caller wants blocking behavior and will set the
connection to blocking for the duration of the PQexec() call, it will
then restore it
---
Internal changes:
new field in PGconn 'int nonblocking' set to 1 if the connection is
nonblocking, 0 if blocking (default)
macro pqIsnonblocking(PGconn) to avoid a function call to check blocking
status (only visible if libpq-int.h is included)
the internal function connectMakeNonblocking() has been replaced with
PQsetblocking()
restart a send if EINTR is reported during a flush.
---
Lastly:
This is work in progress, I will be working towards making libpq
better at not blocking.
here are the diffs:
Index: fe-connect.c
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.109
diff -u -c -IHeader -I$Id: -r1.109 fe-connect.c
cvs diff: conflicting specifications of output style
*** fe-connect.c 2000/01/14 05:33:15 1.109
--- fe-connect.c 2000/01/14 18:36:54
***************
*** 594,624 ****
return 0;
}-
- /* ----------
- * connectMakeNonblocking -
- * Make a connection non-blocking.
- * Returns 1 if successful, 0 if not.
- * ----------
- */
- static int
- connectMakeNonblocking(PGconn *conn)
- {
- #ifndef WIN32
- if (fcntl(conn->sock, F_SETFL, O_NONBLOCK) < 0)
- #else
- if (ioctlsocket(conn->sock, FIONBIO, &on) != 0)
- #endif
- {
- printfPQExpBuffer(&conn->errorMessage,
- "connectMakeNonblocking -- fcntl() failed: errno=%d\n%s\n",
- errno, strerror(errno));
- return 0;
- }
-
- return 1;
- }
-
/* ----------
* connectNoDelay -
* Sets the TCP_NODELAY socket option.
--- 594,599 ----
***************
*** 789,795 ****
* Ewan Mellor <eem21@cam.ac.uk>.
* ---------- */
#if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL)
! if (!connectMakeNonblocking(conn))
goto connect_errReturn;
#endif --- 764,770 ----
* Ewan Mellor <eem21@cam.ac.uk>.
* ---------- */
#if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL)
! if (PQsetnonblocking(conn, TRUE) != 0)
goto connect_errReturn;
#endif ***************
*** 898,904 ****
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (!connectMakeNonblocking(conn))
goto connect_errReturn;
#endif
--- 873,879 ----
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (PQsetnonblocking(conn, TRUE) != 0)
goto connect_errReturn;
#endif ***************
*** 1702,1707 ****
--- 1677,1683 ----
conn->inBuffer = (char *) malloc(conn->inBufSize);
conn->outBufSize = 8 * 1024;
conn->outBuffer = (char *) malloc(conn->outBufSize);
+ conn->nonblocking = FALSE;
initPQExpBuffer(&conn->errorMessage);
initPQExpBuffer(&conn->workBuffer);
if (conn->inBuffer == NULL ||
***************
*** 1812,1817 ****
--- 1788,1794 ----
conn->lobjfuncs = NULL;
conn->inStart = conn->inCursor = conn->inEnd = 0;
conn->outCount = 0;
+ conn->nonblocking = FALSE;}
Index: fe-exec.c
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-exec.c,v
retrieving revision 1.86
diff -u -c -IHeader -I$Id: -r1.86 fe-exec.c
cvs diff: conflicting specifications of output style
*** fe-exec.c 1999/11/11 00:10:14 1.86
--- fe-exec.c 2000/01/14 22:47:07
***************
*** 13,18 ****
--- 13,19 ----
*/
#include <errno.h>
#include <ctype.h>
+ #include <fcntl.h> #include "postgres.h"
#include "libpq-fe.h"
***************
*** 24,30 ****
#include <unistd.h>
#endif
-
/* keep this in same order as ExecStatusType in libpq-fe.h */
const char *const pgresStatus[] = {
"PGRES_EMPTY_QUERY",
--- 25,30 ----
***************
*** 514,526 ****
conn->curTuple = NULL; /* send the query to the backend; */
! /* the frontend-backend protocol uses 'Q' to designate queries */
! if (pqPutnchar("Q", 1, conn) ||
! pqPuts(query, conn) ||
! pqFlush(conn))
{
! handleSendFailure(conn);
! return 0;
}
/* OK, it's launched! */
--- 514,566 ----
conn->curTuple = NULL; /* send the query to the backend; */
!
! /*
! * in order to guarantee that we don't send a partial query
! * where we would become out of sync with the backend and/or
! * block during a non-blocking connection we must first flush
! * the send buffer before sending more data
! *
! * an alternative is to implement 'queue reservations' where
! * we are able to roll up a transaction
! * (the 'Q' along with our query) and make sure we have
! * enough space for it all in the send buffer.
! */
! if (pqIsnonblocking(conn))
{
! /*
! * the buffer must have emptied completely before we allow
! * a new query to be buffered
! */
! if (pqFlush(conn))
! return 0;
! /* 'Q' == queries */
! /* XXX: if we fail here we really ought to not block */
! if (pqPutnchar("Q", 1, conn) ||
! pqPuts(query, conn))
! {
! handleSendFailure(conn);
! return 0;
! }
! /*
! * give the data a push, ignore the return value as
! * ConsumeInput() will do any aditional flushing if needed
! */
! (void) pqFlush(conn);
! }
! else
! {
! /*
! * the frontend-backend protocol uses 'Q' to
! * designate queries
! */
! if (pqPutnchar("Q", 1, conn) ||
! pqPuts(query, conn) ||
! pqFlush(conn))
! {
! handleSendFailure(conn);
! return 0;
! }
}
/* OK, it's launched! */
***************
*** 574,580 ****
--- 614,630 ----
* we will NOT block waiting for more input.
*/
if (pqReadData(conn) < 0)
+ {
+ /*
+ * for non-blocking connections
+ * try to flush the send-queue otherwise we may never get a
+ * responce for something that may not have already been sent
+ * because it's in our write buffer!
+ */
+ if (pqIsnonblocking(conn))
+ (void) pqFlush(conn);
return 0;
+ }
/* Parsing of the data waits till later. */
return 1;
}
***************
*** 1088,1093 ****
--- 1138,1153 ----
{
PGresult *result;
PGresult *lastResult;
+ bool savedblocking;
+
+ /*
+ * we assume anyone calling PQexec wants blocking behaviour,
+ * we force the blocking status of the connection to blocking
+ * for the duration of this function and restore it on return
+ */
+ savedblocking = pqIsnonblocking(conn);
+ if (PQsetnonblocking(conn, FALSE) == -1)
+ return NULL; /*
* Silently discard any prior query result that application didn't
***************
*** 1102,1115 ****
PQclear(result);
printfPQExpBuffer(&conn->errorMessage,
"PQexec: you gotta get out of a COPY state yourself.\n");
! return NULL;
}
PQclear(result);
}
/* OK to send the message */
if (!PQsendQuery(conn, query))
! return NULL;
/*
* For backwards compatibility, return the last result if there are
--- 1162,1176 ----
PQclear(result);
printfPQExpBuffer(&conn->errorMessage,
"PQexec: you gotta get out of a COPY state yourself.\n");
! /* restore blocking status */
! goto errout;
}
PQclear(result);
} /* OK to send the message */
if (!PQsendQuery(conn, query))
! goto errout; /* restore blocking status */
/*
* For backwards compatibility, return the last result if there are
***************
*** 1142,1148 ****
--- 1203,1217 ----
result->resultStatus == PGRES_COPY_OUT)
break;
}
+
+ if (PQsetnonblocking(conn, savedblocking) == -1)
+ return NULL;
return lastResult;
+
+ errout:
+ if (PQsetnonblocking(conn, savedblocking) == -1)
+ return NULL;
+ return NULL;
}***************
*** 1431,1438 ****
"PQendcopy() -- I don't think there's a copy in progress.\n");
return 1;
}
! (void) pqFlush(conn); /* make sure no data is waiting to be sent */
/* Return to active duty */
conn->asyncStatus = PGASYNC_BUSY;
--- 1500,1516 ----
"PQendcopy() -- I don't think there's a copy in progress.\n");
return 1;
}
+
+ /*
+ * make sure no data is waiting to be sent,
+ * abort if we are non-blocking and the flush fails
+ */
+ if (pqFlush(conn) && pqIsnonblocking(conn))
+ return (1);! /* non blocking connections may have to abort at this point. */
! if (pqIsnonblocking(conn) && PQisBusy(conn))
! return (1);
/* Return to active duty */
conn->asyncStatus = PGASYNC_BUSY;
***************
*** 2025,2028 ****
--- 2103,2192 ----
return 1;
else
return 0;
+ }
+
+ /* PQsetnonblocking:
+ sets the PGconn's database connection non-blocking if the arg is TRUE
+ or makes it non-blocking if the arg is FALSE, this will not protect
+ you from PQexec(), you'll only be safe when using the non-blocking
+ API
+ Needs to be called only on a connected database connection.
+ */
+
+ int
+ PQsetnonblocking(PGconn *conn, int arg)
+ {
+ int fcntlarg;
+
+ arg = (arg == TRUE) ? 1 : 0;
+ /* early out if the socket is already in the state requested */
+ if (arg == conn->nonblocking)
+ return (0);
+
+ /*
+ * to guarantee constancy for flushing/query/result-polling behavior
+ * we need to flush the send queue at this point in order to guarantee
+ * proper behavior.
+ * this is ok because either they are making a transition
+ * _from_ or _to_ blocking mode, either way we can block them.
+ */
+ /* if we are going from blocking to non-blocking flush here */
+ if (!pqIsnonblocking(conn) && pqFlush(conn))
+ return (-1);
+
+
+ #ifdef USE_SSL
+ if (conn->ssl)
+ {
+ printfPQExpBuffer(&conn->errorMessage,
+ "PQsetnonblocking() -- not supported when using SSL\n");
+ return (-1);
+ }
+ #endif /* USE_SSL */
+
+ #ifndef WIN32
+ fcntlarg = fcntl(conn->sock, F_GETFL, 0);
+ if (fcntlarg == -1)
+ return (-1);
+
+ if ((arg == TRUE &&
+ fcntl(conn->sock, F_SETFL, fcntlarg | O_NONBLOCK) == -1) ||
+ (arg == FALSE &&
+ fcntl(conn->sock, F_SETFL, fcntlarg & ~O_NONBLOCK) == -1))
+ #else
+ fcntlarg = arg;
+ if (ioctlsocket(conn->sock, FIONBIO, &fcntlarg) != 0)
+ #endif
+ {
+ printfPQExpBuffer(&conn->errorMessage,
+ "PQsetblocking() -- unable to set nonblocking status to %s\n",
+ arg == TRUE ? "TRUE" : "FALSE");
+ return (-1);
+ }
+
+ conn->nonblocking = arg;
+
+ /* if we are going from non-blocking to blocking flush here */
+ if (pqIsnonblocking(conn) && pqFlush(conn))
+ return (-1);
+
+ return (0);
+ }
+
+ /* return the blocking status of the database connection, TRUE == nonblocking,
+ FALSE == blocking
+ */
+ int
+ PQisnonblocking(const PGconn *conn)
+ {
+
+ return (pqIsnonblocking(conn));
+ }
+
+ /* try to force data out, really only useful for non-blocking users */
+ int
+ PQflush(PGconn *conn)
+ {
+
+ return (pqFlush(conn));
}
Index: fe-misc.c
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-misc.c,v
retrieving revision 1.33
diff -u -c -IHeader -I$Id: -r1.33 fe-misc.c
cvs diff: conflicting specifications of output style
*** fe-misc.c 1999/11/30 03:08:19 1.33
--- fe-misc.c 2000/01/12 03:12:14
***************
*** 86,91 ****
--- 86,122 ----
{
size_t avail = Max(conn->outBufSize - conn->outCount, 0);+ /*
+ * if we are non-blocking and the send queue is too full to buffer this
+ * request then try to flush some and return an error
+ */
+ if (pqIsnonblocking(conn) && nbytes > avail && pqFlush(conn))
+ {
+ /*
+ * even if the flush failed we may still have written some
+ * data, recalculate the size of the send-queue relative
+ * to the amount we have to send, we may be able to queue it
+ * afterall even though it's not sent to the database it's
+ * ok, any routines that check the data coming from the
+ * database better call pqFlush() anyway.
+ */
+ if (nbytes > Max(conn->outBufSize - conn->outCount, 0))
+ {
+ printfPQExpBuffer(&conn->errorMessage,
+ "pqPutBytes -- pqFlush couldn't flush enough"
+ " data: space available: %d, space needed %d\n",
+ Max(conn->outBufSize - conn->outCount, 0), nbytes);
+ return EOF;
+ }
+ }
+
+ /*
+ * is the amount of data to be sent is larger than the size of the
+ * output buffer then we must flush it to make more room.
+ *
+ * the code above will make sure the loop conditional is never
+ * true for non-blocking connections
+ */
while (nbytes > avail)
{
memcpy(conn->outBuffer + conn->outCount, s, avail);
***************
*** 548,553 ****
--- 579,592 ----
return EOF;
}+ /*
+ * don't try to send zero data, allows us to use this function
+ * without too much worry about overhead
+ */
+ if (len == 0)
+ return (0);
+
+ /* while there's still data to send */
while (len > 0)
{
/* Prevent being SIGPIPEd if backend has closed the connection. */
***************
*** 556,561 ****
--- 595,601 ----
#endif int sent;
+
#ifdef USE_SSL
if (conn->ssl)
sent = SSL_write(conn->ssl, ptr, len);
***************
*** 585,590 ****
--- 625,632 ----
case EWOULDBLOCK:
break;
#endif
+ case EINTR:
+ continue; case EPIPE:
#ifdef ECONNRESET
***************
*** 616,628 ****
ptr += sent;
len -= sent;
}
if (len > 0)
{
/* We didn't send it all, wait till we can send more */
- /* At first glance this looks as though it should block. I think
- * that it will be OK though, as long as the socket is
- * non-blocking. */
if (pqWait(FALSE, TRUE, conn))
return EOF;
}
--- 658,688 ----
ptr += sent;
len -= sent;
}
+
if (len > 0)
{
/* We didn't send it all, wait till we can send more */
+
+ /*
+ * if the socket is in non-blocking mode we may need
+ * to abort here
+ */
+ #ifdef USE_SSL
+ /* can't do anything for our SSL users yet */
+ if (conn->ssl == NULL)
+ {
+ #endif
+ if (pqIsnonblocking(conn))
+ {
+ /* shift the contents of the buffer */
+ memmove(conn->outBuffer, ptr, len);
+ conn->outCount = len;
+ return EOF;
+ }
+ #ifdef USE_SSL
+ }
+ #endif if (pqWait(FALSE, TRUE, conn))
return EOF;
}
Index: libpq-fe.h
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-fe.h,v
retrieving revision 1.54
diff -u -c -IHeader -I$Id: -r1.54 libpq-fe.h
cvs diff: conflicting specifications of output style
*** libpq-fe.h 2000/01/14 05:33:15 1.54
--- libpq-fe.h 2000/01/14 22:45:33
***************
*** 261,266 ****
--- 261,273 ----
extern int PQgetlineAsync(PGconn *conn, char *buffer, int bufsize);
extern int PQputnbytes(PGconn *conn, const char *buffer, int nbytes);
extern int PQendcopy(PGconn *conn);
+
+ /* Set blocking/nonblocking connection to the backend */
+ extern int PQsetnonblocking(PGconn *conn, int arg);
+ extern int PQisnonblocking(const PGconn *conn);
+
+ /* Force the write buffer to be written (or at least try) */
+ extern int PQflush(PGconn *conn); /*
* "Fast path" interface --- not really recommended for application
Index: libpq-int.h
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-int.h,v
retrieving revision 1.15
diff -u -c -IHeader -I$Id: -r1.15 libpq-int.h
cvs diff: conflicting specifications of output style
*** libpq-int.h 2000/01/14 05:33:15 1.15
--- libpq-int.h 2000/01/14 18:32:51
***************
*** 214,219 ****
--- 214,222 ----
int inEnd; /* offset to first position after avail
* data */+ int nonblocking; /* whether this connection is using a blocking
+ * socket to the backend or not */
+
/* Buffer for data not yet sent to backend */
char *outBuffer; /* currently allocated buffer */
int outBufSize; /* allocated size of buffer */
***************
*** 297,301 ****
--- 300,310 ----
#define strerror(A) (sys_errlist[(A)])
#endif /* sunos4 */
#endif /* !strerror */
+
+ /*
+ * this is so that we can check is a connection is non-blocking internally
+ * without the overhead of a function call
+ */
+ #define pqIsnonblocking(conn) (conn->nonblocking)#endif /* LIBPQ_INT_H */
on a side note miscadmin.h causes problems on FreeBSD because it uses
pid_t without having included sys/types.h
thanks!
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
From bouncefilter Fri Jan 14 14:22:17 2000
Received: from onestone.elsinore.klever.net (root@onestone.elsinore.klever.net
[207.175.129.2]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA62311
for <pgsql-hackers@hub.org>; Fri, 14 Jan 2000 14:21:48 -0500 (EST)
(envelope-from sbirch@ironmountainsystems.com)
Received: from ironmountainsystems.com (ppp47.kross.klever.net
[209.203.65.47]) by onestone.elsinore.klever.net (8.8.7/8.8.0)
with ESMTP id LAA13219; Fri, 14 Jan 2000 11:20:27 -0800
Sender: sbirch@onestone.elsinore.klever.net
Message-ID: <387F76FE.DF894E0E@ironmountainsystems.com>
Date: Fri, 14 Jan 2000 11:20:30 -0800
From: Stephen Birch <sbirch@ironmountainsystems.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-SMP i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Adam Walczykiewicz <adam.walczykiewicz@multiuser.com.pl>,
pgsql-hackers@hub.org
Subject: Re: [HACKERS] Uninstalling PostgreSQL ??!!
References: <Pine.GSO.4.02A.10001131634260.6438-100000@Pingvin.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Does the PostgreSQL project officially only support Red Hat - I sure would like to see SuSE supported and
mentioned instead of just Red hat. I'd be happy to generate SuSE RPMs for distribution via the PostgreSQL
site.
I thought I saw some discussion about this issue earlier.
Who generates the SuSE rpms distributed with the SuSE release. These are of no value to me because I wish
to use /usr/local/pgsql for PostgreSQL.
Steve
Peter Eisentraut wrote:
On Thu, 13 Jan 2000, Adam Walczykiewicz wrote:
This message was sent from Geocrawler.com by "Adam Walczykiewicz" <adam.walczykiewicz@multiuser.com.pl>
Be sure to reply to that address.Hi!
I've compiled and installed PostgreSQL v.6.5.2.
(I use SuSe Linux 6.2.).
Now I want to replace it with v.6.5.3.
There is "make clean" statement in Makefile.
But where to find "make uninstall"?One more reason to move to automake, ey?
Is PostgreSQL install only in /usr/local/pgsql
(I used default Dir) and it's enough to
rm -f from that directory(?!).Yes.
(I would like to make PostgreSQL.RPM for SuSe
Linux.that's why I have to know how to
uninstall...)I think you have a misconception about RPMs. Your easiest bet would be to
start at with the RedHat RPMs and adjust what needs adjusting.--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden************
From bouncefilter Fri Jan 14 14:41:14 2000
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 OAA67953
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 14:41:04 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <CZZ0L0C3>; Fri, 14 Jan 2000 21:37:47 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C445@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Thomas Lockhart '" <lockhart@alumni.caltech.edu>, "'Don Baccus '"
<dhogaza@pacifier.com>
Cc: "'Bruce Momjian '" <pgman@candle.pha.pa.us>, "'PostgreSQL-development '"
<pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Re: Informix and OUTER join syntax
Date: Fri, 14 Jan 2000 21:27:02 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
I was under the impression that if you used NATURAL JOIN, then the join
would be made on the declared keys.
Or doesn't SQL92 support declared keys?
MikeA
-----Original Message-----
From: Thomas Lockhart
To: Don Baccus
Cc: Bruce Momjian; PostgreSQL-development
Sent: 00/01/14 05:14
Subject: Re: [HACKERS] Re: Informix and OUTER join syntax
And if I understand SQL92 correctly, if tab1, tab2, and tab3 only
share col1 in common, then you can further simplify:
SELECT *
FROM tab1 NATURAL RIGHT JOIN (tab2 NATURAL RIGHT JOIN tab3)
Is that right? ...and some
might argue this is less clear than explicitly listing the column(s)
to join on.
But this is "natural", right? ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
************
From bouncefilter Fri Jan 14 14:46:20 2000
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 OAA68342
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 14:45:24 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <CZZ0L0CP>; Fri, 14 Jan 2000 21:42:08 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C446@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'The Hermit Hacker '" <scrappy@hub.org>, "'Don Baccus '"
<dhogaza@pacifier.com>
Cc: "'Mike Mascari '" <mascarm@mascari.com>, "'Bruce Momjian '"
<pgman@candle.pha.pa.us>, "'Tatsuo Ishii '" <t-ishii@sra.co.jp>,
"'tgl@sss.pgh.pa.us '" <tgl@sss.pgh.pa.us>, "'xun@cs.ucsb.edu '"
<xun@cs.ucsb.edu>, "'pgsql-hackers@postgreSQL.org '"
<pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] [hackers]development suggestion needed
Date: Fri, 14 Jan 2000 21:38:01 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
So, what's the deal, here...is the goal the Big Time or not?
If it means adopting one vendors concept of what the world should look
like...not.I *hate* the way Oracle sets up tablespaces ... where i have to
pre-guess
the size of my data and allocate space accordingly...what if my table
never does reach that critical mass? I've just wasted X meg of space
...
I go with you on the size thing, but I still think it's not a bad idea to be
able to determine WHERE your data goes, at least down to a table/index/etc.
level.
I hate the way that Oracle starts up something like 4 processes for
every
database, when the server is started...
Well, Oracle doesn't see a database quite the way we do. At least, not the
way we use it. We tend to have multiple schemas in a single 'instance', or
database. These schemas are actually defined per user. This is possible on
Postgres, but people just don't do it. So although four processes are
started for each instance, we only have two instances running on our main
dev server, even though there are about twenty-five schemas on it.
<snip>
If that happens to follow what one vendor happens to have done as far >>
as
their implementation, great...but there has been no conscious effort to
do
so that I'm aware of...
Cool. PostgreSQL is a vendor.
Just look at the whole OUTER JOIN issue ... *shrug*
I *like* the fact that we come up with original ideas/solutions to
problems, that make use of *existing* technologies ...
And move to new technologies a lot quicker than any other product.
I liked the thread about moving indexes and tables to seperate file
systems, and hope we can implement something that will make it
something
that does't require 'ln's, but I definitely don't like Oracle's way of
doing things ...
Yes, that's about the sum of it. Why not the links? I think that it's an
elegant way of designing the whole thing. Only the system table that stores
the 'tablespace' directories will even have a hard path in it. For the
rest, everything works in the main database directory (which could be
considered the SYSTEM tablespace).
MikeA
From bouncefilter Fri Jan 14 15:01:20 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA72338
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 15:00:43 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA89075;
Fri, 14 Jan 2000 15:58:36 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 14 Jan 2000 15:58:36 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Alfred Perlstein <bright@wintelcom.net>
cc: admin <admin@wtbwts.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Revised nonblocking patches + quasi docs
In-Reply-To: <20000114120516.D824@fw.wintelcom.net>
Message-ID: <Pine.BSF.4.21.0001141557450.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 14 Jan 2000, Alfred Perlstein wrote:
If so then I'll be glad to update the docs myself, otherwise I'd
also be happy to provide coupious amounts of plaintext docs and
comments in my code like I have been so far.
That's all you need to do...as long as we have documentation that can be
included, it will be included ... if in sgml, all the better, but
plaintext works also...
From bouncefilter Fri Jan 14 14:47:15 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA68436
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 14:46:19 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id MAA13019;
Fri, 14 Jan 2000 12:05:17 -0800 (PST)
Date: Fri, 14 Jan 2000 12:05:17 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: admin <admin@wtbwts.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Don Baccus <dhogaza@pacifier.com>,
pgsql-hackers@postgreSQL.org, scrappy@hub.org
Subject: Re: [HACKERS] Revised nonblocking patches + quasi docs
Message-ID: <20000114120516.D824@fw.wintelcom.net>
References: <20000114111430.A824@fw.wintelcom.net>
<Pine.BSF.4.10.10001141401330.84869-100000@server.b0x.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.BSF.4.10.10001141401330.84869-100000@server.b0x.com>;
from admin@wtbwts.com on Fri, Jan 14, 2000 at 02:11:52PM +0000
* admin <admin@wtbwts.com> [000114 11:35] wrote:
Alfred wrote:
* Tom Lane <tgl@sss.pgh.pa.us> [000109 08:18] wrote:
Don Baccus <dhogaza@pacifier.com> writes:
At 05:27 PM 1/8/00 -0500, Tom Lane wrote:
I also object strongly to the lack of documentation.
... I know there are some folks who aren't native-english speakers, so
perhaps you don't want to require that the implementor of such patches
provide the final documentation wording. But the information should
be there and spelled out in a form that can be very easily moved to
the docs.Oh, absolutely. Thomas, our master of the docs, has always had the
policy of "give me some words, I'll take care of formatting and
editing..."I was probably too harsh on Alfred last night, since in fact his code
was fairly well commented, and some minimal doco could have been
extracted from the routine headers. But on a change like this, I think
some paragraphs of coherent high-level explanation are needed: what it
does, when and why you'd use it. I didn't see that anywhere...I've actually been trying to work on the sgml and failing miserably,
I have no clue how this stuff works (sgml compilation) are you asking
for a couple of paragraphs that describe the proposed changes?If so I hope this suffices, if not some help on building the sgml
would be much appreciated:--------
The FreeBSD Documentation Project (FDP) has excellent references to get a
general idea on building sgml docs. First, you can install the
textproc/docproj port or, if you're not running freebsd, refer to the
website to see which programs you need. Second, you can read the FDP
Primer which details how everything comes together:
http://www.freebsd.org/tutorials/docproj-primer/Furthermore, again if you happen to be running FreeBSD, you can grab the
doc src using cvsup. The proper reference is also documented somewhere in
the Primer or in the Synchronisation chapter in the Handbook.Keep at it, sgml and the docbook stylesheets are really worthwhile when
you start getting the hang of it.
Marc
'course I run freebsd. :) I even have the docproj port installed,
however it seems that there's some things missing here, (see the
end of this message).
I really have no problem with commenting my code nor do I have a
problem with producing documentation for these changes, however
I'm _extremely_ pressed for time with this project, haven't slept
in 2 days and I and don't have time to fight with building the sgml
files to check that my changes/additions are valid, I'd much rather
focus on working on the rest of libpq for blocking issues and getting
my app into test mode.
Perhaps someone can offer a step-by-step to building _postgresql's_
doc files, or maybe there's a machine out there where this will
build properly and someone can give me an account on it?
If so then I'll be glad to update the docs myself, otherwise I'd
also be happy to provide coupious amounts of plaintext docs and
comments in my code like I have been so far.
thanks,
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
~/pgcvs/pgsql/doc/src % gmake
gmake all
gmake[1]: Entering directory `/home/bright/pgcvs/pgsql/doc/src'
gmake -C sgml clean
gmake[2]: Entering directory `/home/bright/pgcvs/pgsql/doc/src/sgml'
(rm -rf HTML.manifest *.html *.htm *.1 *.l man1 manl manpage*)
gmake[2]: Leaving directory `/home/bright/pgcvs/pgsql/doc/src/sgml'
gmake -C sgml admin.html
gmake[2]: Entering directory `/home/bright/pgcvs/pgsql/doc/src/sgml'
(rm -rf *.htm)
jade -D ref -D ../graphics -V %use-id-as-filename% -d /home/users/t/thomas/db118.d/docbook/html/docbook.dsl -t sgml admin.sgml
^^^^^^^^^^^^---- huh?
~/pgcvs/pgsql/doc % find . -name "*.dsl"
~/pgcvs/pgsql/doc %
continues...
jade:admin.sgml:26:59:W: cannot generate system identifier for public text "-//Davenport//DTD DocBook V3.0//EN"
jade:admin.sgml:51:0:E: reference to entity "BOOK" for which no system identifier could be generated
jade:admin.sgml:26:0: entity was defined here
jade:admin.sgml:51:0:E: DTD did not contain element declaration for document type name
jade:admin.sgml:53:9:E: there is no attribute "ID"
jade:admin.sgml:53:16:E: element "BOOK" undefined
jade:admin.sgml:57:7:E: element "TITLE" undefined
jade:admin.sgml:58:10:E: element "BOOKINFO" undefined
jade:admin.sgml:59:14:E: element "RELEASEINFO" undefined
jade:admin.sgml:60:13:E: element "BOOKBIBLIO" undefined
jade:admin.sgml:61:15:E: element "AUTHORGROUP" undefined
jade:admin.sgml:62:15:E: element "CORPAUTHOR" undefined
jade:admin.sgml:67:10:E: element "EDITOR" undefined
jade:admin.sgml:68:14:E: element "FIRSTNAME" undefined
jade:admin.sgml:69:12:E: element "SURNAME" undefined
jade:admin.sgml:70:16:E: element "AFFILIATION" undefined
jade:admin.sgml:71:13:E: element "ORGNAME" undefined
jade:admin.sgml:82:8:E: element "DATE" undefined
jade:admin.sgml:85:14:E: element "LEGALNOTICE" undefined
jade:admin.sgml:86:8:E: element "PARA" undefined
jade:admin.sgml:87:16:E: element "PRODUCTNAME" undefined
jade:admin.sgml:87:56:E: general entity "copy" not defined and no default entity
jade:admin.sgml:107:13:E: there is no attribute "ID"
jade:admin.sgml:107:22:E: element "PREFACE" undefined
jade:admin.sgml:108:8:E: element "TITLE" undefined
jade:admin.sgml:110:7:E: element "PARA" undefined
jade:admin.sgml:111:15:E: element "PRODUCTNAME" undefined
jade:admin.sgml:117:15:E: element "PRODUCTNAME" undefined
jade:intro-ag.sgml:1:13:E: there is no attribute "ID"
jade:intro-ag.sgml:1:23:E: element "CHAPTER" undefined
jade:intro-ag.sgml:2:8:E: element "TITLE" undefined
jade:intro-ag.sgml:4:7:E: element "PARA" undefined
jade:intro-ag.sgml:6:14:E: there is no attribute "URL"
jade:intro-ag.sgml:6:38:E: element "ULINK" undefined
jade:intro-ag.sgml:6:51:E: element "PRODUCTNAME" undefined
jade:intro-ag.sgml:10:15:E: element "PRODUCTNAME" undefined
jade:intro-ag.sgml:11:74:E: element "ULINK" undefined
jade:intro-ag.sgml:12:16:E: element "PRODUCTNAME" undefined
jade:intro-ag.sgml:13:19:E: element "PRODUCTNAME" undefined
jade:intro-ag.sgml:15:55:E: element "ACRONYM" undefined
jade:intro-ag.sgml:16:33:E: element "ACRONYM" undefined
jade:intro-ag.sgml:17:23:E: element "ACRONYM" undefined
jade:info.sgml:1:6:E: element "SECT1" undefined
jade:info.sgml:2:7:E: element "TITLE" undefined
jade:info.sgml:4:6:E: element "PARA" undefined
jade:info.sgml:8:14:E: element "VARIABLELIST" undefined
jade:info.sgml:9:15:E: element "VARLISTENTRY" undefined
jade:info.sgml:10:8:E: element "TERM" undefined
jade:info.sgml:11:12:E: element "LISTITEM" undefined
jade:info.sgml:12:9:E: element "PARA" undefined
jade:info.sgml:18:15:E: element "VARLISTENTRY" undefined
jade:info.sgml:19:8:E: element "TERM" undefined
jade:info.sgml:20:12:E: element "LISTITEM" undefined
jade:info.sgml:21:9:E: element "PARA" undefined
jade:info.sgml:27:15:E: element "VARLISTENTRY" undefined
jade:info.sgml:28:8:E: element "TERM" undefined
jade:info.sgml:29:12:E: element "LISTITEM" undefined
jade:info.sgml:30:9:E: element "PARA" undefined
jade:info.sgml:38:15:E: element "VARLISTENTRY" undefined
jade:info.sgml:39:8:E: element "TERM" undefined
jade:info.sgml:40:12:E: element "LISTITEM" undefined
jade:info.sgml:41:9:E: element "PARA" undefined
jade:info.sgml:47:15:E: element "VARLISTENTRY" undefined
jade:info.sgml:48:8:E: element "TERM" undefined
jade:info.sgml:49:12:E: element "LISTITEM" undefined
jade:info.sgml:50:9:E: element "PARA" undefined
jade:info.sgml:51:33:E: element "PRODUCTNAME" undefined
jade:info.sgml:53:17:E: element "PRODUCTNAME" undefined
jade:info.sgml:55:15:E: element "CITETITLE" undefined
jade:info.sgml:56:41:E: element "CITETITLE" undefined
jade:info.sgml:61:15:E: element "VARLISTENTRY" undefined
jade:info.sgml:62:8:E: element "TERM" undefined
jade:info.sgml:63:12:E: element "LISTITEM" undefined
jade:info.sgml:64:9:E: element "PARA" undefined
jade:info.sgml:66:41:E: element "CITETITLE" undefined
jade:info.sgml:72:6:E: element "PARA" undefined
jade:info.sgml:74:14:E: element "PRODUCTNAME" undefined
jade:info.sgml:77:14:E: element "VARIABLELIST" undefined
jade:info.sgml:78:15:E: element "VARLISTENTRY" undefined
jade:info.sgml:79:8:E: element "TERM" undefined
jade:info.sgml:80:12:E: element "LISTITEM" undefined
jade:info.sgml:81:9:E: element "PARA" undefined
jade:info.sgml:87:15:E: element "VARLISTENTRY" undefined
jade:info.sgml:88:8:E: element "TERM" undefined
jade:info.sgml:89:12:E: element "LISTITEM" undefined
jade:info.sgml:90:9:E: element "PARA" undefined
jade:info.sgml:97:15:E: element "VARLISTENTRY" undefined
jade:info.sgml:98:8:E: element "TERM" undefined
jade:info.sgml:99:12:E: element "LISTITEM" undefined
jade:info.sgml:100:9:E: element "PARA" undefined
jade:info.sgml:106:15:E: element "VARLISTENTRY" undefined
jade:info.sgml:107:8:E: element "TERM" undefined
jade:info.sgml:108:12:E: element "LISTITEM" undefined
jade:info.sgml:109:9:E: element "PARA" undefined
jade:info.sgml:111:32:E: element "ULINK" undefined
jade:info.sgml:111:45:E: element "PRODUCTNAME" undefined
jade:info.sgml:113:28:E: element "PRODUCTNAME" undefined
jade:info.sgml:119:15:E: element "VARLISTENTRY" undefined
jade:info.sgml:120:8:E: element "TERM" undefined
jade:info.sgml:121:12:E: element "LISTITEM" undefined
jade:info.sgml:122:9:E: element "PARA" undefined
jade:info.sgml:124:53:E: element "ULINK" undefined
jade:info.sgml:125:67:E: element "ULINK" undefined
jade:info.sgml:133:15:E: element "VARLISTENTRY" undefined
jade:info.sgml:134:8:E: element "TERM" undefined
jade:info.sgml:135:12:E: element "LISTITEM" undefined
jade:info.sgml:136:9:E: element "PARA" undefined
jade:info.sgml:137:17:E: element "PRODUCTNAME" undefined
jade:info.sgml:139:37:E: element "PRODUCTNAME" undefined
jade:info.sgml:147:9:E: element "PARA" undefined
jade:info.sgml:151:50:E: element "ULINK" undefined
jade:info.sgml:152:64:E: element "ULINK" undefined
jade:notation.sgml:1:10:E: there is no attribute "ID"
jade:notation.sgml:1:23:E: element "SECT1" undefined
jade:notation.sgml:2:7:E: element "TITLE" undefined
jade:notation.sgml:4:6:E: element "PARA" undefined
jade:notation.sgml:6:12:E: element "FIRSTTERM" undefined
jade:notation.sgml:8:14:E: element "PRODUCTNAME" undefined
jade:notation.sgml:10:14:E: element "PRODUCTNAME" undefined
jade:notation.sgml:13:14:E: element "PRODUCTNAME" undefined
jade:notation.sgml:16:6:E: element "PARA" undefined
jade:notation.sgml:18:14:E: element "PRODUCTNAME" undefined
jade:notation.sgml:18:48:E: element "FIRSTTERM" undefined
jade:notation.sgml:19:32:E: element "REPLACEABLE" undefined
jade:notation.sgml:20:27:E: element "PRODUCTNAME" undefined
jade:notation.sgml:24:31:E: element "PRODUCTNAME" undefined
jade:notation.sgml:26:28:E: element "PRODUCTNAME" undefined
jade:notation.sgml:27:11:E: element "EMPHASIS" undefined
jade:notation.sgml:28:73:E: element "FIRSTTERM" undefined
jade:notation.sgml:29:66:E: element "FIRSTTERM" undefined
jade:notation.sgml:33:6:E: element "PARA" undefined
jade:notation.sgml:35:12:E: element "FIRSTTERM" undefined
jade:notation.sgml:36:13:E: element "ACRONYM" undefined
jade:notation.sgml:37:14:E: element "PRODUCTNAME" undefined
jade:notation.sgml:41:14:E: element "APPLICATION" undefined
jade:notation.sgml:44:6:E: element "PARA" undefined
jade:notation.sgml:45:18:E: element "APPLICATION" undefined
jade:notation.sgml:47:21:E: element "PRODUCTNAME" undefined
jade:notation.sgml:48:51:E: element "APPLICATION" undefined
jade:notation.sgml:50:38:E: element "APPLICATION" undefined
jade:notation.sgml:56:6:E: element "PARA" undefined
jade:notation.sgml:57:18:E: element "PRODUCTNAME" undefined
jade:notation.sgml:58:45:E: element "APPLICATION" undefined
jade:notation.sgml:60:14:E: element "PRODUCTNAME" undefined
jade:notation.sgml:68:20:E: element "SECT1" undefined
jade:notation.sgml:69:7:E: element "TITLE" undefined
jade:notation.sgml:71:6:E: element "PARA" undefined
jade:notation.sgml:72:8:E: element "QUOTE" undefined
jade:notation.sgml:72:33:E: element "FILENAME" undefined
jade:notation.sgml:74:26:E: element "PRODUCTNAME" undefined
jade:notation.sgml:77:6:E: element "PARA" undefined
jade:notation.sgml:79:9:E: element "QUOTE" undefined
jade:notation.sgml:79:30:E: element "QUOTE" undefined
jade:notation.sgml:81:9:E: element "QUOTE" undefined
jade:notation.sgml:81:30:E: element "QUOTE" undefined
jade:notation.sgml:81:78:E: element "QUOTE" undefined
jade:notation.sgml:85:6:E: element "PARA" undefined
jade:notation.sgml:86:34:E: element "QUOTE" undefined
jade:notation.sgml:86:55:E: element "QUOTE" undefined
jade:notation.sgml:87:22:E: element "QUOTE" undefined
jade:notation.sgml:90:6:E: element "PARA" undefined
jade:notation.sgml:92:71:E: element "QUOTE" undefined
jade:notation.sgml:92:73:E: general entity "gt" not defined and no default entity
jade:notation.sgml:93:41:E: element "PRODUCTNAME" undefined
jade:notation.sgml:94:49:E: element "QUOTE" undefined
jade:notation.sgml:96:8:E: element "QUOTE" undefined
jade:notation.sgml:97:10:E: element "ACRONYM" undefined
jade:notation.sgml:97:63:E: element "QUOTE" undefined
jade:notation.sgml:101:6:E: element "NOTE" undefined
jade:notation.sgml:102:7:E: element "PARA" undefined
jade:notation.sgml:103:39:E: element "PRODUCTNAME" undefined
jade:notation.sgml:106:42:E: element "ULINK" undefined
jade:y2k.sgml:1:15:E: element "SECT1" undefined
jade:y2k.sgml:2:7:E: element "TITLE" undefined
jade:y2k.sgml:4:6:E: element "NOTE" undefined
jade:y2k.sgml:5:8:E: element "TITLE" undefined
jade:y2k.sgml:7:7:E: element "PARA" undefined
jade:y2k.sgml:9:50:E: element "ULINK" undefined
jade:y2k.sgml:14:6:E: element "PARA" undefined
jade:y2k.sgml:15:18:E: element "PRODUCTNAME" undefined
jade:y2k.sgml:16:18:E: element "PRODUCTNAME" undefined
jade:y2k.sgml:21:14:E: element "ITEMIZEDLIST" undefined
jade:y2k.sgml:22:11:E: element "LISTITEM" undefined
jade:y2k.sgml:23:8:E: element "PARA" undefined
jade:y2k.sgml:24:65:E: element "PRODUCTNAME" undefined
jade:y2k.sgml:26:36:E: element "PRODUCTNAME" undefined
jade:y2k.sgml:31:11:E: element "LISTITEM" undefined
jade:y2k.sgml:32:8:E: element "PARA" undefined
jade:y2k.sgml:36:19:E: element "PRODUCTNAME" undefined
jade:y2k.sgml:42:11:E: element "LISTITEM" undefined
jade:y2k.sgml:43:8:E: element "PARA" undefined
jade:y2k.sgml:47:65:E: element "ULINK" undefined
jade:y2k.sgml:50:15:E: element "QUOTE" undefined
jade:y2k.sgml:50:57:E: element "QUOTE" undefined
jade:y2k.sgml:51:18:E: element "QUOTE" undefined
jade:y2k.sgml:51:60:E: element "QUOTE" undefined
jade:y2k.sgml:55:11:E: element "LISTITEM" undefined
jade:y2k.sgml:56:8:E: element "PARA" undefined
jade:y2k.sgml:59:16:E: element "PRODUCTNAME" undefined
jade:y2k.sgml:64:6:E: element "PARA" undefined
jade:y2k.sgml:66:56:E: element "ULINK" undefined
jade:y2k.sgml:68:53:E: element "ULINK" undefined
jade:I: maximum number of errors (200) reached; change with -E option
jade:E: cannot open "/home/users/t/thomas/db118.d/docbook/html/docbook.dsl" (No such file or directory)
jade:E: specification document does not have the DSSSL architecture as a base architecture
PostgreSQL Administrator's Guide
Covering v6.5 for general release
The PostgreSQL Development Team
Thomas
Lockhart
Caltech/JPL
(last updated 1999-06-01)
PostgreSQL is Copyright 1996-9
by the Postgres Global Development Group.
Summary
Postgres,
developed originally in the UC Berkeley Computer Science Department,
pioneered many of the object-relational concepts
now becoming available in some commercial databases.
It provides SQL92/SQL3 language support,
transaction integrity, and type extensibility.
PostgreSQL is an open-source descendant
of this original Berkeley code.
Introduction
This document is the Administrator's Manual for the
PostgreSQL
database management system, originally developed at the University
of California at Berkeley.
PostgreSQL is based on
Postgres release 4.2.
The Postgres project,
led by Professor Michael Stonebraker, was sponsored by the
Defense Advanced Research Projects Agency (DARPA), the
Army Research Office (ARO), the National Science
Foundation (NSF), and ESL, Inc.
Resources
This manual set is organized into several parts:
Tutorial
An introduction for new users. Does not cover advanced features.
User's Guide
General information for users, including available commands and data types.
Programmer's Guide
Advanced information for application programmers. Topics include
type and function extensibility, library interfaces,
and application design issues.
Administrator's Guide
Installation and management information. List of supported machines.
Developer's Guide
Information for Postgres developers.
This is intended for those who are contributing to the
Postgres project;
application development information should appear in the
Programmer's Guide.
Currently included in the Programmer's Guide.
Reference Manual
Detailed reference information on command syntax.
Currently included in the User's Guide.
In addition to this manual set, there are other resources to help you with
Postgres installation and use:
man pages
The man pages have general information on command syntax.
FAQs
The Frequently Asked Questions (FAQ) documents address both general issues
and some platform-specific issues.
READMEs
README files are available for some contributed packages.
Web Site
The
Postgres
web site might have some information not appearing in the distribution.
There is a mhonarc catalog of mailing list traffic
which is a rich resource for many topics.
Mailing Lists
The
pgsql-general
(archive)
mailing list is a good place to have user questions answered.
Other mailing lists are available; consult the Info Central section of the
PostgreSQL web site for details.
Yourself!
Postgres is an open source product.
As such, it depends on the user community for ongoing support.
As you begin to use Postgres,
you will rely on others for help, either through the
documentation or through the mailing lists.
Consider contributing your knowledge back. If you learn something
which is not in the documentation, write it up and contribute it.
If you add features to the code, contribute it.
Even those without a lot of experience can provide corrections and
minor changes in the documentation, and that is a good way to start.
The
pgsql-docs
(archive)
mailing list is the place to get going.
Terminology
In the following documentation,
site
may be interpreted as the host machine on which
Postgres is installed.
Since it is possible to install more than one set of
Postgres
databases on a single host, this term more precisely denotes any
particular set of installed
Postgres binaries and databases.
The
Postgres superuser
is the user named postgres
who owns the Postgres
binaries and database files. As the database superuser, all
protection mechanisms may be bypassed and any data accessed
arbitrarily.
In addition, the Postgres superuser is allowed to execute
some support programs which are generally not available to all users.
Note that the Postgres superuser is
not
the same as the Unix superuser (which will be referred to as root).
The superuser should have a non-zero user identifier (UID)
for security reasons.
The
database administrator
or DBA, is the person who is responsible for installing
Postgres with mechanisms to
enforce a security policy for a site. The DBA can add new users by
the method described below
and maintain a set of template databases for use by
createdb.
The postmaster
is the process that acts as a clearing-house for requests
to the Postgres system.
Frontend applications connect to the postmaster,
which keeps tracks of any system errors and communication between the
backend processes. The postmaster
can take several command-line arguments to tune its behavior.
However, supplying arguments is necessary only if you intend to run multiple
sites or a non-default site.
The Postgres backend
(the actual executable program postgres) may be executed
directly from the user shell by the
Postgres super-user
(with the database name as an argument). However,
doing this bypasses the shared buffer pool and lock table associated
with a postmaster/site, therefore this is not recommended in a multiuser
site.
Notation
... or /usr/local/pgsql/
at the front of a file name is used to represent the
path to the Postgres superuser's home directory.
In a command synopsis, brackets
([ and ]) indicate an optional phrase or keyword.
Anything in braces
({ and }) and containing vertical bars (|)
indicates that you must choose one.
In examples, parentheses (( and )) are used to group boolean
expressions. | is the boolean operator OR.
Examples will show commands executed from various accounts and programs.
Commands executed from the root account will be preceeded with .
Commands executed from the Postgres
superuser account will be preceeded with %, while commands
executed from an unprivileged user's account will be preceeded with
$.
SQL commands will be preceeded with =
or will have no leading prompt, depending on the context.
At the time of writing (Postgres v6.5) the notation for
flagging commands is not universally consistant throughout the documentation set.
Please report problems to
the Documentation Mailing List.
Y2K Statement
Author
Written by
Thomas Lockhart
on 1998-10-22.
The PostgreSQL Global Development Team provides
the Postgres software code tree as a public service,
without warranty and without liability for it's behavior or performance.
However, at the time of writing:
The author of this statement, a volunteer on the Postgres
support team since November, 1996, is not aware of
any problems in the Postgres code base related
to time transitions around Jan 1, 2000 (Y2K).
The author of this statement is not aware of any reports of Y2K problems
uncovered in regression testing
or in other field use of recent or current versions
of Postgres. We might have expected
to hear about problems if they existed, given the installed base and
the active participation of users on the support mailing lists.
To the best of the author's knowledge, the
assumptions Postgres makes about dates specified with a two-digit year
are documented in the current
User's Guide
in the chapter on data types.
For two-digit years, the significant transition year is 1970, not 2000;
e.g. 70-01-01 is interpreted as 1970-01-01,
whereas 69-01-01 is interpreted as 2069-01-01.
Any Y2K problems in the underlying OS related to obtaining "the
current time" may propagate into apparent Y2K problems in
Postgres.
Refer to
The Gnu Project
and
gmake[2]: *** [admin.html] Error 1
gmake[2]: Leaving directory `/home/bright/pgcvs/pgsql/doc/src/sgml'
gmake[1]: *** [admin.tar] Error 2
gmake[1]: Leaving directory `/home/bright/pgcvs/pgsql/doc/src'
gmake: *** [install] Error 2
oy!
From bouncefilter Fri Jan 14 15:11:15 2000
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA75974
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 15:10:35 -0500 (EST) (envelope-from geek+@cmu.edu)
Received: from export.andrew.cmu.edu (EXPORT.ANDREW.CMU.EDU [128.2.23.2])
by smtp2.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id PAA28350
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 15:10:33 -0500 (EST)
Date: 14 Jan 2000 15:10:32 -0500
Message-ID: <emacs-smtp-976-14463-33464-898004@export.andrew.cmu.edu>
From: Brian E Gallew <geek+@cmu.edu>
X-Mailer: BatIMail version 3.2
To: <pgsql-hackers@postgreSQL.org>
In-reply-to: <1BF7C7482189D211B03F00805F8527F748C446@S-NATH-EXCH2>
Subject: Re: [HACKERS] [hackers]development suggestion needed
References: <1BF7C7482189D211B03F00805F8527F748C446@S-NATH-EXCH2>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/signed; protocol="application/pgp-signature";
boundary="pgp-sign-Multipart_Fri_Jan_14_15:10:31_2000-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
--pgp-sign-Multipart_Fri_Jan_14_15:10:31_2000-1
Content-Type: text/plain; charset=US-ASCII
Then <Michael.Ansley@intec.co.za> spoke up and said:
I liked the thread about moving indexes and tables to seperate file
systems, and hope we can implement something that will make it
something
that does't require 'ln's, but I definitely don't like Oracle's way of
doing things ...Yes, that's about the sum of it. Why not the links? I think that it's an
elegant way of designing the whole thing. Only the system table that stores
the 'tablespace' directories will even have a hard path in it. For the
rest, everything works in the main database directory (which could be
considered the SYSTEM tablespace).
It seems to me (in spite of the fact that I contribute no code) that
we *might* want to consider if we want a system table that contains
storage manager specific information. Our current storage manager
could probably be extended (with some small amount of difficulty) to
get more path information out of such a table. A raw partition
storage manager might want pathing and sizeing information.
Back to the symlink stuff: symlinking in general should be deprecated
since it doesn't work everywhere, PLUS it causes ugliness in the table
truncation code. I must admit, I'm and Ingres fan, and I kinda like
the way it does things (very similar to what PostgreSQL does, but
explicit pathing in a system table). A database is created in a
default location, it can then be extended across multiple locations.
Without explicit instruction, however, it will create all new files in
the default location. Ingres also has the initial database lookup
function return the default database area.
--
=====================================================================
| JAVA must have been developed in the wilds of West Virginia. |
| After all, why else would it support only single inheritance?? |
=====================================================================
| Finger geek@cmu.edu for my public key. |
=====================================================================
--pgp-sign-Multipart_Fri_Jan_14_15:10:31_2000-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface
iQBVAwUBOH+CuIdzVnzma+gdAQH5SQH9GU7ongsJ+Sz/KEyUX4RqRIRhvCgFlxN/
4HvvErUGFiyvBcowIw5lovm0QnCID6TRAW9zGRaULmbwZ+92Ic5EkA==
=uXD4
-----END PGP MESSAGE-----
--pgp-sign-Multipart_Fri_Jan_14_15:10:31_2000-1--
From bouncefilter Fri Jan 14 15:58:15 2000
Received: from rage.hub.org (root@nat193.192.mpoweredpc.net [142.177.193.192])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA86213
for <pgsql-hackers@hub.org>; Fri, 14 Jan 2000 15:57:48 -0500 (EST)
(envelope-from jeff@hub.org)
Received: from localhost (jeff@localhost)
by rage.hub.org (8.9.3/8.9.3) with ESMTP id QAA09713;
Fri, 14 Jan 2000 16:57:52 -0400 (AST) (envelope-from jeff@hub.org)
X-Authentication-Warning: rage.hub.org: jeff owned process doing -bs
Date: Fri, 14 Jan 2000 16:57:52 -0400 (AST)
From: Jeff MacDonald <jeff@hub.org>
Reply-To: Jeff MacDonald <jeff@hub.org>
To: Stephen Birch <sbirch@ironmountainsystems.com>
cc: Peter Eisentraut <peter_e@gmx.net>,
Adam Walczykiewicz <adam.walczykiewicz@multiuser.com.pl>,
pgsql-hackers@hub.org
Subject: Re: [HACKERS] Uninstalling PostgreSQL ??!!
In-Reply-To: <387F76FE.DF894E0E@ironmountainsystems.com>
Message-ID: <Pine.BSF.4.10.10001141656030.428-100000@rage.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi Steve,
The PostgreSQL project is willing to support any os it
can. We have Redhat RPMS on our site, because someone
(Lamar Owen) took the time to do it, then submitted them.
You may do the same. Ideally we'd like to have a package/bin
for each os.
Jeff
===================================================================
So long as the Universe had a beginning, we can suppose it had a
creator, but if the Universe is completly self contained , having
no boundry or edge, it would neither be created nor destroyed
It would simply be.
===================================================================
From bouncefilter Fri Jan 14 16:36:15 2000
Received: from mail.1000dollarreward.com (root@[208.141.81.68])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA00466
for <pgsql-hackers@postgresql.org>;
Fri, 14 Jan 2000 16:35:33 -0500 (EST)
(envelope-from Keith@Claygency.com)
Received: from keith ([208.141.81.208])
by mail.1000dollarreward.com (8.8.8/8.8.8) with SMTP id QAA14689
for <pgsql-hackers@postgresql.org>; Fri, 14 Jan 2000 16:49:28 -0500
Received: by localhost with Microsoft MAPI; Fri, 14 Jan 2000 16:37:13 -0500
Message-ID: <01BF5EAD.9C209F40.Keith@Claygency.com>
From: Keith Harmon <Keith@Claygency.com>
Reply-To: "Keith@Claygency.com" <Keith@Claygency.com>
To: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: FW: licensing and support
Date: Fri, 14 Jan 2000 16:37:11 -0500
Organization: Claygency
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
I tried to send this to pgsql-questions@postgresql.org and it was returned
re: user unknown. Can you forward to support?
Thanks,
Keith Harmon
-----Original Message-----
From: Keith Harmon [SMTP:Keith@Claygency.com]
Sent: Friday, January 14, 2000 4:17 PM
To: 'pgsql-questions@postgresql.org'
Subject: licensing and support
Hello there,
I found your product via an internet search via an article describing how
to set up Linux, Apache and PostgreSQL.
I have a Java database app using JDBC that currently runs on SQL server 7
MSDE on the Wintel platform, but I would like to be able to make it
available on the Linux and Solaris platforms. This is a new retail product
in which the database will not be visible to the user, essentially
imbedding the database behind the product.
The decision to use MSDE for Wintel was predicated on the fact that it has
a royalty free runtime distribution.
Is it true that PostgreSQL is free - source code and all? I can include it
behind my software for no license royalty?
I assume your support services have a fee involved - what is that cost
structure like?
Looking forward to hearing from you,
Keith Harmon
From bouncefilter Fri Jan 14 16:57:18 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA04511
for <pgsql-hackers@hub.org>; Fri, 14 Jan 2000 16:56:35 -0500 (EST)
(envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max03-032.enterprise.net
[194.72.196.32])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id VAA01783;
Fri, 14 Jan 2000 21:56:29 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id VAA30386;
Fri, 14 Jan 2000 21:56:21 GMT
Message-Id: <200001142156.VAA30386@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Stephen Birch <sbirch@ironmountainsystems.com>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] Uninstalling PostgreSQL ??!!
In-Reply-To: Message from Stephen Birch <sbirch@ironmountainsystems.com>
of "Fri,
14 Jan 2000 11:20:30 PST." <387F76FE.DF894E0E@ironmountainsystems.com>
References: <Pine.GSO.4.02A.10001131634260.6438-100000@Pingvin.DoCS.UU.SE>
<387F76FE.DF894E0E@ironmountainsystems.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 14 Jan 2000 21:56:18 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Stephen Birch wrote:
Does the PostgreSQL project officially only support Red Hat - I sure would l
ike to see SuSE supported and
mentioned instead of just Red hat. I'd be happy to generate SuSE RPMs for d
istribution via the PostgreSQL
site.I thought I saw some discussion about this issue earlier.
Who generates the SuSE rpms distributed with the SuSE release. These are of
no value to me because I wish
to use /usr/local/pgsql for PostgreSQL.
If you generate RPMs for SUSE, rather than just for your own use, you will
surely need to conform to their policy. I should be most surprised if
that allowed their RPMs to use /usr/local, which should be for the local
administrator rather than for the distribution.
That is, of course, why Red Hat's RPMs and Debian's packages relocate
PostgreSQL into directories that conform to those distributions'
policies.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"For the LORD is good; his mercy is everlasting; and
his truth endureth to all generations."
Psalms 100:5
From bouncefilter Fri Jan 14 17:05:16 2000
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 RAA09313
for <hackers@postgresql.org>; Fri, 14 Jan 2000 17:04:52 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64374 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S22547AbQANWEN>;
Fri, 14 Jan 2000 23:04:13 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129Evv-0001wR-00; Fri, 14 Jan 2000 23:11:03 +0100
Date: Fri, 14 Jan 2000 23:11:02 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Mike Mascari <mascarim@yahoo.com>
cc: hackers@postgresql.org
Subject: descriptions on operators
Message-ID: <Pine.LNX.4.21.0001140151350.1917-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
I know we left this issue open, but I came to the conclusion that it would
be wiser to keep it like it used to be in that operator comments should be
indexed on the underlying functions. The reason is simply that there is a
a one-to-one relationship between operators and their function, so we'd
end up writing everything double with little purpose. That would mean
you'd have to tweak your code a little.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Jan 14 17:05:16 2000
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 RAA09309
for <hackers@postgresql.org>; Fri, 14 Jan 2000 17:04:50 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64352 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S202762AbQANWEK>;
Fri, 14 Jan 2000 23:04:10 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129Ew4-0001wT-00
for hackers@postgresql.org; Fri, 14 Jan 2000 23:11:12 +0100
Date: Fri, 14 Jan 2000 23:11:12 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: Help from a Windows programmer needed!
Message-ID: <Pine.LNX.4.21.0001140155480.1917-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
The Windows makefile for psql is still in prehistoric state. Is there
someone who uses Visual C++ or whatever it was that could update it?
Otherwise psql will no longer be supported on non-cygwin systems!
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Jan 14 17:19:16 2000
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 RAA12060
for <hackers@postgresql.org>; Fri, 14 Jan 2000 17:19:02 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64211 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S36883AbQANWS0>;
Fri, 14 Jan 2000 23:18:26 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129FA0-00028o-00
for hackers@postgresql.org; Fri, 14 Jan 2000 23:25:36 +0100
Date: Fri, 14 Jan 2000 23:25:36 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: psql variables fixed (?)
Message-ID: <Pine.LNX.4.21.0001140011200.1917-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
I resolved the issue psql variables vs array syntax in the manner
suggested by various people. If the variable is undefined the string will
be untouched. Now something else I'd like to get your comment on is that I
handled the cast operator '::' in the same way, namely so that
=> select 'now'::datetime
will resolve to
=> select 'now':<value of variable "datetime" if defined>
The reason is that otherwise a construct like this
=> \set foo 3
=> select arr.a[2::foo];
or even
=> \set foo 'int4'
=> select x:::foo from y;
won't be possible without introducing an extra syntax trick. And it makes
it consistent throughout.
(Btw., was somebody mentioning that this cast syntax is non-standard and
that he wanted to move toward a standard one? Just wondering.)
However, psql defines some variables by itself, for example the one
containing the last oid. I set up the rule that those variables are always
all upper-case. If something still fails you can always call \unset VAR to
unset it before a query. The list of these variables is in the docs.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Jan 14 17:19:16 2000
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 RAA12074
for <pgsql-hackers@postgresql.org>;
Fri, 14 Jan 2000 17:19:11 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64285 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S69653AbQANWSh>;
Fri, 14 Jan 2000 23:18:37 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129FA8-00028q-00; Fri, 14 Jan 2000 23:25:44 +0100
Date: Fri, 14 Jan 2000 23:25:44 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Brook Milligan <brook@biology.nmsu.edu>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql -f inconsistency with "copy from stdin"
In-Reply-To: <200001122054.NAA04232@biology.nmsu.edu>
Message-ID: <Pine.LNX.4.21.0001140134370.1917-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Okay, this is the new law:
copy x from stdin;
"stdin" is whereever the actual copy from stdin command line came from.
This is that way because "stdin" in that case does not really refer to
stdin in the classical sense but tells the backend to get the data from
the same stream the command came from (namely the network connection), and
that's what we're doing.
copy x from stdout;
The output goes to whereever select * from x would go to, in particular \o
affects this. This is purely because I said so, but I think it's
reasonable.
\copy x from stdin
The input comes from psql's stdin. (Which is correcter in this case since
it's a _frontend_ copy.)
\copy x to stdout
psql's stdout
I hope everyone's happy now. ;)
On 2000-01-12, Brook Milligan mentioned:
But there are specifically two kinds of input involved here [*]:
- input of SQL commands and such to psql
- input of data to a COPY commandTo me these are conceptually very distinct (in much the same way you
have distinguished already between various output streams; in fact,
I'm not sure how you have matched those with the output stream from
COPY, but it might be relevant to think about that in light of this
discussion). Thus, to me it makes sense to say "take input from there
and there," as long as it is clear that one "there" refers to one
input stream and the other to the other one. For example, -f
naturally refers to the first one above, while the STDIN naturally
refers to the second.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Jan 14 17:20:16 2000
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 RAA12214
for <hackers@postgresql.org>; Fri, 14 Jan 2000 17:19:42 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64649 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S47125AbQANWTN>;
Fri, 14 Jan 2000 23:19:13 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129FAl-00029O-00
for hackers@postgresql.org; Fri, 14 Jan 2000 23:26:23 +0100
Date: Fri, 14 Jan 2000 23:26:23 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: pg_pwd
Message-ID: <Pine.LNX.4.21.0001142031261.344-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
I committed a few changes to the user creation code which should, in
theory, make them more robust (doesn't use pg_exec_query_dest anymore).
Due to an inherent design conflict the update of the password file cannot
use the COPY logic anymore (the copy command wouldn't see the last changed
tuple), so it does it itself now, which looks better to me anyway. The
format of the file is still the same, I just filled up the unused spots
with x's and 0's. The remaining problem is initdb, which writes the
initial pg_pwd with COPY, so we can't go to a different, more compact
format yet. A solution for this would be to scrap this call and instead
call
echo "ALTER USER $POSTGRES WITH PASSWORD '$WHATEVER'" | postgres ...
in initdb and forget about all the scary sed -f or similar things that
have been proposed recently to get the password in there securely. That
way we can be assured to have the password file always in the format it
will be later on.
Bruce, are you still working on that part?
A few other side effects of the changes were:
* Even unprivileged users can change their own password (but nothing else)
* The password is now an Sconst in the parser, which better reflects its
text datatype and also forces users to quote them.
* If your password is NULL you won't be written to the password file,
meaning you can't connect until you have a password set up (if you use
password authentication).
* When you drop a user that owns a database you get an error. The database
is not gone.
These are minor "wholesale" changes, but I thought they would be in the
public's interest.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Jan 14 17:22:21 2000
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 RAA12672
for <pgsql-hackers@postgresql.org>;
Fri, 14 Jan 2000 17:21:53 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61859 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S51217AbQANWVP>;
Fri, 14 Jan 2000 23:21:15 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129FCh-00029Q-00; Fri, 14 Jan 2000 23:28:23 +0100
Date: Fri, 14 Jan 2000 23:28:23 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: Many regress tests failing due to latest psql changes
In-Reply-To: <26388.947814425@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001142326430.344-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
This seems to have been like that for a while. I put in a fflush() at the
appropriate spot, hope that helps. Man, I thought we had all of them
caught already... (It's time I start running the regress tests
religiously, ey?)
On 2000-01-13, Tom Lane mentioned:
It looks like the latest psql has a buffer-flush-timing problem.
Error messages are appearing out-of-sync with script echoing,
for example:*** expected/boolean.out Sat Jan 8 19:31:26 2000 --- results/boolean.out Thu Jan 13 20:41:24 2000 *************** *** 111,118 **** -- This is now an invalid expression -- For pre-v6.3 this evaluated to false - thomas 1997-10-23 INSERT INTO BOOLTBL2 (f1) - VALUES (bool 'XXX'); ERROR: Bad boolean external representation 'XXX' -- BOOLTBL2 should be full of false's at this point SELECT '' AS f_4, BOOLTBL2.*; f_4 | f1 --- 111,118 ---- -- This is now an invalid expression -- For pre-v6.3 this evaluated to false - thomas 1997-10-23 INSERT INTO BOOLTBL2 (f1) ERROR: Bad boolean external representation 'XXX' + VALUES (bool 'XXX'); -- BOOLTBL2 should be full of false's at this point SELECT '' AS f_4, BOOLTBL2.*; f_4 | f1This is making it difficult to look for actual backend bugs,
so I respectfully request a fix ASAP.regards, tom lane
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Jan 14 17:53:18 2000
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 RAA22140
for <pgsql-hackers@hub.org>; Fri, 14 Jan 2000 17:52:19 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id RAA10149;
Fri, 14 Jan 2000 17:52:11 -0500
Message-ID: <387FA892.17F2E9F8@wgcr.org>
Date: Fri, 14 Jan 2000 17:52:02 -0500
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: Oliver Elphick <olly@lfix.co.uk>
CC: Stephen Birch <sbirch@ironmountainsystems.com>, pgsql-hackers@hub.org
Subject: Re: [HACKERS] Uninstalling PostgreSQL ??!!
References: <Pine.GSO.4.02A.10001131634260.6438-100000@Pingvin.DoCS.UU.SE>
<387F76FE.DF894E0E@ironmountainsystems.com>
<200001142156.VAA30386@linda.lfix.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Oliver Elphick wrote:
Stephen Birch wrote:
Does the PostgreSQL project officially only support Red Hat - I sure would l
ike to see SuSE supported and
mentioned instead of just Red hat. I'd be happy to generate SuSE RPMs for d
istribution via the PostgreSQL
site.I thought I saw some discussion about this issue earlier.
Who generates the SuSE rpms distributed with the SuSE release. These are of
SuSE does their own -- according to rpmfind.net, they've split things up
worse than RedHat ever did. They also put things in different places
than RedHat does, which, of course, they are certainly free to do.
If you generate RPMs for SUSE, rather than just for your own use, you will
surely need to conform to their policy. I should be most surprised if
that allowed their RPMs to use /usr/local, which should be for the local
administrator rather than for the distribution.That is, of course, why Red Hat's RPMs and Debian's packages relocate
PostgreSQL into directories that conform to those distributions'
policies.
Thank you, Oliver, for explaining that. I really wish that the various
Linux distributions could standardize some things -- it is really
aggravating as a packager of RPMS -- SuSE has one way and place to store
things, RedHat as another, Caldera has yet another. Which is why I have
labeled the RPMS I have built as _RedHat_ -- that's what I've got, so
that's what I am able to support.
I just received documentation from a nice chap who has successfully
installed and gotten working the JDBC client in the RPM distribution --
man, I'm very grateful for documentation!
I know that there have been a couple of users who have gotten the RedHat
RPM's to be usable under SuSE -- I just need more information -- in
particular, where does SuSE like to put things? What environment
variables and RPM macros are defined under SuSE during the build, so
that conditional logic can be put in the source RPM -- having a single
source RPM is a big plus, because then everybody can build from a common
knowledge base.
According to rpmfind.net, the SuSE RPM's are very different from the
RedHat ones -- which I regret. However, I picked up the maintenance of
an existing RPM so that existing users wouldn't be drastically surprised
at the changes, rather than me building a whole new set of RPM's.
Feel free to look at the source RPM for RedHat, and look carefully in my
README.rpm as to package rationale. Feel free to take what I've done
and modify it for SuSE. And, if you're going to do the above, please
document it so that others can understand it. I would like to see a
single RPM base that worked for all the RPM-based distributions -- sure
would make support easier!
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Fri Jan 14 18:31:17 2000
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 SAA33224;
Fri, 14 Jan 2000 18:30:54 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA13193;
Fri, 14 Jan 2000 18:05:27 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001142305.SAA13193@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_pwd
In-Reply-To: <Pine.LNX.4.21.0001142031261.344-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 14, 2000 11:26:23 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Fri, 14 Jan 2000 18:05:27 -0500 (EST)
CC: hackers@postgreSQL.org, webmaster@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
I committed a few changes to the user creation code which should, in
theory, make them more robust (doesn't use pg_exec_query_dest anymore).
Great. I have been hoping for this.
Due to an inherent design conflict the update of the password file cannot
use the COPY logic anymore (the copy command wouldn't see the last changed
tuple), so it does it itself now, which looks better to me anyway. The
format of the file is still the same, I just filled up the unused spots
with x's and 0's. The remaining problem is initdb, which writes the
initial pg_pwd with COPY, so we can't go to a different, more compact
format yet. A solution for this would be to scrap this call and instead
callecho "ALTER USER $POSTGRES WITH PASSWORD '$WHATEVER'" | postgres ...
That is fine with me.
in initdb and forget about all the scary sed -f or similar things that
have been proposed recently to get the password in there securely. That
way we can be assured to have the password file always in the format it
will be later on.Bruce, are you still working on that part?
Sure, the echo is fine. If not, you do whatever you want, and I will go
in and make it secure.
A few other side effects of the changes were:
* Even unprivileged users can change their own password (but nothing else)
Great.
* The password is now an Sconst in the parser, which better reflects its
text datatype and also forces users to quote them.* If your password is NULL you won't be written to the password file,
meaning you can't connect until you have a password set up (if you use
password authentication).* When you drop a user that owns a database you get an error. The database
is not gone.These are minor "wholesale" changes, but I thought they would be in the
public's interest.
Sounds like a nice set of patches. We need to get Peter on the
Developers page. Vince?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 14 18:18:18 2000
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 SAA28790;
Fri, 14 Jan 2000 18:18:10 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id SAA10181;
Fri, 14 Jan 2000 18:18:18 -0500
Message-ID: <387FAEB0.32C83370@wgcr.org>
Date: Fri, 14 Jan 2000 18:18:08 -0500
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: Jeff MacDonald <jeff@hub.org>
CC: Stephen Birch <sbirch@ironmountainsystems.com>,
Peter Eisentraut <peter_e@gmx.net>,
Adam Walczykiewicz <adam.walczykiewicz@multiuser.com.pl>,
pgsql-hackers@hub.org
Subject: Re: [HACKERS] Uninstalling PostgreSQL ??!!
References: <Pine.BSF.4.10.10001141656030.428-100000@rage.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jeff MacDonald wrote:
The PostgreSQL project is willing to support any os it
can. We have Redhat RPMS on our site, because someone
(Lamar Owen) took the time to do it, then submitted them.
Thanks, Jeff.
You may do the same. Ideally we'd like to have a package/bin
for each os.
If anyone wants to pick up RPM's for SuSE or Caldera (or any other
RPM-based distribution), I'll be perfectly happy to help them get
started.
I would like any other RPM's to be as close as possible to the RedHat
ones to simplify support, but that's not absolutely necessary. I'll
also offer any of the spec file stuff and upgrading scripts to them to
expedite their efforts -- after all, I was able to take Oliver's Debian
upgrade scripts and modify them to work very nicely under RedHat without
a great deal of effort (once I understood them, that is).
The documentation of the packaging differences in the various
distributions would be very helpful to have on the PostgreSQL site --
I've put the RPM readme on the ftp site under bindist/RPM (Jeff, if
SuSE and Caldera folks get this running, we might want to rename the
bindist/RPM dir to bindist/RedHat, as those RPM's and that documentation
is pretty RedHat-specific), and I'd like to see the Debian documentation
(simple docs -- where is PGDATA, what is the name and parameters of the
startup script, etc) placed on the PostgreSQL site as well -- Oliver has
already mentioned that the standard download site for the Debian
packages is the Debian distribution's site, so ftp.postgresql.org may
not need the .deb's online. Just a thought.
Of course, those are just the Linux packages. There are many other
systems that have package managers for which it would be useful to have
prebuilt binaries available for download.
I am bothered more than a little of the thought that the RPM-based linux
distributions are so different that a single RPM set can't work with all
of them equally well. Of course, that can happen under open source --
the distributors are certainly free to do it their own way.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Fri Jan 14 18:34:17 2000
Received: from corvette.mascari.com (dhcp26142035.columbus.rr.com
[24.26.142.35]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA34155
for <hackers@postgreSQL.org>; Fri, 14 Jan 2000 18:33:54 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id SAA05103;
Fri, 14 Jan 2000 18:32:16 -0500
Message-ID: <387FB1C5.F6DAFED@mascari.com>
Date: Fri, 14 Jan 2000 18:31:17 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] descriptions on operators
References: <Pine.LNX.4.21.0001140151350.1917-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Eisentraut wrote:
I know we left this issue open, but I came to the conclusion that it would
be wiser to keep it like it used to be in that operator comments should be
indexed on the underlying functions. The reason is simply that there is a
a one-to-one relationship between operators and their function, so we'd
end up writing everything double with little purpose. That would mean
you'd have to tweak your code a little.
If that's the way you want it, so it shall be. I have to write up
a diff for pg_dump this weekend anyways to generate the
appropriate COMMENT ON statements for version 7.0.
Mike Mascari
From bouncefilter Fri Jan 14 21:03:24 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA76225
for <pgsql-hackers@postgresql.org>;
Fri, 14 Jan 2000 21:02:22 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA91628
for <pgsql-hackers@postgresql.org>;
Fri, 14 Jan 2000 22:02:39 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 14 Jan 2000 22:02:39 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: date/time problem in v6.5.3 and 7.0.0 ...
Message-ID: <Pine.BSF.4.21.0001142201470.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I can add days to now(), but not subtract?
=====================================
template1=> select now() + '30 days';
?column?
------------------------------
Sun Feb 13 22:00:33 2000 AST
(1 row)
template1=> select now() - '30 days';
ERROR: Unable to identify an operator '-' for types 'timestamp' and 'unknown'
You will have to retype this query using an explicit cast
template1=> select version();
version
---------------------------------------------------------------------
PostgreSQL 7.0.0 on i386-unknown-freebsd4.0, compiled by gcc 2.95.2
(1 row)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 14 21:18:19 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA80493
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 21:17:25 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id SAA14702;
Fri, 14 Jan 2000 18:17:01 -0800 (PST)
Message-Id: <3.0.1.32.20000114181256.0109cb00@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 14 Jan 2000 18:12:56 -0800
To: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] date/time problem in v6.5.3 and 7.0.0 ...
In-Reply-To: <Pine.BSF.4.21.0001142201470.46499-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:02 PM 1/14/00 -0400, The Hermit Hacker wrote:
I can add days to now(), but not subtract?
=====================================
template1=> select now() + '30 days';
?column?
------------------------------
Sun Feb 13 22:00:33 2000 AST
(1 row)template1=> select now() - '30 days';
ERROR: Unable to identify an operator '-' for types 'timestamp' and
'unknown'
You will have to retype this query using an explicit cast
template1=> select version();
donb=> select now()-'30 days'::reltime;
?column?
----------------------
1999-12-15 18:13:18-08
(1 row)
donb=> select now()-'30 days';
ERROR: Unable to identify an operator '-' for types 'timestamp' and 'unknown'
You will have to retype this query using an explicit cast
donb=>
As a relative newcomer, I too have found dates a bit confusing and
my solution has been to cast like crazy rather than guess what will
happen if I don't :)
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 14 22:00:26 2000
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 VAA95137
for <pgsql-hackers@postgresql.org>;
Fri, 14 Jan 2000 21:59:35 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62543 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S219161AbQAOC6w>;
Sat, 15 Jan 2000 03:58:52 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129JWK-000793-00; Sat, 15 Jan 2000 04:04:56 +0100
Date: Sat, 15 Jan 2000 04:04:56 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: Peter opens a can of worms
In-Reply-To: <27170.947815830@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001150102160.344-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Boy, those worms were just waiting to come out ...
On 2000-01-13, Tom Lane mentioned:
I wrote:
Cool. Now who's going to fix the cartload of warnings this has
produced? I'm counting about 125 of them.
All fixed. (good count by the way ;)
On further investigation, it seems that some of these warnings are
real portability issues (pointers being printed as ints, etc).
Actually about a quarter of these were definitely problems, with a handful
of rather serious bugs (depends on how serious this can become, of
course).
But a very considerable fraction are bogus. gcc doesn't know about
Actually going through them there were certainly a few harmless ones (such
as too many arguments), but exactly zero were completely bogus. Especially
too many arguments might point out a typo.
elog's "%m" extension to the standard %-format set, and it seems to
be assuming that there should be a parameter to go with the %m.
%m is a GNU extension (so they claim). (And even if it weren't, there's a
way to "register" non-standard format conversions.)
I have a feeling we will have to revert this change...
I'd ask you to reconsider. Especially with the multitude of typdefs we
have you never know for sure what format to use. As I said, a number of
these warnings actually had a good cause.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Fri Jan 14 22:01:26 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA96201
for <hackers@postgresql.org>; Fri, 14 Jan 2000 22:00:27 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id DAA09967;
Sat, 15 Jan 2000 03:08:59 GMT
Sender: lockhart@hub.org
Message-ID: <387FE4CB.BB2EE0C6@alumni.caltech.edu>
Date: Sat, 15 Jan 2000 03:08:59 +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: hackers@postgresql.org
Subject: Re: [HACKERS] psql variables fixed (?)
References: <Pine.LNX.4.21.0001140011200.1917-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Eisentraut wrote:
I resolved the issue psql variables vs array syntax in the manner
suggested by various people. If the variable is undefined the string will
be untouched. Now something else I'd like to get your comment on is that I
handled the cast operator '::' in the same way, namely so that
(Btw., was somebody mentioning that this cast syntax is non-standard and
that he wanted to move toward a standard one? Just wondering.)
Yes, I probably mentioned that. But there is a problem in that the
SQL92 standard does not actually define the "type 'string'" syntax for
anything other than date/time types, since those are the only types
other than true strings defined in the standard. So I extended the
standard (in a natural way imho) to include any string-y input.
I'd be a little reluctant to give up the alternate "::" syntax, only
because I'm not sure I trust the standards folks to not stomp on the
alternative at some point in the future. (Sorry about the
double-negative, but it says what I mean :)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 14 22:14:19 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA03081
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 22:14:06 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id DAA10081;
Sat, 15 Jan 2000 03:19:15 GMT
Sender: lockhart@hub.org
Message-ID: <387FE733.49D9A679@alumni.caltech.edu>
Date: Sat, 15 Jan 2000 03:19:15 +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: Alfred Perlstein <bright@wintelcom.net>
CC: admin <admin@wtbwts.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org,
scrappy@hub.org
Subject: Re: [HACKERS] Revised nonblocking patches + quasi docs
References: <20000114111430.A824@fw.wintelcom.net>
<Pine.BSF.4.10.10001141401330.84869-100000@server.b0x.com>
<20000114120516.D824@fw.wintelcom.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've actually been trying to work on the sgml and failing miserably,
I have no clue how this stuff works (sgml compilation) are you asking
for a couple of paragraphs that describe the proposed changes?
If so I hope this suffices, if not some help on building the sgml
would be much appreciated:'course I run freebsd. :) I even have the docproj port installed,
however it seems that there's some things missing here, (see the
end of this message).
Perhaps someone can offer a step-by-step to building _postgresql's_
doc files, or maybe there's a machine out there where this will
build properly and someone can give me an account on it?
You are probably very near having something working. The Postgres docs
have an appendix on "Documentation", which contains some information
on getting jade built and running. The makefile in doc/src/sgml has
comments which indicate what probably needs to be changed, and how to
do it (the parameters are set so the stuff builds on postgresql.org,
but I have a couple of lines in my Makefile.custom to get things to
work at home).
In particular, the .dsl files are somewhere in your jade installation
tree (it is in /usr/lib/sgml/stylesheets/nwalsh-modular/{print,html}
on my Linux box).
Ask more specific questions and we'll help you through it, but only
after you get some sleep :)
I'm out of town through the weekend, but will be on-list Monday night
afaik.
- Thomas
~/pgcvs/pgsql/doc/src % gmake
gmake all
gmake[1]: Entering directory `/home/bright/pgcvs/pgsql/doc/src'
gmake -C sgml clean
gmake[2]: Entering directory `/home/bright/pgcvs/pgsql/doc/src/sgml'
(rm -rf HTML.manifest *.html *.htm *.1 *.l man1 manl manpage*)
gmake[2]: Leaving directory `/home/bright/pgcvs/pgsql/doc/src/sgml'
gmake -C sgml admin.html
gmake[2]: Entering directory `/home/bright/pgcvs/pgsql/doc/src/sgml'
(rm -rf *.htm)
jade -D ref -D ../graphics -V %use-id-as-filename% -d /home/users/t/thomas/db118.d/docbook/html/docbook.dsl -t sgml admin.sgml^^^^^^^^^^^^---- huh?
~/pgcvs/pgsql/doc % find . -name "*.dsl"
~/pgcvs/pgsql/doc %continues...
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 14 22:13:20 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA02676
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 22:12:50 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id DAA10087;
Sat, 15 Jan 2000 03:20:33 GMT
Sender: lockhart@hub.org
Message-ID: <387FE781.26E0778F@alumni.caltech.edu>
Date: Sat, 15 Jan 2000 03:20:33 +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: "Ansley, Michael" <Michael.Ansley@intec.co.za>
CC: "'Don Baccus '" <dhogaza@pacifier.com>,
"'Bruce Momjian '" <pgman@candle.pha.pa.us>,
"'PostgreSQL-development '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Informix and OUTER join syntax
References: <1BF7C7482189D211B03F00805F8527F748C445@S-NATH-EXCH2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I was under the impression that if you used NATURAL JOIN, then the join
would be made on the declared keys.
Nope. On column names in common.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 14 23:59:28 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA44460
for <hackers@postgreSQL.org>; Fri, 14 Jan 2000 23:58:43 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id UAA29187;
Fri, 14 Jan 2000 20:58:08 -0800 (PST)
Message-Id: <3.0.1.32.20000114204912.0109f060@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 14 Jan 2000 20:49:12 -0800
To: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] psql variables fixed (?)
Cc: hackers@postgreSQL.org
In-Reply-To: <387FE4CB.BB2EE0C6@alumni.caltech.edu>
References: <Pine.LNX.4.21.0001140011200.1917-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 03:08 AM 1/15/00 +0000, Thomas Lockhart wrote:
I'd be a little reluctant to give up the alternate "::" syntax, only
because I'm not sure I trust the standards folks to not stomp on the
alternative at some point in the future. (Sorry about the
double-negative, but it says what I mean :)
Which begs the question ... does Postgres.org have representation
on the standards commitees?
Whether or not there's money available for development, I should
think minimal funding for participation in the standards committee
(i.e. travel and per-diem, maybe not a salary) wouldn't be hard to
scare up...
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sat Jan 15 00:00:26 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA44803
for <pgsql-hackers@postgreSQL.org>;
Fri, 14 Jan 2000 23:59:52 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id UAA29213;
Fri, 14 Jan 2000 20:58:13 -0800 (PST)
Message-Id: <3.0.1.32.20000114205251.0109e880@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 14 Jan 2000 20:52:51 -0800
To: Thomas Lockhart <lockhart@alumni.caltech.edu>,
"Ansley, Michael" <Michael.Ansley@intec.co.za>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Re: Informix and OUTER join syntax
Cc: "'Bruce Momjian '" <pgman@candle.pha.pa.us>,
"'PostgreSQL-development '" <pgsql-hackers@postgreSQL.org>
In-Reply-To: <387FE781.26E0778F@alumni.caltech.edu>
References: <1BF7C7482189D211B03F00805F8527F748C445@S-NATH-EXCH2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 03:20 AM 1/15/00 +0000, Thomas Lockhart wrote:
I was under the impression that if you used NATURAL JOIN, then the join
would be made on the declared keys.Nope. On column names in common.
(phew!) This is how I remembered it. Though it's in Boston and I'm
in Portland (OR, that is), due to my space-headedness, I can strongly
recommend that interested folks spend some of those $25,000 or so
dollars saved by not using Oracle on a copy of Date's SQL primer :)
(I forget the exact title, but it's pretty good. I'll probably pick
up the standard, too, but Date's book is as much critique as explanation
and the SQL 92 standard seems in need of critical comments)
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sat Jan 15 00:32:21 2000
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 AAA62235
for <pgsql-hackers@postgresql.org>;
Sat, 15 Jan 2000 00:31:36 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id OAA24887;
Sat, 15 Jan 2000 14:31:33 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id OAA02559;
Sat, 15 Jan 2000 14:31:32 +0900
To: peter_e@gmx.net, e99re41@DoCS.UU.SE
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] libpq+MB/putenv(), getenv() clean up
In-Reply-To: Your message of "Thu, 13 Jan 2000 12:00:28 +0100 (MET)"
<Pine.GSO.4.02A.10001131154340.6438-100000@Pingvin.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10001131154340.6438-100000@Pingvin.DoCS.UU.SE>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000115143131E.t-ishii@sra.co.jp>
Date: Sat, 15 Jan 2000 14:31:31 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 20
Whatever you do, please do not set any environment variables from within
programs. It's evil.
Of course it's in my plan. I will eliminate them.
(3) Add a new function PQclientencoding() to extract client_encoding
from PGconn.How about PQencoding()?
Humm... someday we may have PQdatabasencoding(). So I think it's
better to have "client" on it not to be confused.
How about PQmblen(character, encoding)? Then you could call it PQmblen(c,
PQclientencoding(conn)) or PQmblen(c, other_encoding). That makes it more
general.
Good idea. Agreed.
--
Tatsuo Ishii
From bouncefilter Sat Jan 15 00:40:22 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA66620
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 00:39:46 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA02143;
Sat, 15 Jan 2000 00:39:25 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Peter opens a can of worms
In-reply-to: <Pine.LNX.4.21.0001150102160.344-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001150102160.344-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sat, 15 Jan 2000 04:04:56 +0100"
Date: Sat, 15 Jan 2000 00:39:25 -0500
Message-ID: <2140.947914765@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
On 2000-01-13, Tom Lane mentioned:
I have a feeling we will have to revert this change...
I'd ask you to reconsider.
If you found a solution to the %m issue, I'm a happy camper. I thought
all the too-many-arguments gripes were because of %m, but evidently
I was mistaken. Good work!
regards, tom lane
From bouncefilter Sat Jan 15 00:52:21 2000
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 AAA69635
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 00:51:34 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id OAA25338
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 14:51:32 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-19 [133.137.84.19])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id OAA02621
for <pgsql-hackers@postgreSQL.org>; Sat, 15 Jan 2000 14:51:30 +0900
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] libpq+MB/putenv(), getenv() clean up
In-Reply-To: <20000113105845O.t-ishii@sra.co.jp>
References: <20000113105845O.t-ishii@sra.co.jp>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000115145242R.t-ishii@sra.co.jp>
Date: Sat, 15 Jan 2000 14:52:42 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 39
I have committed changes below.
(1) Add a new member "int client_encoding" to struct pg_conn.
done.
(2) Add an argument which is a pointer to PGconn to PQsetenvPoll() so
that the client encoding can be set in (1) above.
Rather than adding new parameter, I changed the argument to PGconn *.
(3) Add a new function PQclientencoding() to extract client_encoding
from PGconn.
done.
(4) Change PQmblen() so that it extracts encoding info using
PQclientencoding() rather than calling getenv(). This also requires
add an argument which is a pointer to PGconn.
Now,
extern int PQmblen(const unsigned char *s, int encoding);
(Thanks goes to Peter for the suggestion)
(5) Change fe-print.c:do_filed() to add an argument which is a pointer to
PGconn.
I found the arugument PGresult *res of do_field() has a pointer to
PGconn. So I did not need to change the interface.
(6) lots of changes have been made to psql to adapt the changes above.
Though I have run the regression test with/without multibyte and did
not find particular problem, please let me know if you find anything
wrong with those changes.
--
Tatsuo Ishii
From bouncefilter Sat Jan 15 00:55:21 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA70271
for <hackers@postgreSQL.org>; Sat, 15 Jan 2000 00:54:44 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA02183;
Sat, 15 Jan 2000 00:54:11 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Peter Eisentraut <peter_e@gmx.net>, hackers@postgreSQL.org
Subject: Re: [HACKERS] psql variables fixed (?)
In-reply-to: <387FE4CB.BB2EE0C6@alumni.caltech.edu>
References: <Pine.LNX.4.21.0001140011200.1917-100000@localhost.localdomain>
<387FE4CB.BB2EE0C6@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Sat, 15 Jan 2000 03:08:59 +0000"
Date: Sat, 15 Jan 2000 00:54:11 -0500
Message-ID: <2180.947915651@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
I'd be a little reluctant to give up the alternate "::" syntax, only
because I'm not sure I trust the standards folks to not stomp on the
alternative at some point in the future.
Even more to the point, we now have a substantial pool of user
applications that rely on "::" (I know a lot of my company's
code does, for example). We can't just blow off those users.
Peter's current proposal seems OK to me, with the caveat that we
will have to be *very* circumspect about introducing additional
variables-automatically-defined-by-psql in the future. Every
time we do, we risk breaking existing user scripts, not unlike
what happens when we introduce a new reserved word in the backend
grammar.
Lane's Other Law: the price of success is backwards compatibility.
regards, tom lane
From bouncefilter Sat Jan 15 01:13:21 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA78568
for <hackers@postgreSQL.org>; Sat, 15 Jan 2000 01:13:15 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA02216;
Sat, 15 Jan 2000 01:12:59 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: hackers@postgreSQL.org
Subject: Standards (was Re: psql variables fixed (?))
In-reply-to: <3.0.1.32.20000114204912.0109f060@mail.pacifier.com>
References: <Pine.LNX.4.21.0001140011200.1917-100000@localhost.localdomain>
<3.0.1.32.20000114204912.0109f060@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Fri, 14 Jan 2000 20:49:12 -0800"
Date: Sat, 15 Jan 2000 01:12:59 -0500
Message-ID: <2213.947916779@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Don Baccus <dhogaza@pacifier.com> writes:
Which begs the question ... does Postgres.org have representation
on the standards commitees?
Not that I've heard about --- for that matter, is there any active
SQL standards committee?
Whether or not there's money available for development, I should
think minimal funding for participation in the standards committee
(i.e. travel and per-diem, maybe not a salary) wouldn't be hard to
scare up...
While I don't know anything about the SQL standards situation, I do know
how this game is played from past work with JPEG. The only effective
participants on the international standards committees are people who
work for corporate research labs of corporations with very deep pockets.
(Or, occasionally, professors with tenure at universities having very
deep pockets.)
JPEG, for example, used to have a regular schedule of three meetings
a year: one in the Americas, one in Europe, one in the Far East. Your
travel budget didn't stretch that far? Tough luck; you were a bystander
not a player. Not to mention that the real players would organize/host
a local meeting every so often --- better be able to budget a couple of
full-time secretaries to handle the details if you want to do that.
I don't think PostgreSQL, Inc is playing in that league, or has any
prospect of doing so soon. Nor would I want to be our representative
if we could do it. The Net has changed the rules about running
large-scale collaborations, but AFAICT the ISO hasn't heard yet.
regards, tom "professional bystander" lane
organizer, Independent JPEG Group
From bouncefilter Sat Jan 15 01:29:21 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA82243
for <hackers@postgresql.org>; Sat, 15 Jan 2000 01:28:25 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id CAA93376;
Sat, 15 Jan 2000 02:27:05 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 15 Jan 2000 02:27:05 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, hackers@postgresql.org
Subject: Re: [HACKERS] Standards (was Re: psql variables fixed (?))
In-Reply-To: <2213.947916779@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001150225200.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 15 Jan 2000, Tom Lane wrote:
I don't think PostgreSQL, Inc is playing in that league, or has any
prospect of doing so soon.
Things are picking up, and I'd *love* to be able to do stuff like that,
but "not any time soon"...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sat Jan 15 07:42:25 2000
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 HAA82656
for <pgsql-hackers@postgresql.org>;
Sat, 15 Jan 2000 07:42:09 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id VAA10239
for <pgsql-hackers@postgresql.org>;
Sat, 15 Jan 2000 21:42:07 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-8 [133.137.84.8])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id VAA04096
for <pgsql-hackers@postgresql.org>; Sat, 15 Jan 2000 21:42:06 +0900
To: pgsql-hackers@postgresql.org
Subject: pgbench added to contrib
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000115214319M.t-ishii@sra.co.jp>
Date: Sat, 15 Jan 2000 21:43:19 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 6
As I promised before, I have added a small tool called "pgbench",
performing TPC-B like benchmarking, to contrib. See
contrib/pgbench/README for more details.
--
Tatsuo Ishii
From bouncefilter Sat Jan 15 08:44:31 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA93710
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 08:43:43 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id GAA26485;
Sat, 15 Jan 2000 06:06:09 -0800 (PST)
Date: Sat, 15 Jan 2000 06:06:08 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: admin <admin@wtbwts.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org,
scrappy@hub.org
Subject: FreeBSD postgresql doc-HOWTO was: Re: [HACKERS] Revised nonblocking
patches + quasi docs
Message-ID: <20000115060608.K508@fw.wintelcom.net>
References: <20000114111430.A824@fw.wintelcom.net>
<Pine.BSF.4.10.10001141401330.84869-100000@server.b0x.com>
<20000114120516.D824@fw.wintelcom.net>
<387FE733.49D9A679@alumni.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <387FE733.49D9A679@alumni.caltech.edu>;
from lockhart@alumni.caltech.edu on Sat, Jan 15, 2000 at
03:19:15AM +0000
* Thomas Lockhart <lockhart@alumni.caltech.edu> [000114 19:42] wrote:
I've actually been trying to work on the sgml and failing miserably,
I have no clue how this stuff works (sgml compilation) are you asking
for a couple of paragraphs that describe the proposed changes?
If so I hope this suffices, if not some help on building the sgml
would be much appreciated:'course I run freebsd. :) I even have the docproj port installed,
however it seems that there's some things missing here, (see the
end of this message).
Perhaps someone can offer a step-by-step to building _postgresql's_
doc files, or maybe there's a machine out there where this will
build properly and someone can give me an account on it?You are probably very near having something working.
Yes, I can feel it, I just ran to the store to pick up the goat blood
and candles. :)
With the help of a friend Jeroen Ruigrok van der Werven, one of
the FreeBSD'doc folks I got it working here's what I needed to do:
install the textproc/docproj and textproc/docbook from /usr/ports,
maybe more packages are needed (dsssl-docbook-modular, dtd-catalogs),
i was installing everything hoping to get it to work...
setup my enviornment... (this ought to be mentioned in the docs)
export SMGL_ROOT=/usr/local/share/sgml
SGML_CATALOG_FILES=/usr/local/share/sgml/jade/catalog
SGML_CATALOG_FILES=/usr/local/share/sgml/html/catalog:$SGML_CATALOG_FILES
SGML_CATALOG_FILES=/usr/local/share/sgml/iso8879/catalog:$SGML_CATALOG_FILES
SGML_CATALOG_FILES=/usr/local/share/sgml/transpec/catalog:$SGML_CATALOG_FILES
SGML_CATALOG_FILES=/usr/local/share/sgml/docbook/catalog:$SGML_CATALOG_FILES
export SGML_CATALOG_FILES
then in the pgsql/doc/src dir:
gmake all \
HSTYLE=/usr/local/share/sgml/docbook/dsssl/modular/html/ \
PSTYLE=/usr/local/share/sgml/docbook/dsssl/modular/print/ \
wait a good long time...
viola.
Ok, I should have the docs for my code along with some help for
hapless FreeBSD users trying to work on this stuff in a bit.
I guess this means that Marc can't weasel his way out of doing
documentation anymore, or was that the point all along? :)
Btw, does anyone have some fixes so gvim doesn't barf doing syntax
highlighting on these sgml files?
-Alfred
From bouncefilter Sat Jan 15 11:39:33 2000
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA25629
for <hackers@postgresql.org>; Sat, 15 Jan 2000 11:38:30 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.243]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sat, 15 Jan 2000 10:38:56 -0600
Sender: ed
Message-ID: <3880A2D1.9251C455@austin.rr.com>
Date: Sat, 15 Jan 2000 10:39:45 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>, hackers@postgresql.org
Subject: Re: [HACKERS] psql variables fixed (?)
References: <Pine.LNX.4.21.0001140011200.1917-100000@localhost.localdomain>
<387FE4CB.BB2EE0C6@alumni.caltech.edu>
<2180.947915651@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Lane's Other Law: the price of success is backwards compatibility.
"And the onlookers breathed a sigh of relief..."
From bouncefilter Sat Jan 15 13:25:54 2000
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 NAA45024
for <hackers@postgresql.org>; Sat, 15 Jan 2000 13:25:27 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64382 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S69633AbQAOSYy>;
Sat, 15 Jan 2000 19:24:54 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129XzI-0008Mv-00
for hackers@postgresql.org; Sat, 15 Jan 2000 19:31:48 +0100
Date: Sat, 15 Jan 2000 19:31:48 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: flex
Message-ID: <Pine.LNX.4.21.0001151907590.386-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Maybe this has been discussed before my time, but why exactly is it that
we don't distribute lex'ed files, as with yacc'ed files?
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Jan 15 13:31:35 2000
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 NAA47140
for <hackers@postgresql.org>; Sat, 15 Jan 2000 13:30:38 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64528 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S69633AbQAOSaM>;
Sat, 15 Jan 2000 19:30:12 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129Y4i-0008ON-00
for hackers@postgresql.org; Sat, 15 Jan 2000 19:37:24 +0100
Date: Sat, 15 Jan 2000 19:37:24 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: TODO list
Message-ID: <Pine.LNX.4.21.0001151259300.386-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
* User who can create databases can modify pg_database table
Not anymore.
* Interlock to prevent DROP DATABASE on a database with running backends
I think Tom wanted this listed as an achievement, because it's already
done.
* Better interface for adding to pg_group
Done.
* Allow array on int8[]
Done. (Credit to Thomas, thought, he just forgot to apply the patch.)
* Make Absolutetime/Relativetime int4 because time_t can be int8 on some
ports
Does this mean the abstime/reltime types or all of them? I thought the
former were deprecated anyway.
* Permissions on indexes, prevent them?
Done (prevented)
* Make postgres user have a password by default
Done. (--pwprompt option, enter it blind twice, echo ALTER USER |
postgres; probably as secure as it gets)
* Update table SET table.value = 3 fails(SQL standard says this is OK)
Not the standard I'm looking at. Someone please enlighten me.
<update statement: searched> ::=
UPDATE <table name>
SET <set clause list>
[ WHERE <search condition> ]
<set clause list> ::=
<set clause> [ { <comma> <set clause> }... ]
<set clause> ::=
<object column> <equals operator> <update source>
<object column> ::= <column name>
<column name> ::= <identifier>
<identifier> ::=
[ <introducer><character set specification> ] <actual identifier>
<introducer> ::= <underscore>
<character set specification> ::=
{ nothing of interest }
<actual identifier> ::=
<regular identifier>
| <delimited identifier>
{ meaning a non-quoted identifier or a quoted one }
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Jan 15 14:32:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA62409
for <hackers@postgreSQL.org>; Sat, 15 Jan 2000 14:31:51 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA06304;
Sat, 15 Jan 2000 14:31:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001151931.OAA06304@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list
In-Reply-To: <Pine.LNX.4.21.0001151259300.386-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 15, 2000 07:37:24 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sat, 15 Jan 2000 14:31:17 -0500 (EST)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
* User who can create databases can modify pg_database table
Not anymore.
Done. Good.
* Interlock to prevent DROP DATABASE on a database with running backends
I think Tom wanted this listed as an achievement, because it's already
done.
Done.
* Better interface for adding to pg_group
Done.
Yes. I can remove the pg_group FAQ item after 7.0 is out to most
people.
* Allow array on int8[]
Done. (Credit to Thomas, thought, he just forgot to apply the patch.)
Good.
* Make Absolutetime/Relativetime int4 because time_t can be int8 on some
portsDoes this mean the abstime/reltime types or all of them? I thought the
former were deprecated anyway.
I think the idea is that it can roll over the mac int4 value. Not sure
about which types are active.
* Permissions on indexes, prevent them?
Done (prevented)
Good.
* Make postgres user have a password by default
Done. (--pwprompt option, enter it blind twice, echo ALTER USER |
postgres; probably as secure as it gets)
Perfect. We don't want to do it by default.
* Update table SET table.value = 3 fails(SQL standard says this is OK)
Not the standard I'm looking at. Someone please enlighten me.
<update statement: searched> ::=
UPDATE <table name>
SET <set clause list>
[ WHERE <search condition> ]<set clause list> ::=
<set clause> [ { <comma> <set clause> }... ]<set clause> ::=
<object column> <equals operator> <update source><object column> ::= <column name>
<column name> ::= <identifier>
<identifier> ::=
[ <introducer><character set specification> ] <actual identifier><introducer> ::= <underscore>
<character set specification> ::=
{ nothing of interest }<actual identifier> ::=
<regular identifier>
| <delimited identifier>{ meaning a non-quoted identifier or a quoted one }
I don't see anything in the spec that says you can use table.column on
the left-hand side of the equals. No?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 15 14:34:30 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA62655
for <hackers@postgreSQL.org>; Sat, 15 Jan 2000 14:33:35 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA06633;
Sat, 15 Jan 2000 14:32:51 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001151932.OAA06633@candle.pha.pa.us>
Subject: Re: [HACKERS] flex
In-Reply-To: <Pine.LNX.4.21.0001151907590.386-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 15, 2000 07:31:48 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sat, 15 Jan 2000 14:32:51 -0500 (EST)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
Maybe this has been discussed before my time, but why exactly is it that
we don't distribute lex'ed files, as with yacc'ed files?
Not sure. Are they more platform-dependent or lexer-dependent? Doesn't
the lexer call a lexer-specific library? Not sure.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 15 15:01:34 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA93935
for <hackers@postgreSQL.org>; Sat, 15 Jan 2000 15:01:16 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA19252;
Sat, 15 Jan 2000 12:00:35 -0800 (PST)
Message-Id: <3.0.1.32.20000115115500.010a78f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sat, 15 Jan 2000 11:55:00 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>, Peter Eisentraut <peter_e@gmx.net>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] TODO list
Cc: hackers@postgreSQL.org
In-Reply-To: <200001151931.OAA06304@candle.pha.pa.us>
References: <Pine.LNX.4.21.0001151259300.386-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:31 PM 1/15/00 -0500, Bruce Momjian wrote:
* Update table SET table.value = 3 fails(SQL standard says this is OK)
Not the standard I'm looking at. Someone please enlighten me.
If this is indeed the standard, it looks to me as though Bruce is
reading it right. Makes sense, too, only one table can be updated
at a time, so there's no opportunity for ambiguity in column names
on the left side. What's the point?
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sat Jan 15 16:45:34 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA16311
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 16:44:57 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max02-059.enterprise.net
[194.72.195.179])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id VAA15673
for <pgsql-hackers@postgreSQL.org>; Sat, 15 Jan 2000 21:44:52 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id VAA06452;
Sat, 15 Jan 2000 21:44:42 GMT
Message-Id: <200001152144.VAA06452@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: pgsql-hackers@postgreSQL.org, olly@linda.lfix.co.uk
Subject: Re: [HACKERS] Problem with foreign keys and inheritance
In-Reply-To: Message from "Oliver Elphick" <olly@lfix.co.uk> of "Thu,
13 Jan 2000 22:14:39 GMT." <200001132214.WAA24994@linda.lfix.co.uk>
References: <200001132214.WAA24994@linda.lfix.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 15 Jan 2000 21:44:42 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
"Oliver Elphick" wrote:
When I create a table that inherits from another table that uses foreign
keys, I get something like this:ERROR: cache lookup of attribute 10 in relation 124171 failed
This is happening in get_attribute_name() of backend/utils/adt/ruleutils.c
I'm still trying to track this down; it seems to be happening when the
backend is trying to fetch details of the ancestor class, in
deparse_expression().
However, I cannot find relation 124171; is there any way to find out
where a relation is, given only its oid?
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"For I know that my redeemer liveth, and that he shall
stand at the latter day upon the earth"
Job 19:25
From bouncefilter Sat Jan 15 22:20:42 2000
Received: from corvette.mascari.com (dhcp26142035.columbus.rr.com
[24.26.142.35]) by hub.org (8.9.3/8.9.3) with ESMTP id WAA83709
for <pgsql-hackers@postgresql.org>;
Sat, 15 Jan 2000 22:19:38 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id WAA07574
for <pgsql-hackers@postgresql.org>; Sat, 15 Jan 2000 22:18:13 -0500
Sender: mascarm@corvette.mascari.com
Message-ID: <3880F1F0.D9821033@mascari.com>
Date: Sat, 15 Jan 2000 17:17:21 -0500
From: Mike Mascari <mascarm@mascari.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: INDEX_MAX_KEYS and pg_dump
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello,
I grabbed last nights snapshot to come up with a diff for
pg_dump to generate COMMENT ON statements for user-defined
descriptions. However, I believe pg_dump is currently in a
broken state with respect to the dumping of indexes,
possibly related to the current work done with
INDEX_MAX_KEYS. Can anyone confirm this?
Thanks for any info,
Mike Mascari
From bouncefilter Sat Jan 15 18:25:38 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA33587
for <pgsql-hackers@postgresql.org>;
Sat, 15 Jan 2000 18:25:17 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.243]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sat, 15 Jan 2000 17:15:56 -0600
Sender: ed
Message-ID: <38810223.6AB9A33F@austin.rr.com>
Date: Sat, 15 Jan 2000 17:26:27 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Oliver Elphick <olly@lfix.co.uk>
CC: pgsql-hackers@postgresql.org, olly@linda.lfix.co.uk
Subject: Re: [HACKERS] Problem with foreign keys and inheritance
References: <200001132214.WAA24994@linda.lfix.co.uk>
<200001152144.VAA06452@linda.lfix.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Oliver Elphick wrote:
However, I cannot find relation 124171; is there any way to find out
where a relation is, given only its oid?
This might give you a pretty good hint...
select * from pg_attribute where attrelid = 124171;
Cheers,
Ed Loehr
From bouncefilter Sat Jan 15 18:31:39 2000
Received: from onestone.elsinore.klever.net (root@onestone.elsinore.klever.net
[207.175.129.2]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA36807
for <hackers@postgreSQL.org>; Sat, 15 Jan 2000 18:30:51 -0500 (EST)
(envelope-from sbirch@ironmountainsystems.com)
Received: from ironmountainsystems.com (ppp24.kross.klever.net
[209.203.65.24]) by onestone.elsinore.klever.net (8.8.7/8.8.0)
with ESMTP id PAA21062; Sat, 15 Jan 2000 15:29:45 -0800
Sender: sbirch@onestone.elsinore.klever.net
Message-ID: <388102EE.71E5FDF2@ironmountainsystems.com>
Date: Sat, 15 Jan 2000 15:29:50 -0800
From: Stephen Birch <sbirch@ironmountainsystems.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-SMP i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO list
References: <Pine.LNX.4.21.0001151259300.386-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Can we ALTER a table to drop a column yet, or is that still a TO DO item?
Steve
Peter Eisentraut wrote:
* User who can create databases can modify pg_database table
Not anymore.
* Interlock to prevent DROP DATABASE on a database with running backends
From bouncefilter Sat Jan 15 18:46:38 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA39958
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 18:46:09 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max03-017.enterprise.net
[194.72.196.17])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id XAA29903;
Sat, 15 Jan 2000 23:46:03 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id XAA13984;
Sat, 15 Jan 2000 23:46:01 GMT
Message-Id: <200001152346.XAA13984@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Ed Loehr <eloehr@austin.rr.com>
cc: Oliver Elphick <olly@lfix.co.uk>, pgsql-hackers@postgreSQL.org,
olly@linda.lfix.co.uk, olly@linda.lfix.co.uk
Subject: Re: [HACKERS] Problem with foreign keys and inheritance
In-Reply-To: Message from Ed Loehr <eloehr@austin.rr.com>
of "Sat, 15 Jan 2000 17:26:27 CST." <38810223.6AB9A33F@austin.rr.com>
References: <200001132214.WAA24994@linda.lfix.co.uk>
<200001152144.VAA06452@linda.lfix.co.uk>
<38810223.6AB9A33F@austin.rr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 15 Jan 2000 23:45:59 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Ed Loehr wrote:
Oliver Elphick wrote:
However, I cannot find relation 124171; is there any way to find out
where a relation is, given only its oid?This might give you a pretty good hint...
select * from pg_attribute where attrelid = 124171;
Nothing.
I tried looking for the oid in every system table listed by \dS - no joy :-(
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"For I know that my redeemer liveth, and that he shall
stand at the latter day upon the earth"
Job 19:25
From bouncefilter Sat Jan 15 19:04:38 2000
Received: from hu.tm.ee (ppp80.tele2.ee [212.107.33.80])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA44693
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 19:04:22 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 61B851323E; Sun, 16 Jan 2000 02:09:32 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <38810C3C.F15758B3@tm.ee>
Date: Sun, 16 Jan 2000 02:09:32 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Xun Cheng <xun@cs.ucsb.edu>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] [hackers]development suggestion needed
References: <200001140046.QAA17082@brubeck.cs.ucsb.edu>
<25266.947813004@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
xun@cs.ucsb.edu (Xun Cheng) writes:
I want to experiment with some new fast join algorithms.
Cool. Welcome aboard!
Could anyone tell me if
the directory /docs/pgsql/src/backend/executor is the
right place to startThe executor is only half the problem: you must also teach the
planner/optimizer how and when to use the new join type.Hiroshi Inoue has recently been down this path (adding support
for TID-based scans), and might be able to give you more specific
advice.1. Does postgresql do raw storage device management or it relies
on file system? My impression is no raw device. If no,
is it difficult to add it and possibly how?Postgres uses Unix files. We have avoided raw-device access mostly on
grounds of portability. To persuade people that such a change should go
into the distribution, you'd need to prove that *significantly* better
performance is obtained with raw access. I for one don't think it's a
foregone conclusion; Postgres gets considerable benefit from sitting
atop Unix kernel device schedulers and disk buffer caches.As far as the actual implementation goes, the low level access methods
go through a "storage manager" switch that was intended to allow for
the addition of a new storage manager, such as a raw-device manager.
So you could get a good deal of stuff working by implementing code that
parallels md.c/fd.c. The main problem at this point is that there is a
fair amount of utility code that goes out and does its own manipulation
of the database file structure. You'd need to clean that up by pushing
it all down below the storage manager switch (inventing new storage
manager calls as needed).that the available join algos implemented are nested loop
join (including index-based), hash join (which one? hybrid),
sort-merge join?Right. The hash join uses batching if it estimates that the relation
is too large to fit in memory; is that what you call "hybrid"?
I've heard the word "hybrid" being used of a scheme where you hash each
key of a multi-key index separately and then concatenate the hashes for
the index. That way you can use the index for accessing also subsets of
keys by examining only the buxkets with matching hash sections.
Does postgres do it even when generating the keys ?
I'd guess it does, as each hashable type has a hashing function.
OTOH pg probably does not use it for finding by the 3rd field of index ?
--------
Hannu
From bouncefilter Sun Jan 16 00:26:41 2000
Received: from pcr.ca (www.pcr.ca [207.139.158.13] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id AAA11301
for <pgsql-hackers@postgresql.org>;
Sun, 16 Jan 2000 00:26:04 -0500 (EST)
(envelope-from admin@wtbwts.com)
Received: by pcr.ca (Postfix, from userid 1000)
id 7E96C1FE8; Sun, 16 Jan 2000 00:25:07 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1])
by pcr.ca (Postfix) with ESMTP id 641071F8C
for <pgsql-hackers@postgresql.org>;
Sun, 16 Jan 2000 00:25:07 +0000 (GMT)
Date: Sun, 16 Jan 2000 00:25:07 +0000 (GMT)
From: Marc Tardif <admin@wtbwts.com>
X-Sender: admin@server.b0x.com
To: pgsql-hackers@postgresql.org
Subject: rules with oid
Message-ID: <Pine.BSF.4.10.10001160023560.90272-100000@server.b0x.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From bouncefilter Sat Jan 15 20:26:37 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA59966
for <hackers@postgreSQL.org>; Sat, 15 Jan 2000 20:26:09 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA17247;
Sat, 15 Jan 2000 20:25:32 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] flex
In-reply-to: <Pine.LNX.4.21.0001151907590.386-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001151907590.386-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sat, 15 Jan 2000 19:31:48 +0100"
Date: Sat, 15 Jan 2000 20:25:32 -0500
Message-ID: <17244.947985932@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
Maybe this has been discussed before my time, but why exactly is it that
we don't distribute lex'ed files, as with yacc'ed files?
No particularly good reason I suppose... if we did that, we could get
rid of that whole 'lextest' business, too.
regards, tom lane
From bouncefilter Sat Jan 15 20:32:39 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA63842
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 20:32:21 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA17271;
Sat, 15 Jan 2000 20:31:57 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: Ed Loehr <eloehr@austin.rr.com>, pgsql-hackers@postgreSQL.org,
olly@linda.lfix.co.uk
Subject: Re: [HACKERS] Problem with foreign keys and inheritance
In-reply-to: <200001152346.XAA13984@linda.lfix.co.uk>
References: <200001132214.WAA24994@linda.lfix.co.uk>
<200001152144.VAA06452@linda.lfix.co.uk>
<38810223.6AB9A33F@austin.rr.com>
<200001152346.XAA13984@linda.lfix.co.uk>
Comments: In-reply-to "Oliver Elphick" <olly@lfix.co.uk>
message dated "Sat, 15 Jan 2000 23:45:59 +0000"
Date: Sat, 15 Jan 2000 20:31:56 -0500
Message-ID: <17268.947986316@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Oliver Elphick" <olly@lfix.co.uk> writes:
However, I cannot find relation 124171; is there any way to find out
where a relation is, given only its oid?This might give you a pretty good hint...
select * from pg_attribute where attrelid = 124171;
Actually, "select * from pg_class where oid = 124171" is the canonical
answer; if that doesn't produce anything, you have no such table.
I tried looking for the oid in every system table listed by \dS - no joy :-(
Is it possible that you dropped the table in question since that try?
If you recreated it, it wouldn't have the same OID the second time.
Another possibility is that the rule dumper is picking up a completely
wrong number for some reason. I thought that code was pretty solid by
now, but it might still have some glitches left.
If you provided an SQL script that reproduces the problem, more people
might be motivated to look for it...
regards, tom lane
From bouncefilter Sat Jan 15 20:39:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA64572
for <hackers@postgreSQL.org>; Sat, 15 Jan 2000 20:39:05 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA17313;
Sat, 15 Jan 2000 20:38:33 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, hackers@postgreSQL.org
Subject: Re: [HACKERS] flex
In-reply-to: <200001151932.OAA06633@candle.pha.pa.us>
References: <200001151932.OAA06633@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sat, 15 Jan 2000 14:32:51 -0500"
Date: Sat, 15 Jan 2000 20:38:33 -0500
Message-ID: <17310.947986713@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Maybe this has been discussed before my time, but why exactly is it that
we don't distribute lex'ed files, as with yacc'ed files?
Not sure. Are they more platform-dependent or lexer-dependent? Doesn't
the lexer call a lexer-specific library? Not sure.
flex has a lexer-specific library (libfl.a), but as far as I can tell
our scanners don't call it. In fact our build process has no provision
for adding -lfl to the link, which I used to think was an oversight, but
now it's starting to seem like a good idea. We could ship scan.c et al
in the same way we handle the yacc/bison output files, and it should
work everywhere.
If we were going to do this, I'd vote for making sure that *all* the
yacc files are pregenerated (currently, we only take care of the larger
ones), and then most people wouldn't need either flex or bison to build.
regards, tom lane
From bouncefilter Sat Jan 15 21:04:37 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA70227
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 21:03:51 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA17392
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 21:03:50 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: I think we need an explicit parsetree node for CAST
Date: Sat, 15 Jan 2000 21:03:50 -0500
Message-ID: <17389.947988230@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I noticed today that the system drops any "typmod" modifier associated
with a type name being casted to. For example,
regression=# select '1.23456'::numeric(7,2);
?column?
----------
1.23456 --- should be 1.23
(1 row)
regression=# select CAST ('1234567.89' AS numeric(4,1));
?column?
------------
1234567.89 --- should raise a numeric-overflow error
(1 row)
These particular cases can be fixed with a one-line patch, I think,
because there is storage in an A_Const node to hold a reference to
a Typename, which includes typmod. parse_expr.c is just forgetting
to pass the typmod to parser_typecast().
BUT: there isn't any equally simple patch when the value being casted
is not a constant. For instance
select field1 :: numeric(7,2) from table1;
cannot work properly now, because gram.y transforms it into
select numeric(field1) from table;
which (a) drops the typmod and (b) bypasses all of the intelligence
that should be used to determine how to coerce the type.
What I think we need is to add a new parsetree node type that explicitly
represents a CAST operator, and then modify parse_expr.c to transform
that node type into an appropriate function call (or, perhaps, nothing
at all if the source value is already the right type).
Comments?
regards, tom lane
From bouncefilter Sat Jan 15 21:31:35 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA74044
for <hackers@postgreSQL.org>; Sat, 15 Jan 2000 21:30:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA26366;
Sat, 15 Jan 2000 21:29:18 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001160229.VAA26366@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list
In-Reply-To: <388102EE.71E5FDF2@ironmountainsystems.com> from Stephen Birch at
"Jan 15, 2000 03:29:50 pm"
To: Stephen Birch <sbirch@ironmountainsystems.com>
Date: Sat, 15 Jan 2000 21:29:18 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Can we ALTER a table to drop a column yet, or is that still a TO DO item?
Still a TODO item.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 15 21:38:41 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA76322
for <hackers@postgreSQL.org>; Sat, 15 Jan 2000 21:38:02 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA26882;
Sat, 15 Jan 2000 21:35:31 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001160235.VAA26882@candle.pha.pa.us>
Subject: Re: [HACKERS] flex
In-Reply-To: <17310.947986713@sss.pgh.pa.us> from Tom Lane at "Jan 15,
2000 08:38:33 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 15 Jan 2000 21:35:31 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Added to TODO list.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Maybe this has been discussed before my time, but why exactly is it that
we don't distribute lex'ed files, as with yacc'ed files?Not sure. Are they more platform-dependent or lexer-dependent? Doesn't
the lexer call a lexer-specific library? Not sure.flex has a lexer-specific library (libfl.a), but as far as I can tell
our scanners don't call it. In fact our build process has no provision
for adding -lfl to the link, which I used to think was an oversight, but
now it's starting to seem like a good idea. We could ship scan.c et al
in the same way we handle the yacc/bison output files, and it should
work everywhere.If we were going to do this, I'd vote for making sure that *all* the
yacc files are pregenerated (currently, we only take care of the larger
ones), and then most people wouldn't need either flex or bison to build.regards, tom lane
************
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 15 21:38:41 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA76388
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 21:38:28 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA27062;
Sat, 15 Jan 2000 21:37:06 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001160237.VAA27062@candle.pha.pa.us>
Subject: Re: [HACKERS] I think we need an explicit parsetree node for CAST
In-Reply-To: <17389.947988230@sss.pgh.pa.us> from Tom Lane at "Jan 15,
2000 09:03:50 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 15 Jan 2000 21:37:06 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
These particular cases can be fixed with a one-line patch, I think,
because there is storage in an A_Const node to hold a reference to
a Typename, which includes typmod. parse_expr.c is just forgetting
to pass the typmod to parser_typecast().BUT: there isn't any equally simple patch when the value being casted
is not a constant. For instanceselect field1 :: numeric(7,2) from table1;
cannot work properly now, because gram.y transforms it into
select numeric(field1) from table;
which (a) drops the typmod and (b) bypasses all of the intelligence
that should be used to determine how to coerce the type.What I think we need is to add a new parsetree node type that explicitly
represents a CAST operator, and then modify parse_expr.c to transform
that node type into an appropriate function call (or, perhaps, nothing
at all if the source value is already the right type).
I have on the TODO list, and once considered adding more passing around
of atttypmod in the parser to keep such information. Maybe I shoud do
that first to see what happens and what gets fixed.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 15 22:01:37 2000
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 WAA81199
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 22:01:07 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA27171;
Sat, 15 Jan 2000 21:41:09 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001160241.VAA27171@candle.pha.pa.us>
Subject: Re: [HACKERS] I think we need an explicit parsetree node for CAST
In-Reply-To: <17389.947988230@sss.pgh.pa.us> from Tom Lane at "Jan 15,
2000 09:03:50 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 15 Jan 2000 21:41:09 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
These particular cases can be fixed with a one-line patch, I think,
because there is storage in an A_Const node to hold a reference to
a Typename, which includes typmod. parse_expr.c is just forgetting
to pass the typmod to parser_typecast().BUT: there isn't any equally simple patch when the value being casted
is not a constant. For instanceselect field1 :: numeric(7,2) from table1;
cannot work properly now, because gram.y transforms it into
select numeric(field1) from table;
which (a) drops the typmod and (b) bypasses all of the intelligence
that should be used to determine how to coerce the type.What I think we need is to add a new parsetree node type that explicitly
represents a CAST operator, and then modify parse_expr.c to transform
that node type into an appropriate function call (or, perhaps, nothing
at all if the source value is already the right type).
Actually, I think I never made the additional atttypmod changes because
no one had ever reported a problem, and I was confused by that.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 15 23:32:37 2000
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 XAA01174
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 23:31:43 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA28804;
Sat, 15 Jan 2000 23:05:30 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001160405.XAA28804@candle.pha.pa.us>
Subject: Re: [HACKERS] INDEX_MAX_KEYS and pg_dump
In-Reply-To: <3880F1F0.D9821033@mascari.com> from Mike Mascari at "Jan 15,
2000
05:17:21 pm"
To: Mike Mascari <mascarm@mascari.com>
Date: Sat, 15 Jan 2000 23:05:30 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hello,
I grabbed last nights snapshot to come up with a diff for
pg_dump to generate COMMENT ON statements for user-defined
descriptions. However, I believe pg_dump is currently in a
broken state with respect to the dumping of indexes,
possibly related to the current work done with
INDEX_MAX_KEYS. Can anyone confirm this?
I just looked and I don't see any problems.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 16 11:32:44 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA79146
for <pgsql-hackers@postgresql.org>;
Sun, 16 Jan 2000 11:32:43 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA13160;
Sun, 16 Jan 2000 08:31:44 -0800 (PST)
Message-Id: <3.0.1.32.20000115200730.010ac290@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sat, 15 Jan 2000 20:07:30 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] I think we need an explicit parsetree node for
CAST
In-Reply-To: <17389.947988230@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 09:03 PM 1/15/00 -0500, Tom Lane wrote:
What I think we need is to add a new parsetree node type that explicitly
represents a CAST operator, and then modify parse_expr.c to transform
that node type into an appropriate function call (or, perhaps, nothing
at all if the source value is already the right type).Comments?
Well, I hate to keep popping up wearing my compiler-writer hat, but
yes, this seems obvious. If the casting notation includes type
modifications like precision information then the simple expression
type_name(expr) can't ever match it. The casting notation must be
rejected or properly executed. Silent errors of this type are simply
unforgivable. Either an error or a proper transformation (presumably
to a function that takes precision and scale parameters) is fine, but
silent and incorrect execution is a major sin.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sat Jan 15 23:16:37 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA95780
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 23:16:20 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA17933
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 23:16:12 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: pg_dump not in very good shape
Date: Sat, 15 Jan 2000 23:16:12 -0500
Message-ID: <17930.947996172@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I have repaired the most recently introduced coredump in pg_dump,
but it still crashes on the regression test database.
Issue 1:
The "most recently introduced coredump" came from the change to
oidvector/int2vector to suppress trailing zeroes in the output
routine. pg_dump was assuming that it would see exactly the
right number of zeroes, and wasn't bothering to initialize any
leftover array locations --- but it would happily try to dereference
those locations later on. Ugh.
Although cleaning up pg_dump's code is clearly good practice, maybe
this should raise a flag about whether suppressing the zeroes is
a good idea. Are there any client applications that will break
because of this change? I'm not sure...
Issue 2:
The reason it's still broken is that the pqexpbuffer.c code I added to
libpq doesn't support adding more than 1K characters to an "expansible
string" in any one appendPQExpBuffer() call. pg_dump tries to use that
routine to format function definitions, which can easily be over 1K.
(Very likely there are other places in pg_dump that have similar
problems, but this is the one you hit first when trying to pg_dump the
regression DB.) That 1K limitation was OK when the module was just used
internally in libpq, but if we're going to allow pg_dump to use it, we
probably ought to relax the limitation.
The equivalent backend code already has solved this problem, but it
solved it by using vsnprintf() which isn't available everywhere.
We have a vsnprintf() emulation in backend/port, so in theory we
could link that routine into libpq if we are on a platform that
hasn't got vsnprintf.
The thing that bothers me about that is that if libpq exports a
vsnprintf routine that's different from the system version, we
could find ourselves changing the behavior of applications that
thought they were calling the local system's vsnprintf. (The
backend/port module would get linked if either snprintf() or
vsnprintf() is missing --- there are machines that have only one
--- and we'd effectively replace the system definition of the
one that the local system did have.) That's not good.However, the alternative of hacking pg_dump so it doesn't try to
format more than 1K at a time is mighty unattractive as well.
I am inclined to go ahead and insert vsnprintf into libpq.
The risk of problems seems pretty small (and it's zero on any
machine with a reasonably recent libc, since then vsnprintf
will be in libc and we won't link our version). The risk of
missing a buffer-overrun condition in pg_dump, and shipping
a pg_dump that will fail on someone's database, seems worse.
Comments? Better ideas?
regards, tom lane
From bouncefilter Sat Jan 15 23:24:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA96853
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 23:23:59 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA17949;
Sat, 15 Jan 2000 23:22:42 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] I think we need an explicit parsetree node for CAST
In-reply-to: <200001160241.VAA27171@candle.pha.pa.us>
References: <200001160241.VAA27171@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sat, 15 Jan 2000 21:41:09 -0500"
Date: Sat, 15 Jan 2000 23:22:42 -0500
Message-ID: <17946.947996562@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Actually, I think I never made the additional atttypmod changes because
no one had ever reported a problem, and I was confused by that.
I think that after further discussion, we concluded that it wasn't
really possible to determine an atttypmod value to attach to the
result of most expressions. However, CAST is a special case because
there *is* a typmod value associated with the Typename node. The
thing I want to do is make sure we hold onto that value long enough
to use it...
regards, tom lane
From bouncefilter Sat Jan 15 23:52:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA04168
for <pgsql-hackers@postgreSQL.org>;
Sat, 15 Jan 2000 23:52:31 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA18022;
Sat, 15 Jan 2000 23:51:59 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Mike Mascari <mascarm@mascari.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] INDEX_MAX_KEYS and pg_dump
In-reply-to: <200001160405.XAA28804@candle.pha.pa.us>
References: <200001160405.XAA28804@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sat, 15 Jan 2000 23:05:30 -0500"
Date: Sat, 15 Jan 2000 23:51:59 -0500
Message-ID: <18019.947998319@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
descriptions. However, I believe pg_dump is currently in a
broken state with respect to the dumping of indexes,
possibly related to the current work done with
INDEX_MAX_KEYS. Can anyone confirm this?
I just looked and I don't see any problems.
It was broken --- I committed fixes for it at about 11PM EST.
(The same problem as for func args --- it wasn't coping with
zero suppression in oidvectorout/int2vectorout.)
regards, tom lane
From bouncefilter Sun Jan 16 00:37:43 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA15583
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 00:37:01 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA08522;
Sun, 16 Jan 2000 00:36:21 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001160536.AAA08522@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_dump not in very good shape
In-Reply-To: <17930.947996172@sss.pgh.pa.us> from Tom Lane at "Jan 15,
2000 11:16:12 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 16 Jan 2000 00:36:21 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have repaired the most recently introduced coredump in pg_dump,
but it still crashes on the regression test database.Issue 1:
The "most recently introduced coredump" came from the change to
oidvector/int2vector to suppress trailing zeroes in the output
routine. pg_dump was assuming that it would see exactly the
right number of zeroes, and wasn't bothering to initialize any
leftover array locations --- but it would happily try to dereference
those locations later on. Ugh.Although cleaning up pg_dump's code is clearly good practice, maybe
this should raise a flag about whether suppressing the zeroes is
a good idea. Are there any client applications that will break
because of this change? I'm not sure...
I think we are OK. There are very few places the vectors are used.
They really weren't used even as part of initdb except to define the
types. Makes sense pg_dump uses it, I guess, but I can't imagine other
apps using it. With a definable length, I think we have to supress the
zero padding.
I am inclined to go ahead and insert vsnprintf into libpq.
The risk of problems seems pretty small (and it's zero on any
machine with a reasonably recent libc, since then vsnprintf
will be in libc and we won't link our version). The risk of
missing a buffer-overrun condition in pg_dump, and shipping
a pg_dump that will fail on someone's database, seems worse.
You bring up an interesting point. I say just link it in and see what
happens. No real good way to know how much memory sprintf needs.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 16 00:40:37 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA15960
for <pgsql-hackers@postgresql.org>;
Sun, 16 Jan 2000 00:40:01 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA08651;
Sun, 16 Jan 2000 00:39:53 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001160539.AAA08651@candle.pha.pa.us>
Subject: Re: [HACKERS] I think we need an explicit parsetree node for CAST
In-Reply-To: <17946.947996562@sss.pgh.pa.us> from Tom Lane at "Jan 15,
2000 11:22:42 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 16 Jan 2000 00:39:53 -0500 (EST)
CC: pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Actually, I think I never made the additional atttypmod changes because
no one had ever reported a problem, and I was confused by that.I think that after further discussion, we concluded that it wasn't
really possible to determine an atttypmod value to attach to the
result of most expressions. However, CAST is a special case because
there *is* a typmod value associated with the Typename node. The
thing I want to do is make sure we hold onto that value long enough
to use it...
I found the area you mentioned and fixed it. Seems the other areas I
remember being a problem were fixed by me or someone else, maybe you.
I remember makeResdom and makeVar having bogus entries sometimes, but I
see now they are all fixed.
I see your issue, and I don't know the code well enough to comment on
it.
I was able to do:
test=> select 'x' as fred into test ;
NOTICE: Attribute 'fred' has an unknown type
Relation created; continue
SELECT
test=> \d test
Table "test"
Attribute | Type | Extra
-----------+---------+-------
fred | unknown |
---------------------------------------------------------------------------
test=> select 'x'::varchar as fred into test ;
SELECT
test=> \d test
Table "test"
Attribute | Type | Extra
-----------+------------+-------
fred | varchar(0) |
Seems we should disallow this. This last one is the one you want to
fix:
---------------------------------------------------------------------------
test=> select 'x'::varchar(20) as fred into test ;
SELECT
test=> \d test
Table "test"
Attribute | Type | Extra
-----------+------------+-------
fred | varchar(0) |
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 16 00:41:37 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA16007
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 00:40:38 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA08665;
Sun, 16 Jan 2000 00:40:21 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001160540.AAA08665@candle.pha.pa.us>
Subject: Re: [HACKERS] INDEX_MAX_KEYS and pg_dump
In-Reply-To: <18019.947998319@sss.pgh.pa.us> from Tom Lane at "Jan 15,
2000 11:51:59 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 16 Jan 2000 00:40:21 -0500 (EST)
CC: Mike Mascari <mascarm@mascari.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
descriptions. However, I believe pg_dump is currently in a
broken state with respect to the dumping of indexes,
possibly related to the current work done with
INDEX_MAX_KEYS. Can anyone confirm this?I just looked and I don't see any problems.
It was broken --- I committed fixes for it at about 11PM EST.
(The same problem as for func args --- it wasn't coping with
zero suppression in oidvectorout/int2vectorout.)
Thanks. I missed that.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 16 00:41:37 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA16061
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 00:40:57 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA08675;
Sun, 16 Jan 2000 00:40:49 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001160540.AAA08675@candle.pha.pa.us>
Subject: Re: [HACKERS] I think we need an explicit parsetree node for CAST
In-Reply-To: <17389.947988230@sss.pgh.pa.us> from Tom Lane at "Jan 15,
2000 09:03:50 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 16 Jan 2000 00:40:49 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have applied a patch for this one.
I noticed today that the system drops any "typmod" modifier associated
with a type name being casted to. For example,regression=# select '1.23456'::numeric(7,2);
?column?
----------
1.23456 --- should be 1.23
(1 row)regression=# select CAST ('1234567.89' AS numeric(4,1));
?column?
------------
1234567.89 --- should raise a numeric-overflow error
(1 row)These particular cases can be fixed with a one-line patch, I think,
because there is storage in an A_Const node to hold a reference to
a Typename, which includes typmod. parse_expr.c is just forgetting
to pass the typmod to parser_typecast().BUT: there isn't any equally simple patch when the value being casted
is not a constant. For instanceselect field1 :: numeric(7,2) from table1;
cannot work properly now, because gram.y transforms it into
select numeric(field1) from table;
which (a) drops the typmod and (b) bypasses all of the intelligence
that should be used to determine how to coerce the type.What I think we need is to add a new parsetree node type that explicitly
represents a CAST operator, and then modify parse_expr.c to transform
that node type into an appropriate function call (or, perhaps, nothing
at all if the source value is already the right type).Comments?
regards, tom lane
************
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 16 01:26:37 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA29259
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 01:26:23 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA19748;
Sun, 16 Jan 2000 01:25:59 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] I think we need an explicit parsetree node for CAST
In-reply-to: <200001160540.AAA08675@candle.pha.pa.us>
References: <200001160540.AAA08675@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sun, 16 Jan 2000 00:40:49 -0500"
Date: Sun, 16 Jan 2000 01:25:58 -0500
Message-ID: <19745.948003958@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I have applied a patch for this one.
Right, you saw the parser_typecast mistake. But the problem of doing
it properly for non-constant input to the CAST is still open.
regards, tom lane
From bouncefilter Sun Jan 16 01:45:40 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA33992
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 01:44:49 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA09781;
Sun, 16 Jan 2000 01:44:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001160644.BAA09781@candle.pha.pa.us>
Subject: Re: [HACKERS] I think we need an explicit parsetree node for CAST
In-Reply-To: <19745.948003958@sss.pgh.pa.us> from Tom Lane at "Jan 16,
2000 01:25:58 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 16 Jan 2000 01:44:37 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I have applied a patch for this one.
Right, you saw the parser_typecast mistake. But the problem of doing
it properly for non-constant input to the CAST is still open.
Yes, and constants with cases in SELECT INTO are broken too.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 16 01:58:38 2000
Received: from munn.com (kmunn.munn.com [209.123.248.252])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA35227
for <pgsql-hackers@postgresql.org>;
Sun, 16 Jan 2000 01:57:58 -0500 (EST) (envelope-from kmunn@munn.com)
Received: from localhost (kmunn@localhost)
by munn.com (8.9.1/8.9.1) with ESMTP id BAA27727
for <pgsql-hackers@postgresql.org>; Sun, 16 Jan 2000 01:57:41 -0500
Date: Sun, 16 Jan 2000 01:57:41 -0500 (EST)
From: Kristofer Munn <kmunn@munn.com>
To: pgsql-hackers@postgresql.org
Subject: Temp Tables: Trying to delete a reldesc...
Message-ID: <Pine.LNX.4.04.10001160153450.27063-100000@munn.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi all. Running 6.5.3 on Intel Linux. I think problems related to this
have been reported in the past but the mailing list archives are running
incredibly slowly lately so I'm not *absolutely* sure:
[PostgreSQL 6.5.3 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66]
mail=> begin transaction ;
BEGIN
mail=> create temp table tbl1 ( x int4 ) ;
CREATE
mail=> drop table tbl1 ;
DROP
mail=> commit transaction ;
NOTICE: trying to delete a reldesc that does not exist.
NOTICE: trying to delete a reldesc that does not exist.
END
mail=>
A two-parter:
(1) For myself: Is this at all dangerous/problematic for my database?
(2) For Postgres: Is this addressed in the latest 7.0 source or on the
TODO list?
Thanks...
- K
Kristofer Munn * KMI * 973-509-9414 * AIM KrMunn * http://www.munn.com/
From bouncefilter Sun Jan 16 02:31:38 2000
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 CAA44750
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 02:31:34 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
CAA10667;
Sun, 16 Jan 2000 02:09:44 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001160709.CAA10667@candle.pha.pa.us>
Subject: Re: [HACKERS] Temp Tables: Trying to delete a reldesc...
In-Reply-To: <Pine.LNX.4.04.10001160153450.27063-100000@munn.com> from
Kristofer Munn at "Jan 16, 2000 01:57:41 am"
To: Kristofer Munn <kmunn@munn.com>
Date: Sun, 16 Jan 2000 02:09:44 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hi all. Running 6.5.3 on Intel Linux. I think problems related to this
have been reported in the past but the mailing list archives are running
incredibly slowly lately so I'm not *absolutely* sure:[PostgreSQL 6.5.3 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66]
mail=> begin transaction ;
BEGIN
mail=> create temp table tbl1 ( x int4 ) ;
CREATE
mail=> drop table tbl1 ;
DROP
mail=> commit transaction ;
NOTICE: trying to delete a reldesc that does not exist.
NOTICE: trying to delete a reldesc that does not exist.
END
mail=>A two-parter:
(1) For myself: Is this at all dangerous/problematic for my database?
Not a problem. Was some issue with flushing the cache, I bet.
(2) For Postgres: Is this addressed in the latest 7.0 source or on the
TODO list?
Fixed in current tree.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 16 02:14:38 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA40078
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 02:13:48 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA19840;
Sun, 16 Jan 2000 02:13:20 -0500 (EST)
To: Kristofer Munn <kmunn@munn.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Temp Tables: Trying to delete a reldesc...
In-reply-to: <Pine.LNX.4.04.10001160153450.27063-100000@munn.com>
References: <Pine.LNX.4.04.10001160153450.27063-100000@munn.com>
Comments: In-reply-to Kristofer Munn <kmunn@munn.com>
message dated "Sun, 16 Jan 2000 01:57:41 -0500"
Date: Sun, 16 Jan 2000 02:13:19 -0500
Message-ID: <19837.948006799@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Kristofer Munn <kmunn@munn.com> writes:
[ 6.5.3 acts funny about deleting a temp table created in the same
transaction ]
(1) For myself: Is this at all dangerous/problematic for my database?
AFAIR the notice is harmless; we'd have tried harder to back-patch a
fix if the consequences of the bug were critical.
(2) For Postgres: Is this addressed in the latest 7.0 source or on the
TODO list?
It's fixed in current sources.
regards, tom lane
From bouncefilter Sun Jan 16 02:41:38 2000
Received: from munn.com (kmunn.munn.com [209.123.248.252])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA45510
for <pgsql-hackers@postgresql.org>;
Sun, 16 Jan 2000 02:41:04 -0500 (EST) (envelope-from kmunn@munn.com)
Received: from localhost (kmunn@localhost)
by munn.com (8.9.1/8.9.1) with ESMTP id CAA28139
for <pgsql-hackers@postgresql.org>; Sun, 16 Jan 2000 02:41:02 -0500
Date: Sun, 16 Jan 2000 02:41:02 -0500 (EST)
From: Kristofer Munn <kmunn@munn.com>
To: pgsql-hackers@postgresql.org
Subject: SELECT...FOR UPDATE OF class_name
Message-ID: <Pine.LNX.4.04.10001160236240.28091-100000@munn.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi all - ran into this little parser idiosyncrasy today... Workaround was
simple but this should probably go on somebody's list somewhere.
[PostgreSQL 6.5.3 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66]
mail=> create table tbl1 ( id1 int4 );
CREATE
mail=> create table tbl2 ( id2 int4, id1 int4 ) ;
CREATE
mail=> select 1 from tbl2 t2, tbl1 t1 where t1.id1 = t2.id1 and
t2.id1 = 7 for update ;
?column?
--------
(0 rows)
mail=> select 1 from tbl2 t2, tbl1 t1 where t1.id1 = t2.id1 and
t2.id1 = 7 for update of t2;
?column?
--------
(0 rows)
mail=> select 1 from tbl2 t2, tbl1 t1 where t1.id1 = t2.id1 and
t2.id1 = 7 for update of tbl2;
ERROR: FOR UPDATE: relation tbl2 not found in FROM clause
- K
Kristofer Munn * KMI * 973-509-9414 * AIM KrMunn * http://www.munn.com/
From bouncefilter Sun Jan 16 03:10:38 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA55312
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 03:09:43 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id DAA19956;
Sun, 16 Jan 2000 03:09:26 -0500 (EST)
To: Kristofer Munn <kmunn@munn.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] SELECT...FOR UPDATE OF class_name
In-reply-to: <Pine.LNX.4.04.10001160236240.28091-100000@munn.com>
References: <Pine.LNX.4.04.10001160236240.28091-100000@munn.com>
Comments: In-reply-to Kristofer Munn <kmunn@munn.com>
message dated "Sun, 16 Jan 2000 02:41:02 -0500"
Date: Sun, 16 Jan 2000 03:09:26 -0500
Message-ID: <19952.948010166@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Kristofer Munn <kmunn@munn.com> writes:
select 1 from tbl2 t2, tbl1 t1 where t1.id1 = t2.id1 and
t2.id1 = 7 for update of tbl2;
ERROR: FOR UPDATE: relation tbl2 not found in FROM clause
I believe the error message is correct; you should have written
select 1 from tbl2 t2, tbl1 t1 where t1.id1 = t2.id1 and
t2.id1 = 7 for update of t2;
A lot of people do not realize that writing an alias for a table
in FROM means that as far as all the rest of that query is concerned,
that alias *is* the name of the table. The original table name is
completely masked by the alias. This must be so, because one of the
main reasons for the alias facility is to resolve ambiguity when you
are doing self-joins. Consider
select * from person p1, person p2 where p1.spouse = p2.id;
If you wrote instead
select * from person p1, person p2 where p1.spouse = person.id;
which instance of the person table is being referenced? SQL resolves
this by treating it as an error: there is no table named person
available from that FROM clause.
regards, tom lane
From bouncefilter Sun Jan 16 07:00:44 2000
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 HAA95538
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 07:00:04 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <CZZ0L0J5>; Sun, 16 Jan 2000 13:56:44 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C448@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] pg_dump not in very good shape
Date: Sun, 16 Jan 2000 13:52:37 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Tom, I went through all the places in pg_dump where a format string was used
to add a string to the buffer (I believe it's only a problem when using
snprintf, which, I think, is only used if you pass a format string), and
either removed the format string by passing in a single variable at a time,
or making sure that only things like db object names (which have a size
limit significantly less than 1kB) were passed in using a format string. Of
course, maybe I missed some places, but it shouldn't be a real problem.
That's why there are those particularly ugly pieces of code where the
appendText (or whetever it is) function gets called repeatedly. Not pretty,
but it should always work.
Am I wrong in assuming the the snprintf function only gets used when using a
format string, or is it always used?
MikeA
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Sunday, January 16, 2000 6:16 AM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] pg_dump not in very good shapeI have repaired the most recently introduced coredump in pg_dump,
but it still crashes on the regression test database.Issue 1:
The "most recently introduced coredump" came from the change to
oidvector/int2vector to suppress trailing zeroes in the output
routine. pg_dump was assuming that it would see exactly the
right number of zeroes, and wasn't bothering to initialize any
leftover array locations --- but it would happily try to dereference
those locations later on. Ugh.Although cleaning up pg_dump's code is clearly good practice, maybe
this should raise a flag about whether suppressing the zeroes is
a good idea. Are there any client applications that will break
because of this change? I'm not sure...Issue 2:
The reason it's still broken is that the pqexpbuffer.c code
I added to
libpq doesn't support adding more than 1K characters to an
"expansible
string" in any one appendPQExpBuffer() call. pg_dump tries
to use that
routine to format function definitions, which can easily be over 1K.
(Very likely there are other places in pg_dump that have similar
problems, but this is the one you hit first when trying to
pg_dump the
regression DB.) That 1K limitation was OK when the module
was just used
internally in libpq, but if we're going to allow pg_dump to
use it, we
probably ought to relax the limitation.The equivalent backend code already has solved this problem, but it
solved it by using vsnprintf() which isn't available everywhere.
We have a vsnprintf() emulation in backend/port, so in theory we
could link that routine into libpq if we are on a platform that
hasn't got vsnprintf.The thing that bothers me about that is that if libpq exports a vsnprintf routine that's different from the system version, we could find ourselves changing the behavior of applications that thought they were calling the local system's vsnprintf. (The backend/port module would get linked if either snprintf() or vsnprintf() is missing --- there are machines that have only one --- and we'd effectively replace the system definition of the one that the local system did have.) That's not good.However, the alternative of hacking pg_dump so it doesn't try to
format more than 1K at a time is mighty unattractive as well.I am inclined to go ahead and insert vsnprintf into libpq.
The risk of problems seems pretty small (and it's zero on any
machine with a reasonably recent libc, since then vsnprintf
will be in libc and we won't link our version). The risk of
missing a buffer-overrun condition in pg_dump, and shipping
a pg_dump that will fail on someone's database, seems worse.Comments? Better ideas?
regards, tom lane
************
From bouncefilter Sun Jan 16 10:12:43 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA32878
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 10:11:57 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max02-025.enterprise.net
[194.72.195.145])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id PAA18535
for <pgsql-hackers@postgreSQL.org>; Sun, 16 Jan 2000 15:11:53 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id PAA09186;
Sun, 16 Jan 2000 15:10:35 GMT
Message-Id: <200001161510.PAA09186@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: pgsql-hackers@postgreSQL.org, olly@linda.lfix.co.uk
Subject: Re: [HACKERS] Problem with foreign keys and inheritance
In-Reply-To: Message from "Oliver Elphick" <olly@lfix.co.uk> of "Thu,
13 Jan 2000 22:14:39 GMT." <200001132214.WAA24994@linda.lfix.co.uk>
References: <200001132214.WAA24994@linda.lfix.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 16 Jan 2000 15:10:34 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
"Oliver Elphick" wrote:
[Version: CVS as of yesterday]
When I create a table that inherits from another table that uses foreign
keys, I get something like this:ERROR: cache lookup of attribute 10 in relation 124171 failed
This is happening in get_attribute_name() of backend/utils/adt/ruleutils.c
Here is an SQL script that makes this happen:
========================================================
create database newj with encoding = 'SQL_ASCII';
\connect newj
create table person
(
id char(10) primary key,
name text not null,
address int,
salutation text default 'Dear Sir',
envelope text,
email text,
www text
);
create table individual
(
gender char(1) check (gender = 'M' or gender = 'F'
or gender is null),
born datetime check ((born >= '1 Jan 1880'
and born <= 'today') or born is null),
surname text,
forenames text,
title text,
old_surname text,
mobile text,
ni_no text,
constraint is_named check (not (surname isnull and forenames isnull))
)
inherits (person);
create table organisation
(
contact char(10) references individual (id) match full,
structure char(1) check (structure='L' or structure='C'
or structure='U' or structure='O')
)
inherits (person);
create table customer
(
acs_code char(8),
acs_addr int, class char(1) default '',
type char(2),
area char(2),
country char(2),
vat_class char(1),
vat_number char(12),
discount numeric(6,3) check (discount >= -50.0::numeric(6,3)
and discount <= 50.0)::numeric(6,3),
commission bool default 'f',
status char(1) default '',
deliver_to int,
factor_code text
)
inherits (organisation);
========================================================
Table customer does not get created; instead, I get:
ERROR: cache lookup of attribute 10 in relation <some_oid> failed
--
From bouncefilter Sun Jan 16 10:33:43 2000
Received: from munn.com (kmunn.munn.com [209.123.248.252])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA39193
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 10:33:39 -0500 (EST) (envelope-from kmunn@munn.com)
Received: from localhost (kmunn@localhost)
by munn.com (8.9.1/8.9.1) with ESMTP id KAA00824;
Sun, 16 Jan 2000 10:30:27 -0500
Date: Sun, 16 Jan 2000 10:30:27 -0500 (EST)
From: Kristofer Munn <kmunn@munn.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] SELECT...FOR UPDATE OF class_name
In-Reply-To: <19952.948010166@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.04.10001161027160.711-100000@munn.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Tom Lane wrote:
ERROR: FOR UPDATE: relation tbl2 not found in FROM clause
I believe the error message is correct; you should have written
select 1 from tbl2 t2, tbl1 t1 where t1.id1 = t2.id1 and
t2.id1 = 7 for update of t2;A lot of people do not realize that writing an alias for a table
in FROM means that as far as all the rest of that query is concerned,
that alias *is* the name of the table.[ additional comments and self-join example clipped ]
Ok, that sounds like a fine rule except for non-self-joins:
mail=> select 1 from tbl2 t2, tbl1 t1 where tbl1.id1 = t2.id1 and t2.id1 = 7 ;
^^^^^^^ ^^^^
Does not give any error. I had expected that behavior to be consistent
which is why I ran into the error. However, I have no problem with that
explanation.
- K
Kristofer Munn * KMI * 973-509-9414 * AIM KrMunn * http://www.munn.com/
From bouncefilter Sun Jan 16 10:45:45 2000
Received: from marvin.muc.de (marvin.muc.de [193.149.48.2])
by hub.org (8.9.3/8.9.3) with SMTP id KAA40808
for <hackers@postgresql.org>; Sun, 16 Jan 2000 10:44:58 -0500 (EST)
(envelope-from
moderators-muc-lists-postgres-hackers-owner@moderators.muc.de)
Received: (qmail 59672 invoked by alias); 16 Jan 2000 15:44:17 -0000
Delivered-To: moderators-muc-lists-postgres-hackers@moderators.muc.de
Received: (qmail 59667 invoked from network); 16 Jan 2000 15:44:16 -0000
Received: from mailout00.sul.t-online.de (194.25.134.16)
by marvin.muc.de with SMTP; 16 Jan 2000 15:44:16 -0000
Received: from imh00.btx.dtag.de by mailout00.sul.t-online.de with smtp
id 129rrC-0008Ke-00; Sun, 16 Jan 2000 16:44:46 +0100
Received: from news08.btx.dtag.de by imh00.btx.dtag.de
with esmtp id 129rrC-0002Rk-00; Sun, 16 Jan 2000 16:44:46 +0100
Received: from news by news08.btx.dtag.de
with local id 129rrB-0004CF-00; Sun, 16 Jan 2000 16:44:45 +0100
To: muc-lists-postgres-hackers@moderators.muc.de
Path: news.btx.dtag.de!not-for-mail
From: "Adrian Pach" <AdrianP@gmx.de>
Newsgroups: muc.lists.postgres.hackers
Subject: Credit Card ???????????
Date: Sun, 16 Jan 2000 16:36:52 +0100
Organization: T-Online
Lines: 9
Message-ID: <85sp1c$fo5$1@news08.btx.dtag.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news08.btx.dtag.de 948037484 16133 320079960000-0001 000116 15:44:44
X-Complaints-To: abuse@t-online.de
X-Sender: 320079960000-0001@t-dialin.net
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
I have some quistions! Who can tell me what can i do with a Credit-Card?
What is savety to do?
Where can i get some Informations about writeing Cards with some Programms
and where can i get the Programms?
Adrian-P@firemail.de
From bouncefilter Sun Jan 16 11:44:45 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA80085
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 11:44:33 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA20478;
Sun, 16 Jan 2000 11:44:24 -0500 (EST)
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump not in very good shape
In-reply-to: <1BF7C7482189D211B03F00805F8527F748C448@S-NATH-EXCH2>
References: <1BF7C7482189D211B03F00805F8527F748C448@S-NATH-EXCH2>
Comments: In-reply-to "Ansley, Michael" <Michael.Ansley@intec.co.za>
message dated "Sun, 16 Jan 2000 13:52:37 +0200"
Date: Sun, 16 Jan 2000 11:44:24 -0500
Message-ID: <20475.948041064@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
Tom, I went through all the places in pg_dump where a format string was used
to add a string to the buffer (I believe it's only a problem when using
snprintf, which, I think, is only used if you pass a format string), and
either removed the format string by passing in a single variable at a time,
or making sure that only things like db object names (which have a size
limit significantly less than 1kB) were passed in using a format
string.
Yes, this is pretty much what the alternative is if we don't want to
rely on vsnprintf(). However, if you submitted changes along that line,
they haven't been applied yet.
Of course, maybe I missed some places, but it shouldn't be a real
problem.
Well, that's what the risk is. Not only might you have missed an
obscure case or two (which Murphy's Law says we won't notice till
after release); but everyone who touches pg_dump from here on out
risks getting burnt by this non-obvious limit.
And a pg_dump that cores trying to dump someone's database is *not*
a "minor" problem.
So I'm leaning towards leaving the pg_dump code as-is and fixing the
limitation in pqexpbuffer.
regards, tom lane
From bouncefilter Sun Jan 16 12:02:44 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA87878
for <pgsql-hackers@postgresql.org>;
Sun, 16 Jan 2000 12:01:57 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA20598;
Sun, 16 Jan 2000 12:01:54 -0500 (EST)
To: Kristofer Munn <kmunn@munn.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] SELECT...FOR UPDATE OF class_name
In-reply-to: <Pine.LNX.4.04.10001161027160.711-100000@munn.com>
References: <Pine.LNX.4.04.10001161027160.711-100000@munn.com>
Comments: In-reply-to Kristofer Munn <kmunn@munn.com>
message dated "Sun, 16 Jan 2000 10:30:27 -0500"
Date: Sun, 16 Jan 2000 12:01:54 -0500
Message-ID: <20595.948042114@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Kristofer Munn <kmunn@munn.com> writes:
select 1 from tbl2 t2, tbl1 t1 where tbl1.id1 = t2.id1 and t2.id1 = 7 ;
^^^^^^^ ^^^^
Does not give any error.
What that's doing is giving you a *three way* join --- Postgres silently
adds an implicit FROM clause for the unaliased tbl1, as if you'd written
FROM tbl2 t2, tbl1 t1, tbl1
This behavior has confused a lot of people; moreover it's not SQL
standard (I think it's a leftover from Berkeley's old POSTQUEL
language). There's been a good deal of talk about removing it,
or at least giving a NOTICE when an implicit FROM clause is added.
FOR UPDATE seems to be set up to not allow implicit FROM clause
addition, which is probably a good thing --- it wouldn't make much
sense to say FOR UPDATE on a table not appearing anywhere else in
the query...
regards, tom lane
From bouncefilter Sun Jan 16 12:07:58 2000
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 MAA88329
for <hackers@postgresql.org>; Sun, 16 Jan 2000 12:07:42 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62998 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S339992AbQAPRHB>;
Sun, 16 Jan 2000 18:07:01 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129tFk-0003bH-00
for hackers@postgresql.org; Sun, 16 Jan 2000 18:14:12 +0100
Date: Sun, 16 Jan 2000 18:14:12 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: Re: psql variables fixed (?)
In-Reply-To: <Pine.LNX.4.21.0001140011200.1917-100000@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0001152315070.386-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Silly me. The correct behaviour is of course
=> \set foo 3
=> select arr.a[2: :foo];
=> \set bar timestamp
=> select 'now':: :bar;
That way typecasts should bear no compatibility problems.
On 2000-01-14, I mentioned:
I resolved the issue psql variables vs array syntax in the manner
suggested by various people. If the variable is undefined the string will
be untouched. Now something else I'd like to get your comment on is that I
handled the cast operator '::' in the same way, namely so that=> select 'now'::datetime
will resolve to
=> select 'now':<value of variable "datetime" if defined>The reason is that otherwise a construct like this
=> \set foo 3
=> select arr.a[2::foo];
or even
=> \set foo 'int4'
=> select x:::foo from y;
won't be possible without introducing an extra syntax trick. And it makes
it consistent throughout.(Btw., was somebody mentioning that this cast syntax is non-standard and
that he wanted to move toward a standard one? Just wondering.)However, psql defines some variables by itself, for example the one
containing the last oid. I set up the rule that those variables are always
all upper-case. If something still fails you can always call \unset VAR to
unset it before a query. The list of these variables is in the docs.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sun Jan 16 12:12:45 2000
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 MAA89104
for <hackers@postgresql.org>; Sun, 16 Jan 2000 12:12:03 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62333 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S305167AbQAPRLV>;
Sun, 16 Jan 2000 18:11:21 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129tJv-0003fT-00; Sun, 16 Jan 2000 18:18:31 +0100
Date: Sun, 16 Jan 2000 18:18:31 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Stephen Birch <sbirch@ironmountainsystems.com>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] TODO list
In-Reply-To: <388102EE.71E5FDF2@ironmountainsystems.com>
Message-ID: <Pine.LNX.4.21.0001161817560.1636-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
I'm working on that, but pssst, don't tell anyone! ;)
On 2000-01-15, Stephen Birch mentioned:
Can we ALTER a table to drop a column yet, or is that still a TO DO item?
Steve
Peter Eisentraut wrote:
* User who can create databases can modify pg_database table
Not anymore.
* Interlock to prevent DROP DATABASE on a database with running backends
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sun Jan 16 13:11:46 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA05048
for <pgsql-hackers@postgresql.org>;
Sun, 16 Jan 2000 13:11:07 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA21034;
Sun, 16 Jan 2000 13:10:42 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Problem with foreign keys and inheritance
In-reply-to: <200001161510.PAA09186@linda.lfix.co.uk>
References: <200001132214.WAA24994@linda.lfix.co.uk>
<200001161510.PAA09186@linda.lfix.co.uk>
Comments: In-reply-to "Oliver Elphick" <olly@lfix.co.uk>
message dated "Sun, 16 Jan 2000 15:10:34 +0000"
Date: Sun, 16 Jan 2000 13:10:41 -0500
Message-ID: <21031.948046241@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Oliver Elphick" <olly@lfix.co.uk> writes:
[Version: CVS as of yesterday]
When I create a table that inherits from another table that uses foreign
keys, I get something like this:ERROR: cache lookup of attribute 10 in relation 124171 failed
Ah, I see it. It's got nothing to do with foreign keys, just inherited
constraints. We're trying to deparse the inherited constraint
expressions at a time that the relation-in-process-of-being-created
isn't yet officially visible. So trying to look up its attributes is
failing. Need another CommandCounterIncrement() in there to make it
work.
This must have been busted for a good while, I think. I rewrote that
module months ago and probably broke it then. Probably should add
a regress test case that uses inherited constraints...
regards, tom lane
From bouncefilter Sun Jan 16 15:15:47 2000
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 PAA30057
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 15:15:01 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <CZZ0L0M9>; Sun, 16 Jan 2000 22:11:42 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C44B@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Tom Lane '" <tgl@sss.pgh.pa.us>
Cc: "'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] pg_dump not in very good shape
Date: Sun, 16 Jan 2000 22:07:37 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
And a pg_dump that cores trying to dump someone's database is *not*
a "minor" problem.
No, I didn't mean minor when it happens, I meant minor to fix. Sorry. Of
course it's serious for the user.
So I'm leaning towards leaving the pg_dump code as-is and fixing the
limitation in pqexpbuffer.
Yes, this is the correct solution. What's the best way? To check the
incoming string lengths for anything aproaching or greater than 1kB and
slice it up from there?
MikeA
From bouncefilter Mon Jan 17 00:45:12 2000
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 AAA68211
for <pgsql-hackers@postgresql.org>;
Mon, 17 Jan 2000 00:44:00 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64617 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S335902AbQAPUE5>;
Sun, 16 Jan 2000 21:04:57 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129w1p-00059S-00; Sun, 16 Jan 2000 21:12:01 +0100
Date: Sun, 16 Jan 2000 21:12:01 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_dump not in very good shape
In-Reply-To: <17930.947996172@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001161828190.1636-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-15, Tom Lane mentioned:
I am inclined to go ahead and insert vsnprintf into libpq.
The risk of problems seems pretty small (and it's zero on any
machine with a reasonably recent libc, since then vsnprintf
will be in libc and we won't link our version). The risk of
missing a buffer-overrun condition in pg_dump, and shipping
a pg_dump that will fail on someone's database, seems worse.Comments? Better ideas?
I think including this in libpq is the wrong way to go. It's not meant for
external clients. If you open this can of worms then anything psql or
pg_dump feel like using that day becomes part of the library interface.
We'd be stuck with supporting this forever.
A better idea would be to do what psql does with snprintf: Just include
the [v]snprintf.o file in the compilation (linking) conditionally. (Of
course a better plan might even be consolidating all the backend/port and
utils stuff into one unified port directory that everyone in the source
tree can use, but that's probably too much bother right now.)
One thing that I hope I can tackle for 7.1 is cleaning up the build
process (with automake?) and that would take care of missing functions
automatically by substituting a replacement contained in the distribution,
as I suggested above.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 17 00:44:54 2000
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 AAA68214
for <pgsql-hackers@postgresql.org>;
Mon, 17 Jan 2000 00:44:02 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64778 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S339998AbQAPUFI>;
Sun, 16 Jan 2000 21:05:08 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129w28-00059W-00; Sun, 16 Jan 2000 21:12:20 +0100
Date: Sun, 16 Jan 2000 21:12:20 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_dump not in very good shape
In-Reply-To: <17930.947996172@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001161848440.1636-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-15, Tom Lane mentioned:
I have repaired the most recently introduced coredump in pg_dump,
but it still crashes on the regression test database.
Which brings up the idea why the regression tests don't test pg_dump. It's
just as important to people as the backend. psql already gets tested more
or less. Would it not be a decent idea to do a
pg_dump regress > out
diff out expected.out
at the end of the tests? That way we could catch these problems
earlier. (Especially since I'm not sure how many people use pg_dump at all
during development.)
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 17 00:45:22 2000
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 AAA68216
for <hackers@postgresql.org>; Mon, 17 Jan 2000 00:44:03 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61458 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S366622AbQAPUFw>;
Sun, 16 Jan 2000 21:05:52 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 129w2p-00059n-00; Sun, 16 Jan 2000 21:13:03 +0100
Date: Sun, 16 Jan 2000 21:13:03 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, hackers@postgresql.org
Subject: Re: [HACKERS] flex
In-Reply-To: <200001160235.VAA26882@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0001162035480.1636-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
I've made the necessary changes to release_prep, makefiles, and
documentation (not sure how the INSTALL file proper is made from the sgml
docs, though). lextest is removed. configure now gives a friendly warning
if it finds flex 2.5.3.
(In fact it seems like some lex files were already generated for
distribution, but now it's all of them.)
On 2000-01-15, Bruce Momjian mentioned:
Added to TODO list.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Maybe this has been discussed before my time, but why exactly is it that
we don't distribute lex'ed files, as with yacc'ed files?Not sure. Are they more platform-dependent or lexer-dependent? Doesn't
the lexer call a lexer-specific library? Not sure.flex has a lexer-specific library (libfl.a), but as far as I can tell
our scanners don't call it. In fact our build process has no provision
for adding -lfl to the link, which I used to think was an oversight, but
now it's starting to seem like a good idea. We could ship scan.c et al
in the same way we handle the yacc/bison output files, and it should
work everywhere.
This puzzles me a bit still, but it seems to work. GNU suggests putting
yacc and lex files in distributions, so I can't imagine why they would do
that if you need to have lib[f]l.a anyway.
$ nm /usr/lib/libfl.a
libmain.o:
00000000 t gcc2_compiled.
00000000 T main
U yylex
libyywrap.o:
00000000 t gcc2_compiled.
00000000 T yywrap
If we were going to do this, I'd vote for making sure that *all* the
yacc files are pregenerated (currently, we only take care of the larger
ones), and then most people wouldn't need either flex or bison to build.regards, tom lane
************
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sun Jan 16 15:17:46 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA30204
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 15:16:59 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id PAA24395;
Sun, 16 Jan 2000 15:16:52 -0500 (EST)
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
cc: "'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] pg_dump not in very good shape
In-reply-to: <1BF7C7482189D211B03F00805F8527F748C44B@S-NATH-EXCH2>
References: <1BF7C7482189D211B03F00805F8527F748C44B@S-NATH-EXCH2>
Comments: In-reply-to "Ansley, Michael" <Michael.Ansley@intec.co.za>
message dated "Sun, 16 Jan 2000 22:07:37 +0200"
Date: Sun, 16 Jan 2000 15:16:52 -0500
Message-ID: <24392.948053812@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
So I'm leaning towards leaving the pg_dump code as-is and fixing the
limitation in pqexpbuffer.
Yes, this is the correct solution. What's the best way? To check the
incoming string lengths for anything aproaching or greater than 1kB and
slice it up from there?
I don't think we can do that short of writing a complete snprintf
emulation --- so we might as well just use snprintf.
regards, tom lane
From bouncefilter Sun Jan 16 15:34:49 2000
Received: from corvette.mascari.com (dhcp26142035.columbus.rr.com
[24.26.142.35]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA35380
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 15:34:02 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id PAA08685;
Sun, 16 Jan 2000 15:31:08 -0500
Message-ID: <38822A5D.670DBA2F@mascari.com>
Date: Sun, 16 Jan 2000 15:30:21 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] pg_dump not in very good shape
References: <1BF7C7482189D211B03F00805F8527F748C44B@S-NATH-EXCH2>
<24392.948053812@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
So I'm leaning towards leaving the pg_dump code as-is and fixing the
limitation in pqexpbuffer.Yes, this is the correct solution. What's the best way? To check the
incoming string lengths for anything aproaching or greater than 1kB and
slice it up from there?I don't think we can do that short of writing a complete snprintf
emulation --- so we might as well just use snprintf.regards, tom lane
Can I go ahead and use today's snapshot to write up the diffs for
pg_dump for dumping COMMENT ON statements?
Mike Mascari
From bouncefilter Sun Jan 16 15:48:49 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA37166
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 15:48:32 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id PAA24571;
Sun, 16 Jan 2000 15:47:11 -0500 (EST)
To: Mike Mascari <mascarm@mascari.com>
cc: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] pg_dump not in very good shape
In-reply-to: <38822A5D.670DBA2F@mascari.com>
References: <1BF7C7482189D211B03F00805F8527F748C44B@S-NATH-EXCH2>
<24392.948053812@sss.pgh.pa.us> <38822A5D.670DBA2F@mascari.com>
Comments: In-reply-to Mike Mascari <mascarm@mascari.com>
message dated "Sun, 16 Jan 2000 15:30:21 -0500"
Date: Sun, 16 Jan 2000 15:47:11 -0500
Message-ID: <24568.948055631@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Mike Mascari <mascarm@mascari.com> writes:
Can I go ahead and use today's snapshot to write up the diffs for
pg_dump for dumping COMMENT ON statements?
Sure --- just don't test it with any long comments ;-)
regards, tom lane
From bouncefilter Sun Jan 16 16:33:49 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA48568
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 16:32:59 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id QAA24794;
Sun, 16 Jan 2000 16:32:39 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] I think we need an explicit parsetree node for CAST
In-reply-to: <200001160644.BAA09781@candle.pha.pa.us>
References: <200001160644.BAA09781@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sun, 16 Jan 2000 01:44:37 -0500"
Date: Sun, 16 Jan 2000 16:32:38 -0500
Message-ID: <24791.948058358@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Right, you saw the parser_typecast mistake. But the problem of doing
it properly for non-constant input to the CAST is still open.
BTW, the strings regress test is currently failing in a couple of
places, because it thinks that casting to "char" won't truncate the
string. With this patch in place, casting a constant to "char" means
casting to char(1) which indeed truncates to one character. I think
this is correct behavior, though it may surprise someone somewhere.
There are other places in the strings test that cast non-constant
expressions to "char", and those are going to change behavior as soon
as I finish inventing a parsenode for CAST. So I am not going to bother
checking in an update for the strings test until the dust settles.
Yes, and constants with cases in SELECT INTO are broken too.
Huh? I'm not sure if I follow this or not --- would you give an
example?
regards, tom lane
From bouncefilter Sun Jan 16 17:05:48 2000
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 RAA55183
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 17:05:45 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA00798;
Sun, 16 Jan 2000 17:04:44 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001162204.RAA00798@candle.pha.pa.us>
Subject: Re: [HACKERS] I think we need an explicit parsetree node for CAST
In-Reply-To: <24791.948058358@sss.pgh.pa.us> from Tom Lane at "Jan 16,
2000 04:32:38 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 16 Jan 2000 17:04:44 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Yes, and constants with cases in SELECT INTO are broken too.
Huh? I'm not sure if I follow this or not --- would you give an
example?
Here is the mail I sent out last night. It shows a failure:
---------------------------------------------------------------------------
I see your issue, and I don't know the code well enough to comment on
it.
I was able to do:
test=> select 'x' as fred into test ;
NOTICE: Attribute 'fred' has an unknown type
Relation created; continue
SELECT
test=> \d test
Table "test"
Attribute | Type | Extra
-----------+---------+-------
fred | unknown |
---------------------------------------------------------------------------
test=> select 'x'::varchar as fred into test ;
SELECT
test=> \d test
Table "test"
Attribute | Type | Extra
-----------+------------+-------
fred | varchar(0) |
Seems we should disallow this. This last one is the one you want to
fix:
---------------------------------------------------------------------------
test=> select 'x'::varchar(20) as fred into test ;
SELECT
test=> \d test
Table "test"
Attribute | Type | Extra
-----------+------------+-------
fred | varchar(0) |
-
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 16 18:44:51 2000
Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA76476
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 18:44:27 -0500 (EST) (envelope-from xun@cs.ucsb.edu)
Received: from cs.ucsb.edu (tao [128.111.47.30])
by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id PAA01190
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 15:44:26 -0800 (PST)
Message-Id: <200001162344.PAA01190@hercules.cs.ucsb.edu>
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] hybrid hash, cont. of development suggestion needed
In-reply-to: Your message of "Sun, 16 Jan 2000 02:09:32 +0200."
<38810C3C.F15758B3@tm.ee>
Date: Sun, 16 Jan 2000 15:44:22 -0800
From: Xun Cheng <xun@cs.ucsb.edu>
First I want to thank you for all help I got to my
earlier posting.
Right. The hash join uses batching if it estimates that the relation
is too large to fit in memory; is that what you call "hybrid"?I've heard the word "hybrid" being used of a scheme where you hash each
key of a multi-key index separately and then concatenate the hashes for
the index. That way you can use the index for accessing also subsets of
keys by examining only the buxkets with matching hash sections.
In research, there are traditionally three kinds of hash joins:
simple hash, grace hash and hybrid hash. Hybrid is generally considered
to be having a better performance since it is designed to combine
the best behavior of simple hash and grace hash.
It has two phases. In the first the relations are read, hashed into
buckets, and written out, as in grace hash. However, during this phase
a portion of the memory is reserved for an in-memory hash bucket for R (
R is joining with S and R is smaller). This bucket of R will never
be written to disk.
xun
From bouncefilter Sun Jan 16 18:39:50 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA75801;
Sun, 16 Jan 2000 18:39:15 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id QAA16277;
Sun, 16 Jan 2000 16:00:45 -0800 (PST)
Date: Sun, 16 Jan 2000 16:00:45 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org,
pgsql-patches@postgreSQL.org, Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: docs done Re: [HACKERS] LIBPQ patches ...
Message-ID: <20000116160043.I508@fw.wintelcom.net>
References: <Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
<Pine.BSF.4.21.0001081715180.18498-100000@thelab.hub.org>
<3.0.1.32.20000109070102.0101d7b0@mail.pacifier.com>
<10004.947433028@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <10004.947433028@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Sun, Jan 09, 2000 at 10:50:28AM -0500
* Tom Lane <tgl@sss.pgh.pa.us> [000109 08:18] wrote:
Don Baccus <dhogaza@pacifier.com> writes:
At 05:27 PM 1/8/00 -0500, Tom Lane wrote:
I also object strongly to the lack of documentation.
... I know there are some folks who aren't native-english speakers, so
perhaps you don't want to require that the implementor of such patches
provide the final documentation wording. But the information should
be there and spelled out in a form that can be very easily moved to
the docs.Oh, absolutely. Thomas, our master of the docs, has always had the
policy of "give me some words, I'll take care of formatting and
editing..."I was probably too harsh on Alfred last night, since in fact his code
was fairly well commented, and some minimal doco could have been
extracted from the routine headers. But on a change like this, I think
some paragraphs of coherent high-level explanation are needed: what it
does, when and why you'd use it. I didn't see that anywhere...
Here's the revised patch, it includes sgml docs and changes to
ensure that old style connections behave the way they are expected
to:
Index: doc/src/sgml/libpq.sgml
===================================================================
RCS file: /home/pgcvs/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.25
diff -u -c -r1.25 libpq.sgml
*** doc/src/sgml/libpq.sgml 2000/01/14 05:33:13 1.25
--- doc/src/sgml/libpq.sgml 2000/01/17 03:40:30
***************
*** 377,382 ****
--- 377,386 ----
changed in the future.
</para>
<para>
+ These functions leave the socket in a non-blocking state as if
+ <function>PQsetnonblocking</function> had been called.
+ </para>
+ <para>
These functions are not thread-safe.
</para>
</listitem>
***************
*** 1168,1175 ****
--- 1172,1229 ----
Applications that do not like these limitations can instead use the
underlying functions that <function>PQexec</function> is built from:
<function>PQsendQuery</function> and <function>PQgetResult</function>.
+ </para>
+ <para>
+ Older programs that used this functionality as well as
+ <function>PQputline</function> and <function>PQputnbytes</function>
+ could block waiting to send data to the backend, to
+ address that issue, the function <function>PQsetnonblocking</function>
+ was added.
+ </para>
+ <para>
+ Old applications can neglect to use <function>PQsetnonblocking</function>
+ and get the older potentially blocking behavior. Newer programs can use
+ <function>PQsetnonblocking</function> to achieve a completely non-blocking
+ connection to the backend. <itemizedlist>
+ <listitem>
+ <para>
+ <function>PQsetnonblocking</function> Sets the state of the connection
+ to non-blocking.
+ <synopsis>
+ int PQsetnonblocking(PGconn *conn)
+ </synopsis>
+ this function will ensure that calls to
+ <function>PQputline</function>, <function>PQputnbytes</function>,
+ <function>PQsendQuery</function> and <function>PQendcopy</function>
+ will not block but instead return an error if they need to be called
+ again.
+ </para>
+ <para>
+ When a database connection has been set to non-blocking mode and
+ <function>PQexec</function> is called, it will temporarily set the state
+ of the connection to blocking until the <function>PQexec</function>
+ completes.
+ </para>
+ <para>
+ More of libpq is expected to be made safe for
+ <function>PQsetnonblocking</function> functionality in the near future.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <function>PQisnonblocking</function>
+ Returns the blocking status of the database connection.
+ <synopsis>
+ int PQisnonblocking(const PGconn *conn)
+ </synopsis>
+ Returns TRUE if the connection is set to non-blocking mode,
+ FALSE if blocking.
+ </para>
+ </listitem>
+
<listitem>
<para>
<function>PQsendQuery</function>
***************
*** 1267,1286 **** <listitem>
<para>
<function>PQsocket</function>
Obtain the file descriptor number for the backend connection socket.
! A valid descriptor will be >= 0; a result of -1 indicates that
no backend connection is currently open.
<synopsis>
int PQsocket(const PGconn *conn);
</synopsis>
<function>PQsocket</function> should be used to obtain the backend socket descriptor
in preparation for executing <function>select</function>(2). This allows an
! application to wait for either backend responses or other conditions.
If the result of <function>select</function>(2) indicates that data can be read from
the backend socket, then <function>PQconsumeInput</function> should be called to read the
data; after which, <function>PQisBusy</function>, <function>PQgetResult</function>,
and/or <function>PQnotifies</function> can be used to process the response.
</para>
</listitem>
--- 1321,1363 ---- <listitem>
<para>
+ <function>PQflush</function> Attempt to flush any data queued to the backend,
+ returns 0 if successful (or if the send queue is empty) or EOF if it failed for
+ some reason.
+ <synopsis>
+ int PQflush(PGconn *conn);
+ </synopsis>
+ <function>PQflush</function> needs to be called on a non-blocking connection
+ before calling <function>select</function> to determine if a responce has
+ arrived. If 0 is returned it ensures that there is no data queued to the
+ backend that has not actually been sent. Only applications that have used
+ <function>PQsetnonblocking</function> have a need for this.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<function>PQsocket</function>
Obtain the file descriptor number for the backend connection socket.
! A valid descriptor will be >= 0; a result of -1 indicates that
no backend connection is currently open.
<synopsis>
int PQsocket(const PGconn *conn);
</synopsis>
<function>PQsocket</function> should be used to obtain the backend socket descriptor
in preparation for executing <function>select</function>(2). This allows an
! application using a blocking connection to wait for either backend responses or
! other conditions.
If the result of <function>select</function>(2) indicates that data can be read from
the backend socket, then <function>PQconsumeInput</function> should be called to read the
data; after which, <function>PQisBusy</function>, <function>PQgetResult</function>,
and/or <function>PQnotifies</function> can be used to process the response.
+ </para>
+ <para>
+ Non-blocking connections (that have used <function>PQsetnonblocking</function>)
+ should not use <function>select</function> until <function>PQflush</function>
+ has returned 0 indicating that there is no buffered data waiting to be sent
+ to the backend.
</para>
</listitem>Index: src/interfaces/libpq/fe-connect.c
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.111
diff -u -c -r1.111 fe-connect.c
*** src/interfaces/libpq/fe-connect.c 2000/01/16 21:18:52 1.111
--- src/interfaces/libpq/fe-connect.c 2000/01/17 02:35:56
***************
*** 594,624 ****
return 0;
}-
- /* ----------
- * connectMakeNonblocking -
- * Make a connection non-blocking.
- * Returns 1 if successful, 0 if not.
- * ----------
- */
- static int
- connectMakeNonblocking(PGconn *conn)
- {
- #ifndef WIN32
- if (fcntl(conn->sock, F_SETFL, O_NONBLOCK) < 0)
- #else
- if (ioctlsocket(conn->sock, FIONBIO, &on) != 0)
- #endif
- {
- printfPQExpBuffer(&conn->errorMessage,
- "connectMakeNonblocking -- fcntl() failed: errno=%d\n%s\n",
- errno, strerror(errno));
- return 0;
- }
-
- return 1;
- }
-
/* ----------
* connectNoDelay -
* Sets the TCP_NODELAY socket option.
--- 594,599 ----
***************
*** 789,795 ****
* Ewan Mellor <eem21@cam.ac.uk>.
* ---------- */
#if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL)
! if (!connectMakeNonblocking(conn))
goto connect_errReturn;
#endif --- 764,770 ----
* Ewan Mellor <eem21@cam.ac.uk>.
* ---------- */
#if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL)
! if (PQsetnonblocking(conn, TRUE) != 0)
goto connect_errReturn;
#endif ***************
*** 898,904 ****
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (!connectMakeNonblocking(conn))
goto connect_errReturn;
#endif
--- 873,879 ----
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (PQsetnonblocking(conn, TRUE) != 0)
goto connect_errReturn;
#endif ***************
*** 1720,1725 ****
--- 1695,1701 ----
conn->inBuffer = (char *) malloc(conn->inBufSize);
conn->outBufSize = 8 * 1024;
conn->outBuffer = (char *) malloc(conn->outBufSize);
+ conn->nonblocking = FALSE;
initPQExpBuffer(&conn->errorMessage);
initPQExpBuffer(&conn->workBuffer);
if (conn->inBuffer == NULL ||
***************
*** 1830,1835 ****
--- 1806,1812 ----
conn->lobjfuncs = NULL;
conn->inStart = conn->inCursor = conn->inEnd = 0;
conn->outCount = 0;
+ conn->nonblocking = FALSE;}
Index: src/interfaces/libpq/fe-exec.c
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-exec.c,v
retrieving revision 1.86
diff -u -c -r1.86 fe-exec.c
*** src/interfaces/libpq/fe-exec.c 1999/11/11 00:10:14 1.86
--- src/interfaces/libpq/fe-exec.c 2000/01/14 22:47:07
***************
*** 13,18 ****
--- 13,19 ----
*/
#include <errno.h>
#include <ctype.h>
+ #include <fcntl.h> #include "postgres.h"
#include "libpq-fe.h"
***************
*** 24,30 ****
#include <unistd.h>
#endif
-
/* keep this in same order as ExecStatusType in libpq-fe.h */
const char *const pgresStatus[] = {
"PGRES_EMPTY_QUERY",
--- 25,30 ----
***************
*** 514,526 ****
conn->curTuple = NULL; /* send the query to the backend; */
! /* the frontend-backend protocol uses 'Q' to designate queries */
! if (pqPutnchar("Q", 1, conn) ||
! pqPuts(query, conn) ||
! pqFlush(conn))
{
! handleSendFailure(conn);
! return 0;
}
/* OK, it's launched! */
--- 514,566 ----
conn->curTuple = NULL; /* send the query to the backend; */
!
! /*
! * in order to guarantee that we don't send a partial query
! * where we would become out of sync with the backend and/or
! * block during a non-blocking connection we must first flush
! * the send buffer before sending more data
! *
! * an alternative is to implement 'queue reservations' where
! * we are able to roll up a transaction
! * (the 'Q' along with our query) and make sure we have
! * enough space for it all in the send buffer.
! */
! if (pqIsnonblocking(conn))
{
! /*
! * the buffer must have emptied completely before we allow
! * a new query to be buffered
! */
! if (pqFlush(conn))
! return 0;
! /* 'Q' == queries */
! /* XXX: if we fail here we really ought to not block */
! if (pqPutnchar("Q", 1, conn) ||
! pqPuts(query, conn))
! {
! handleSendFailure(conn);
! return 0;
! }
! /*
! * give the data a push, ignore the return value as
! * ConsumeInput() will do any aditional flushing if needed
! */
! (void) pqFlush(conn);
! }
! else
! {
! /*
! * the frontend-backend protocol uses 'Q' to
! * designate queries
! */
! if (pqPutnchar("Q", 1, conn) ||
! pqPuts(query, conn) ||
! pqFlush(conn))
! {
! handleSendFailure(conn);
! return 0;
! }
}
/* OK, it's launched! */
***************
*** 574,580 ****
--- 614,630 ----
* we will NOT block waiting for more input.
*/
if (pqReadData(conn) < 0)
+ {
+ /*
+ * for non-blocking connections
+ * try to flush the send-queue otherwise we may never get a
+ * responce for something that may not have already been sent
+ * because it's in our write buffer!
+ */
+ if (pqIsnonblocking(conn))
+ (void) pqFlush(conn);
return 0;
+ }
/* Parsing of the data waits till later. */
return 1;
}
***************
*** 1088,1093 ****
--- 1138,1153 ----
{
PGresult *result;
PGresult *lastResult;
+ bool savedblocking;
+
+ /*
+ * we assume anyone calling PQexec wants blocking behaviour,
+ * we force the blocking status of the connection to blocking
+ * for the duration of this function and restore it on return
+ */
+ savedblocking = pqIsnonblocking(conn);
+ if (PQsetnonblocking(conn, FALSE) == -1)
+ return NULL; /*
* Silently discard any prior query result that application didn't
***************
*** 1102,1115 ****
PQclear(result);
printfPQExpBuffer(&conn->errorMessage,
"PQexec: you gotta get out of a COPY state yourself.\n");
! return NULL;
}
PQclear(result);
}
/* OK to send the message */
if (!PQsendQuery(conn, query))
! return NULL;
/*
* For backwards compatibility, return the last result if there are
--- 1162,1176 ----
PQclear(result);
printfPQExpBuffer(&conn->errorMessage,
"PQexec: you gotta get out of a COPY state yourself.\n");
! /* restore blocking status */
! goto errout;
}
PQclear(result);
} /* OK to send the message */
if (!PQsendQuery(conn, query))
! goto errout; /* restore blocking status */
/*
* For backwards compatibility, return the last result if there are
***************
*** 1142,1148 ****
--- 1203,1217 ----
result->resultStatus == PGRES_COPY_OUT)
break;
}
+
+ if (PQsetnonblocking(conn, savedblocking) == -1)
+ return NULL;
return lastResult;
+
+ errout:
+ if (PQsetnonblocking(conn, savedblocking) == -1)
+ return NULL;
+ return NULL;
}***************
*** 1431,1438 ****
"PQendcopy() -- I don't think there's a copy in progress.\n");
return 1;
}
! (void) pqFlush(conn); /* make sure no data is waiting to be sent */
/* Return to active duty */
conn->asyncStatus = PGASYNC_BUSY;
--- 1500,1516 ----
"PQendcopy() -- I don't think there's a copy in progress.\n");
return 1;
}
+
+ /*
+ * make sure no data is waiting to be sent,
+ * abort if we are non-blocking and the flush fails
+ */
+ if (pqFlush(conn) && pqIsnonblocking(conn))
+ return (1);! /* non blocking connections may have to abort at this point. */
! if (pqIsnonblocking(conn) && PQisBusy(conn))
! return (1);
/* Return to active duty */
conn->asyncStatus = PGASYNC_BUSY;
***************
*** 2025,2028 ****
--- 2103,2192 ----
return 1;
else
return 0;
+ }
+
+ /* PQsetnonblocking:
+ sets the PGconn's database connection non-blocking if the arg is TRUE
+ or makes it non-blocking if the arg is FALSE, this will not protect
+ you from PQexec(), you'll only be safe when using the non-blocking
+ API
+ Needs to be called only on a connected database connection.
+ */
+
+ int
+ PQsetnonblocking(PGconn *conn, int arg)
+ {
+ int fcntlarg;
+
+ arg = (arg == TRUE) ? 1 : 0;
+ /* early out if the socket is already in the state requested */
+ if (arg == conn->nonblocking)
+ return (0);
+
+ /*
+ * to guarantee constancy for flushing/query/result-polling behavior
+ * we need to flush the send queue at this point in order to guarantee
+ * proper behavior.
+ * this is ok because either they are making a transition
+ * _from_ or _to_ blocking mode, either way we can block them.
+ */
+ /* if we are going from blocking to non-blocking flush here */
+ if (!pqIsnonblocking(conn) && pqFlush(conn))
+ return (-1);
+
+
+ #ifdef USE_SSL
+ if (conn->ssl)
+ {
+ printfPQExpBuffer(&conn->errorMessage,
+ "PQsetnonblocking() -- not supported when using SSL\n");
+ return (-1);
+ }
+ #endif /* USE_SSL */
+
+ #ifndef WIN32
+ fcntlarg = fcntl(conn->sock, F_GETFL, 0);
+ if (fcntlarg == -1)
+ return (-1);
+
+ if ((arg == TRUE &&
+ fcntl(conn->sock, F_SETFL, fcntlarg | O_NONBLOCK) == -1) ||
+ (arg == FALSE &&
+ fcntl(conn->sock, F_SETFL, fcntlarg & ~O_NONBLOCK) == -1))
+ #else
+ fcntlarg = arg;
+ if (ioctlsocket(conn->sock, FIONBIO, &fcntlarg) != 0)
+ #endif
+ {
+ printfPQExpBuffer(&conn->errorMessage,
+ "PQsetblocking() -- unable to set nonblocking status to %s\n",
+ arg == TRUE ? "TRUE" : "FALSE");
+ return (-1);
+ }
+
+ conn->nonblocking = arg;
+
+ /* if we are going from non-blocking to blocking flush here */
+ if (pqIsnonblocking(conn) && pqFlush(conn))
+ return (-1);
+
+ return (0);
+ }
+
+ /* return the blocking status of the database connection, TRUE == nonblocking,
+ FALSE == blocking
+ */
+ int
+ PQisnonblocking(const PGconn *conn)
+ {
+
+ return (pqIsnonblocking(conn));
+ }
+
+ /* try to force data out, really only useful for non-blocking users */
+ int
+ PQflush(PGconn *conn)
+ {
+
+ return (pqFlush(conn));
}
Index: src/interfaces/libpq/fe-misc.c
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-misc.c,v
retrieving revision 1.33
diff -u -c -r1.33 fe-misc.c
*** src/interfaces/libpq/fe-misc.c 1999/11/30 03:08:19 1.33
--- src/interfaces/libpq/fe-misc.c 2000/01/12 03:12:14
***************
*** 86,91 ****
--- 86,122 ----
{
size_t avail = Max(conn->outBufSize - conn->outCount, 0);+ /*
+ * if we are non-blocking and the send queue is too full to buffer this
+ * request then try to flush some and return an error
+ */
+ if (pqIsnonblocking(conn) && nbytes > avail && pqFlush(conn))
+ {
+ /*
+ * even if the flush failed we may still have written some
+ * data, recalculate the size of the send-queue relative
+ * to the amount we have to send, we may be able to queue it
+ * afterall even though it's not sent to the database it's
+ * ok, any routines that check the data coming from the
+ * database better call pqFlush() anyway.
+ */
+ if (nbytes > Max(conn->outBufSize - conn->outCount, 0))
+ {
+ printfPQExpBuffer(&conn->errorMessage,
+ "pqPutBytes -- pqFlush couldn't flush enough"
+ " data: space available: %d, space needed %d\n",
+ Max(conn->outBufSize - conn->outCount, 0), nbytes);
+ return EOF;
+ }
+ }
+
+ /*
+ * is the amount of data to be sent is larger than the size of the
+ * output buffer then we must flush it to make more room.
+ *
+ * the code above will make sure the loop conditional is never
+ * true for non-blocking connections
+ */
while (nbytes > avail)
{
memcpy(conn->outBuffer + conn->outCount, s, avail);
***************
*** 548,553 ****
--- 579,592 ----
return EOF;
}+ /*
+ * don't try to send zero data, allows us to use this function
+ * without too much worry about overhead
+ */
+ if (len == 0)
+ return (0);
+
+ /* while there's still data to send */
while (len > 0)
{
/* Prevent being SIGPIPEd if backend has closed the connection. */
***************
*** 556,561 ****
--- 595,601 ----
#endif int sent;
+
#ifdef USE_SSL
if (conn->ssl)
sent = SSL_write(conn->ssl, ptr, len);
***************
*** 585,590 ****
--- 625,632 ----
case EWOULDBLOCK:
break;
#endif
+ case EINTR:
+ continue; case EPIPE:
#ifdef ECONNRESET
***************
*** 616,628 ****
ptr += sent;
len -= sent;
}
if (len > 0)
{
/* We didn't send it all, wait till we can send more */
- /* At first glance this looks as though it should block. I think
- * that it will be OK though, as long as the socket is
- * non-blocking. */
if (pqWait(FALSE, TRUE, conn))
return EOF;
}
--- 658,688 ----
ptr += sent;
len -= sent;
}
+
if (len > 0)
{
/* We didn't send it all, wait till we can send more */
+
+ /*
+ * if the socket is in non-blocking mode we may need
+ * to abort here
+ */
+ #ifdef USE_SSL
+ /* can't do anything for our SSL users yet */
+ if (conn->ssl == NULL)
+ {
+ #endif
+ if (pqIsnonblocking(conn))
+ {
+ /* shift the contents of the buffer */
+ memmove(conn->outBuffer, ptr, len);
+ conn->outCount = len;
+ return EOF;
+ }
+ #ifdef USE_SSL
+ }
+ #endif if (pqWait(FALSE, TRUE, conn))
return EOF;
}
Index: src/interfaces/libpq/libpq-fe.h
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-fe.h,v
retrieving revision 1.55
diff -u -c -r1.55 libpq-fe.h
*** src/interfaces/libpq/libpq-fe.h 2000/01/15 05:37:21 1.55
--- src/interfaces/libpq/libpq-fe.h 2000/01/17 02:35:56
***************
*** 263,268 ****
--- 263,275 ----
extern int PQputnbytes(PGconn *conn, const char *buffer, int nbytes);
extern int PQendcopy(PGconn *conn);+ /* Set blocking/nonblocking connection to the backend */
+ extern int PQsetnonblocking(PGconn *conn, int arg);
+ extern int PQisnonblocking(const PGconn *conn);
+
+ /* Force the write buffer to be written (or at least try) */
+ extern int PQflush(PGconn *conn);
+
/*
* "Fast path" interface --- not really recommended for application
* use
Index: src/interfaces/libpq/libpq-int.h
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-int.h,v
retrieving revision 1.16
diff -u -c -r1.16 libpq-int.h
*** src/interfaces/libpq/libpq-int.h 2000/01/15 05:37:21 1.16
--- src/interfaces/libpq/libpq-int.h 2000/01/17 02:35:56
***************
*** 214,219 ****
--- 214,222 ----
int inEnd; /* offset to first position after avail
* data */+ int nonblocking; /* whether this connection is using a blocking
+ * socket to the backend or not */
+
/* Buffer for data not yet sent to backend */
char *outBuffer; /* currently allocated buffer */
int outBufSize; /* allocated size of buffer */
***************
*** 299,303 ****
--- 302,312 ----
#define strerror(A) (sys_errlist[(A)])
#endif /* sunos4 */
#endif /* !strerror */
+
+ /*
+ * this is so that we can check is a connection is non-blocking internally
+ * without the overhead of a function call
+ */
+ #define pqIsnonblocking(conn) (conn->nonblocking)#endif /* LIBPQ_INT_H */
From bouncefilter Sun Jan 16 21:00:50 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA08252
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 21:00:37 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA06452;
Sun, 16 Jan 2000 21:00:32 -0500 (EST)
To: Xun Cheng <xun@cs.ucsb.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] hybrid hash, cont. of development suggestion needed
In-reply-to: <200001162344.PAA01190@hercules.cs.ucsb.edu>
References: <200001162344.PAA01190@hercules.cs.ucsb.edu>
Comments: In-reply-to Xun Cheng <xun@cs.ucsb.edu>
message dated "Sun, 16 Jan 2000 15:44:22 -0800"
Date: Sun, 16 Jan 2000 21:00:32 -0500
Message-ID: <6449.948074432@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Xun Cheng <xun@cs.ucsb.edu> writes:
In research, there are traditionally three kinds of hash joins:
simple hash, grace hash and hybrid hash. Hybrid is generally considered
to be having a better performance since it is designed to combine
the best behavior of simple hash and grace hash.
It has two phases. In the first the relations are read, hashed into
buckets, and written out, as in grace hash. However, during this phase
a portion of the memory is reserved for an in-memory hash bucket for R (
R is joining with S and R is smaller). This bucket of R will never
be written to disk.
Yes, that's how nodeHash.c does it...
regards, tom lane
From bouncefilter Sun Jan 16 21:46:51 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA18423
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 21:46:28 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA03708;
Sun, 16 Jan 2000 21:45:01 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001170245.VAA03708@candle.pha.pa.us>
Subject: Inhterit fix
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 16 Jan 2000 21:45:01 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tom, does your inherit pass constraints fix apply to anything on the
TODO list, like:
* Unique index on base column not honored on inserts from inherited table
INSERT INTO inherit_table (unique_index_col) VALUES (dup) should fail
[inherit]
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 17 01:49:53 2000
Received: from smtp.kdt.de (ns2.kdt.de [195.8.224.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA85249
for <hackers@postgresql.org>; Mon, 17 Jan 2000 01:49:40 -0500 (EST)
(envelope-from christof.petig@wtal.de)
Received: from gateway.petig.de (line0366lf.kdt.de [195.8.240.116])
by smtp.kdt.de (8.8.8/8.8.8) with ESMTP id HAA01143
for <hackers@postgresql.org>; Mon, 17 Jan 2000 07:49:38 +0100
Received: from wtal.de (christof@[192.168.230.9])
by gateway (8.8.8/8.8.8) with ESMTP id HAA10094
for <hackers@postgresql.org>; Mon, 17 Jan 2000 07:47:36 +0100
Sender: christof@to.wtal.de
Message-ID: <3882844E.B6777D3C@wtal.de>
Date: Mon, 17 Jan 2000 03:54:07 +0100
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: hackers@postgresql.org
Subject: external data sources (e.g. a second RDBMS)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear hackers,
I have to port a lot of programs to PostgreSQL and don't want to wait
for completing them all before I put the first into production.
So after some thought I came to an enthrilling vision
If PostgreSQL had an interface for transparently accessing external
data, I could leave the needed tables on the old RDBMS and write a
wrapper which would provide access to the data on the old RDBMS. Both
old and new (pgsql) programs would see the same data. And I could start
using postgres' fine tools (e.g. psql) _now_ for all of my work.
Putting these short sighted things aside it would provide an opportunity
for
- distributed databases
- load balancing via putting a table on multiple servers, creating a
unioning-view
- you could use SQL to access other data sources (e.g. LDAP)
- one step further to world domination (no matter where your data
resides, you could use postgres for your queries)
- accessing multiple databases in _one_ SQL statement (e.g. join)
So I ask for your opinion on this strange idea.
I suggest marking a table as external uses an interface which should
provide the following methods
- query the structure of the table (\d table-name)
- sequentially scan the table (returning selected attributes of each
tuple) [with some conditions]
- update/delete either by cursor or by where-condition
- query for statistics (see below)
Since this functionality would require modifications all over the place
in postgres I would like to start discussion about it. I might overlook
something but the thought of having such a thing around opens up a lot
of opportunities.
Perhaps an ODBC wrapper could be the correct point to start (after
implementing and testing the [additional] virtual table access layer)
Christof
PS: I'd never dare to depend on this functionality, some kind of
mirroring program might cover the problem for me as well, but it looked
so cool.
PPS: Of course I would start to investigate it further _after_ TOAST is
finished.
------------------- example ------------------------------------
[a is an external table, b an internal table]
select tuple_a1,tuple_b1 from a,b where a.tuple_a2=b.tuple_b2 and
tuple_a3=42
would cause
-> sequential scan (tuple_a1,tuple_a2) on a where tuple_a3=42
-> for each entry index scan on b for a.tuple_a2=b.tuple_b2
-> report result
or
-> sequential scan (tuple_b2, tuple_b1) on b
-> index_scan (tuple_a1) by (tuple_a3=42,tuple_a2=b.tuple_b2)
-> report result
clearly we need to collect statistics on external tables as well
From bouncefilter Sun Jan 16 22:02:51 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA22792
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 22:02:13 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA07313;
Sun, 16 Jan 2000 22:02:00 -0500 (EST)
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump not in very good shape
In-reply-to: <20475.948041064@sss.pgh.pa.us>
References: <1BF7C7482189D211B03F00805F8527F748C448@S-NATH-EXCH2>
<20475.948041064@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
message dated "Sun, 16 Jan 2000 11:44:24 -0500"
Date: Sun, 16 Jan 2000 22:02:00 -0500
Message-ID: <7310.948078120@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I wrote:
So I'm leaning towards leaving the pg_dump code as-is and fixing the
limitation in pqexpbuffer.
This is done. pg_dump dumps the regression database again.
regards, tom lane
From bouncefilter Sun Jan 16 22:23:51 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA26463
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 22:23:10 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA07491;
Sun, 16 Jan 2000 22:23:03 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: Inhterit fix
In-reply-to: <200001170245.VAA03708@candle.pha.pa.us>
References: <200001170245.VAA03708@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sun, 16 Jan 2000 21:45:01 -0500"
Date: Sun, 16 Jan 2000 22:23:03 -0500
Message-ID: <7488.948079383@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Tom, does your inherit pass constraints fix apply to anything on the
TODO list, like:
* Unique index on base column not honored on inserts from inherited table
INSERT INTO inherit_table (unique_index_col) VALUES (dup) should fail
[inherit]
No; that was a fix for something that did work in 6.5, but I had
unknowingly broken it :-(.
I guess what the above TODO item is complaining about is that indexes
on a parent table are not duplicated for the child table. That should
happen, I suppose, but it'll take an all-new chunk of code.
regards, tom lane
From bouncefilter Sun Jan 16 22:47:52 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA31943
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 22:47:02 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA07607;
Sun, 16 Jan 2000 22:46:34 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: "Hiroshi Inoue" <Inoue@tpf.co.jp>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Getting rid of setheapoverride (was Re: [COMMITTERS] heap.c)
In-reply-to: <200001170321.WAA04813@candle.pha.pa.us>
References: <200001170321.WAA04813@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sun, 16 Jan 2000 22:21:46 -0500"
Date: Sun, 16 Jan 2000 22:46:34 -0500
Message-ID: <7604.948080794@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Tom, any chance we can change the name of setheapoverried to something
that makes sense?Actually, I thought the plan was to eliminate it entirely in favor of
using CommandCounterIncrement when we need to make tuples visible.
There was a thread about that back in September, but I guess no one's
gotten around to actually doing it.
I remember in the old days being totally confused about its purpose.
That was my motivation to change it. Can I do something to help fix
this?
Actually, according to my notes I had put off doing anything with this
because Hiroshi pointed out that CommandCounterIncrement had a shared-
cache-invalidation problem (it sent SI messages for changes that we
couldn't yet be sure would get committed).
Hiroshi's message last Monday stated that he'd fixed that problem,
so maybe now it's safe to start using CommandCounterIncrement more
heavily. Hiroshi, what do you think --- do you trust
CommandCounterIncrement now?
regards, tom lane
From bouncefilter Sun Jan 16 23:16:52 2000
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 XAA40431
for <pgsql-hackers@postgreSQL.org>;
Sun, 16 Jan 2000 23:16:17 -0500 (EST) (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 NAA01699; Mon, 17 Jan 2000 13:15:01 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: Getting rid of setheapoverride (was Re: [COMMITTERS] heap.c)
Date: Mon, 17 Jan 2000 13:20:37 +0900
Message-ID: <001801bf60a2$34b1cfe0$2801007e@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
In-Reply-To: <7604.948080794@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]Bruce Momjian <pgman@candle.pha.pa.us> writes:
Tom, any chance we can change the name of setheapoverried to
something
that makes sense?
Actually, I thought the plan was to eliminate it entirely in favor of
using CommandCounterIncrement when we need to make tuples visible.
There was a thread about that back in September, but I guess no one's
gotten around to actually doing it.I remember in the old days being totally confused about its purpose.
That was my motivation to change it. Can I do something to help fix
this?Actually, according to my notes I had put off doing anything with this
because Hiroshi pointed out that CommandCounterIncrement had a shared-
cache-invalidation problem (it sent SI messages for changes that we
couldn't yet be sure would get committed).Hiroshi's message last Monday stated that he'd fixed that problem,
so maybe now it's safe to start using CommandCounterIncrement more
heavily. Hiroshi, what do you think --- do you trust
CommandCounterIncrement now?
Oh,I was just looking at heapoverride stuff quite accidentally.
Yes, this call is ugly and should be replaced by CommandCounterIncrement().
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Sun Jan 16 23:40:52 2000
Received: from munn.com (kmunn.munn.com [209.123.248.252])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA49749
for <pgsql-hackers@postgresql.org>;
Sun, 16 Jan 2000 23:40:47 -0500 (EST) (envelope-from kmunn@munn.com)
Received: from localhost (kmunn@localhost)
by munn.com (8.9.1/8.9.1) with ESMTP id XAA12735
for <pgsql-hackers@postgresql.org>; Sun, 16 Jan 2000 23:40:45 -0500
Date: Sun, 16 Jan 2000 23:40:44 -0500 (EST)
From: Kristofer Munn <kmunn@munn.com>
To: pgsql-hackers@postgresql.org
Subject: Temp Table Memory Leak
Message-ID: <Pine.LNX.4.04.10001160208180.27063-200000@munn.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
BOUNDARY="2077359352-1121507908-948084044=:12243"
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.
--2077359352-1121507908-948084044=:12243
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi again...
I've discovered (or perhaps re-discovered) what seems to be a memory leak
involving temp tables. It's so bad that I make a script (which runs as a
daemon) close the backend connection and reconnect each time it runs the
offending command sequences. Without the reset I've seen the backend grow
to over 100 megs in size in a matter of a couple of minutes.
I've created a sample case that reproduces the error that I will attach
with this message. Basically, I create a 50 column temp table (with no
rows in it) and then run updates on each column in succession. The
backend gets large pretty quick - I'm seeing about 12Megs after running
the enclosed script which does an update on all 50 columns 3 times (150
updates).
Thanks...
- K
Kristofer Munn * KMI * 973-509-9414 * AIM KrMunn * http://www.munn.com/
--2077359352-1121507908-948084044=:12243
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="memleak.sql"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.04.10001162340440.12243@munn.com>
Content-Description: Memory Leak Script
Content-Disposition: attachment; filename="memleak.sql"
Y3JlYXRlIHRlbXAgdGFibGUgdGJsMSAoDQoJZjAxIHZhcmNoYXIoMjUpLA0K
CWYwMiB2YXJjaGFyKDI1KSwNCglmMDMgdmFyY2hhcigyNSksDQoJZjA0IHZh
cmNoYXIoMjUpLA0KCWYwNSB2YXJjaGFyKDI1KSwNCglmMDYgdmFyY2hhcigy
NSksDQoJZjA3IHZhcmNoYXIoMjUpLA0KCWYwOCB2YXJjaGFyKDI1KSwNCglm
MDkgdmFyY2hhcigyNSksDQoJZjEwIHZhcmNoYXIoMjUpLA0KCWYxMSB2YXJj
aGFyKDI1KSwNCglmMTIgdmFyY2hhcigyNSksDQoJZjEzIHZhcmNoYXIoMjUp
LA0KCWYxNCB2YXJjaGFyKDI1KSwNCglmMTUgdmFyY2hhcigyNSksDQoJZjE2
IHZhcmNoYXIoMjUpLA0KCWYxNyB2YXJjaGFyKDI1KSwNCglmMTggdmFyY2hh
cigyNSksDQoJZjE5IHZhcmNoYXIoMjUpLA0KCWYyMCB2YXJjaGFyKDI1KSwN
CglmMjEgdmFyY2hhcigyNSksDQoJZjIyIHZhcmNoYXIoMjUpLA0KCWYyMyB2
YXJjaGFyKDI1KSwNCglmMjQgdmFyY2hhcigyNSksDQoJZjI1IHZhcmNoYXIo
MjUpLA0KCWYyNiB2YXJjaGFyKDI1KSwNCglmMjcgdmFyY2hhcigyNSksDQoJ
ZjI4IHZhcmNoYXIoMjUpLA0KCWYyOSB2YXJjaGFyKDI1KSwNCglmMzAgdmFy
Y2hhcigyNSksDQoJZjMxIHZhcmNoYXIoMjUpLA0KCWYzMiB2YXJjaGFyKDI1
KSwNCglmMzMgdmFyY2hhcigyNSksDQoJZjM0IHZhcmNoYXIoMjUpLA0KCWYz
NSB2YXJjaGFyKDI1KSwNCglmMzYgdmFyY2hhcigyNSksDQoJZjM3IHZhcmNo
YXIoMjUpLA0KCWYzOCB2YXJjaGFyKDI1KSwNCglmMzkgdmFyY2hhcigyNSks
DQoJZjQwIHZhcmNoYXIoMjUpLA0KCWY0MSB2YXJjaGFyKDI1KSwNCglmNDIg
dmFyY2hhcigyNSksDQoJZjQzIHZhcmNoYXIoMjUpLA0KCWY0NCB2YXJjaGFy
KDI1KSwNCglmNDUgdmFyY2hhcigyNSksDQoJZjQ2IHZhcmNoYXIoMjUpLA0K
CWY0NyB2YXJjaGFyKDI1KSwNCglmNDggdmFyY2hhcigyNSksDQoJZjQ5IHZh
cmNoYXIoMjUpLA0KCWY1MCB2YXJjaGFyKDI1KQ0KKTsNCg0KdXBkYXRlIHRi
bDEgc2V0IGYwMSA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMDIgPSAnTic7
DQp1cGRhdGUgdGJsMSBzZXQgZjAzID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0
IGYwNCA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMDUgPSAnTic7DQp1cGRh
dGUgdGJsMSBzZXQgZjA2ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYwNyA9
ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMDggPSAnTic7DQp1cGRhdGUgdGJs
MSBzZXQgZjA5ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYxMCA9ICdOJzsN
CnVwZGF0ZSB0YmwxIHNldCBmMTEgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQg
ZjEyID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYxMyA9ICdOJzsNCnVwZGF0
ZSB0YmwxIHNldCBmMTQgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjE1ID0g
J04nOw0KdXBkYXRlIHRibDEgc2V0IGYxNiA9ICdOJzsNCnVwZGF0ZSB0Ymwx
IHNldCBmMTcgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjE4ID0gJ04nOw0K
dXBkYXRlIHRibDEgc2V0IGYxOSA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBm
MjAgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjIxID0gJ04nOw0KdXBkYXRl
IHRibDEgc2V0IGYyMiA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMjMgPSAn
Tic7DQp1cGRhdGUgdGJsMSBzZXQgZjI0ID0gJ04nOw0KdXBkYXRlIHRibDEg
c2V0IGYyNSA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMjYgPSAnTic7DQp1
cGRhdGUgdGJsMSBzZXQgZjI3ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYy
OCA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMjkgPSAnTic7DQp1cGRhdGUg
dGJsMSBzZXQgZjMwID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYzMSA9ICdO
JzsNCnVwZGF0ZSB0YmwxIHNldCBmMzIgPSAnTic7DQp1cGRhdGUgdGJsMSBz
ZXQgZjMzID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYzNCA9ICdOJzsNCnVw
ZGF0ZSB0YmwxIHNldCBmMzUgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjM2
ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYzNyA9ICdOJzsNCnVwZGF0ZSB0
YmwxIHNldCBmMzggPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjM5ID0gJ04n
Ow0KdXBkYXRlIHRibDEgc2V0IGY0MCA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNl
dCBmNDEgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjQyID0gJ04nOw0KdXBk
YXRlIHRibDEgc2V0IGY0MyA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmNDQg
PSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjQ1ID0gJ04nOw0KdXBkYXRlIHRi
bDEgc2V0IGY0NiA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmNDcgPSAnTic7
DQp1cGRhdGUgdGJsMSBzZXQgZjQ4ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0
IGY0OSA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmNTAgPSAnTic7DQp1cGRh
dGUgdGJsMSBzZXQgZjAxID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYwMiA9
ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMDMgPSAnTic7DQp1cGRhdGUgdGJs
MSBzZXQgZjA0ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYwNSA9ICdOJzsN
CnVwZGF0ZSB0YmwxIHNldCBmMDYgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQg
ZjA3ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYwOCA9ICdOJzsNCnVwZGF0
ZSB0YmwxIHNldCBmMDkgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjEwID0g
J04nOw0KdXBkYXRlIHRibDEgc2V0IGYxMSA9ICdOJzsNCnVwZGF0ZSB0Ymwx
IHNldCBmMTIgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjEzID0gJ04nOw0K
dXBkYXRlIHRibDEgc2V0IGYxNCA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBm
MTUgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjE2ID0gJ04nOw0KdXBkYXRl
IHRibDEgc2V0IGYxNyA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMTggPSAn
Tic7DQp1cGRhdGUgdGJsMSBzZXQgZjE5ID0gJ04nOw0KdXBkYXRlIHRibDEg
c2V0IGYyMCA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMjEgPSAnTic7DQp1
cGRhdGUgdGJsMSBzZXQgZjIyID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYy
MyA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMjQgPSAnTic7DQp1cGRhdGUg
dGJsMSBzZXQgZjI1ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYyNiA9ICdO
JzsNCnVwZGF0ZSB0YmwxIHNldCBmMjcgPSAnTic7DQp1cGRhdGUgdGJsMSBz
ZXQgZjI4ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYyOSA9ICdOJzsNCnVw
ZGF0ZSB0YmwxIHNldCBmMzAgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjMx
ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYzMiA9ICdOJzsNCnVwZGF0ZSB0
YmwxIHNldCBmMzMgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjM0ID0gJ04n
Ow0KdXBkYXRlIHRibDEgc2V0IGYzNSA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNl
dCBmMzYgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjM3ID0gJ04nOw0KdXBk
YXRlIHRibDEgc2V0IGYzOCA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMzkg
PSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjQwID0gJ04nOw0KdXBkYXRlIHRi
bDEgc2V0IGY0MSA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmNDIgPSAnTic7
DQp1cGRhdGUgdGJsMSBzZXQgZjQzID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0
IGY0NCA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmNDUgPSAnTic7DQp1cGRh
dGUgdGJsMSBzZXQgZjQ2ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGY0NyA9
ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmNDggPSAnTic7DQp1cGRhdGUgdGJs
MSBzZXQgZjQ5ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGY1MCA9ICdOJzsN
CnVwZGF0ZSB0YmwxIHNldCBmMDEgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQg
ZjAyID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYwMyA9ICdOJzsNCnVwZGF0
ZSB0YmwxIHNldCBmMDQgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjA1ID0g
J04nOw0KdXBkYXRlIHRibDEgc2V0IGYwNiA9ICdOJzsNCnVwZGF0ZSB0Ymwx
IHNldCBmMDcgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjA4ID0gJ04nOw0K
dXBkYXRlIHRibDEgc2V0IGYwOSA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBm
MTAgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjExID0gJ04nOw0KdXBkYXRl
IHRibDEgc2V0IGYxMiA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMTMgPSAn
Tic7DQp1cGRhdGUgdGJsMSBzZXQgZjE0ID0gJ04nOw0KdXBkYXRlIHRibDEg
c2V0IGYxNSA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMTYgPSAnTic7DQp1
cGRhdGUgdGJsMSBzZXQgZjE3ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYx
OCA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMTkgPSAnTic7DQp1cGRhdGUg
dGJsMSBzZXQgZjIwID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYyMSA9ICdO
JzsNCnVwZGF0ZSB0YmwxIHNldCBmMjIgPSAnTic7DQp1cGRhdGUgdGJsMSBz
ZXQgZjIzID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYyNCA9ICdOJzsNCnVw
ZGF0ZSB0YmwxIHNldCBmMjUgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjI2
ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGYyNyA9ICdOJzsNCnVwZGF0ZSB0
YmwxIHNldCBmMjggPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjI5ID0gJ04n
Ow0KdXBkYXRlIHRibDEgc2V0IGYzMCA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNl
dCBmMzEgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjMyID0gJ04nOw0KdXBk
YXRlIHRibDEgc2V0IGYzMyA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMzQg
PSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjM1ID0gJ04nOw0KdXBkYXRlIHRi
bDEgc2V0IGYzNiA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmMzcgPSAnTic7
DQp1cGRhdGUgdGJsMSBzZXQgZjM4ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0
IGYzOSA9ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmNDAgPSAnTic7DQp1cGRh
dGUgdGJsMSBzZXQgZjQxID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGY0MiA9
ICdOJzsNCnVwZGF0ZSB0YmwxIHNldCBmNDMgPSAnTic7DQp1cGRhdGUgdGJs
MSBzZXQgZjQ0ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGY0NSA9ICdOJzsN
CnVwZGF0ZSB0YmwxIHNldCBmNDYgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQg
ZjQ3ID0gJ04nOw0KdXBkYXRlIHRibDEgc2V0IGY0OCA9ICdOJzsNCnVwZGF0
ZSB0YmwxIHNldCBmNDkgPSAnTic7DQp1cGRhdGUgdGJsMSBzZXQgZjUwID0g
J04nOw0KDQpkcm9wIHRhYmxlIHRibDEgOw0K
--2077359352-1121507908-948084044=:12243--
From bouncefilter Mon Jan 17 00:01:55 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA53317
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 00:01:51 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA15006;
Mon, 17 Jan 2000 00:01:27 -0500 (EST)
To: Kristofer Munn <kmunn@munn.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Temp Table Memory Leak
In-reply-to: <Pine.LNX.4.04.10001160208180.27063-200000@munn.com>
References: <Pine.LNX.4.04.10001160208180.27063-200000@munn.com>
Comments: In-reply-to Kristofer Munn <kmunn@munn.com>
message dated "Sun, 16 Jan 2000 23:40:44 -0500"
Date: Mon, 17 Jan 2000 00:01:27 -0500
Message-ID: <15003.948085287@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Kristofer Munn <kmunn@munn.com> writes:
I've created a sample case that reproduces the error that I will attach
with this message. Basically, I create a 50 column temp table (with no
rows in it) and then run updates on each column in succession. The
backend gets large pretty quick - I'm seeing about 12Megs after running
the enclosed script which does an update on all 50 columns 3 times (150
updates).
I confirm the leak in 6.5.* --- but I see no leak in current sources.
regards, tom lane
From bouncefilter Mon Jan 17 00:45:10 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA68277
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 00:44:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: from candle.pha.pa.us (s5-03.ppp.op.net [209.152.195.67])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id AAA28919
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 00:31:26 -0500 (EST)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA11977;
Mon, 17 Jan 2000 00:04:39 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001170504.AAA11977@candle.pha.pa.us>
Subject: Re: [HACKERS] Temp Table Memory Leak
In-Reply-To: <Pine.LNX.4.04.10001160208180.27063-200000@munn.com> from
Kristofer Munn at "Jan 16, 2000 11:40:44 pm"
To: Kristofer Munn <kmunn@munn.com>
Date: Mon, 17 Jan 2000 00:04:39 -0500 (EST)
CC: pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hi again...
I've discovered (or perhaps re-discovered) what seems to be a memory leak
involving temp tables. It's so bad that I make a script (which runs as a
daemon) close the backend connection and reconnect each time it runs the
offending command sequences. Without the reset I've seen the backend grow
to over 100 megs in size in a matter of a couple of minutes.I've created a sample case that reproduces the error that I will attach
with this message. Basically, I create a 50 column temp table (with no
rows in it) and then run updates on each column in succession. The
backend gets large pretty quick - I'm seeing about 12Megs after running
the enclosed script which does an update on all 50 columns 3 times (150
updates).
Is this with 6.5.* or 7.0. If it is 6.5.*, can you try it with our
current tree for testing purposes. I think you will find it is fixed.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 17 00:06:52 2000
Received: from munn.com (kmunn.munn.com [209.123.248.252])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA56308
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 00:06:44 -0500 (EST) (envelope-from kmunn@munn.com)
Received: from localhost (kmunn@localhost)
by munn.com (8.9.1/8.9.1) with ESMTP id AAA13033
for <pgsql-hackers@postgreSQL.org>; Mon, 17 Jan 2000 00:06:42 -0500
Date: Mon, 17 Jan 2000 00:06:42 -0500 (EST)
From: Kristofer Munn <kmunn@munn.com>
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Temp Table Memory Leak
In-Reply-To: <15003.948085287@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.04.10001170005080.12243-100000@munn.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 17 Jan 2000, Tom Lane wrote:
I confirm the leak in 6.5.* --- but I see no leak in current sources.
Good news for 7.0 but... if anyone has a patch I could (safely) apply to
6.5.3 for this problem, it would be much appreciated.
- K
Kristofer Munn * KMI * 973-509-9414 * AIM KrMunn * http://www.munn.com/
From bouncefilter Mon Jan 17 00:45:01 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA68271
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 00:44:35 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: from candle.pha.pa.us (s5-03.ppp.op.net [209.152.195.67])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id AAA29251
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 00:32:46 -0500 (EST)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA12602;
Mon, 17 Jan 2000 00:32:27 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001170532.AAA12602@candle.pha.pa.us>
Subject: Re: [HACKERS] Temp Table Memory Leak
In-Reply-To: <15003.948085287@sss.pgh.pa.us> from Tom Lane at "Jan 17,
2000 00:01:27 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 17 Jan 2000 00:32:27 -0500 (EST)
CC: Kristofer Munn <kmunn@munn.com>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Kristofer Munn <kmunn@munn.com> writes:
I've created a sample case that reproduces the error that I will attach
with this message. Basically, I create a 50 column temp table (with no
rows in it) and then run updates on each column in succession. The
backend gets large pretty quick - I'm seeing about 12Megs after running
the enclosed script which does an update on all 50 columns 3 times (150
updates).I confirm the leak in 6.5.* --- but I see no leak in current sources.
Great. Now the big question is should we backpatch, and if so do we
want a 6.5.4. I know you(Tom) have put a number of patches into the
6.5.* branch, and we are at least 2 months away from our next release.
Comments?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 17 00:35:54 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA67307
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 00:35:52 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA16367;
Mon, 17 Jan 2000 00:35:33 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Bruce Momjian" <pgman@candle.pha.pa.us>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] RE: Getting rid of setheapoverride (was Re:
[COMMITTERS] heap.c)
In-reply-to: <001801bf60a2$34b1cfe0$2801007e@tpf.co.jp>
References: <001801bf60a2$34b1cfe0$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Mon, 17 Jan 2000 13:20:37 +0900"
Date: Mon, 17 Jan 2000 00:35:33 -0500
Message-ID: <16364.948087333@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
Oh,I was just looking at heapoverride stuff quite accidentally.
Yes, this call is ugly and should be replaced by CommandCounterIncrement().
OK, I'm running a build now with setheapoverride calls removed.
Will see what happens.
About half of the setheapoverride calls surrounded heap_update()
(formerly called heap_replace()) calls. AFAICS there is no need
for these calls unless heap_update itself needs them --- but there
are many calls to heap_update that do not have setheapoverride.
Perhaps heap_replace once needed setheapoverride but no longer does?
I am going to try just removing these calls without adding a
CommandCounterIncrement to replace them. If anyone knows that
this is a bad idea, let me know!
regards, tom lane
From bouncefilter Mon Jan 17 00:45:00 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA68285
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 00:44:43 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA17181;
Mon, 17 Jan 2000 00:44:33 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Kristofer Munn <kmunn@munn.com>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Temp Table Memory Leak
In-reply-to: <200001170532.AAA12602@candle.pha.pa.us>
References: <200001170532.AAA12602@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 17 Jan 2000 00:32:27 -0500"
Date: Mon, 17 Jan 2000 00:44:33 -0500
Message-ID: <17178.948087873@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I confirm the leak in 6.5.* --- but I see no leak in current sources.
Great. Now the big question is should we backpatch, and if so do we
want a 6.5.4.
Do you have a low-risk patch for this? I recall that we did some
fairly extensive changes involving not only temp tables but the regular
relation cache. Extracting a patch that could be trusted seems like
it might be tough.
I know you(Tom) have put a number of patches into the 6.5.* branch,
and we are at least 2 months away from our next release.
I have been throwing low-risk/high-reward fixes into REL6_5 when I
could, with the thought that we might want to do another 6.5.* release.
But I'm undecided on whether we should or not. It seems like we are
close enough to 7.0 beta cycle that we should focus our effort there.
regards, tom lane
From bouncefilter Mon Jan 17 01:08:53 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA75328
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 01:08:35 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id CAA09608;
Mon, 17 Jan 2000 02:07:40 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 17 Jan 2000 02:07:40 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Kristofer Munn <kmunn@munn.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Temp Table Memory Leak
In-Reply-To: <200001170532.AAA12602@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001170206370.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 17 Jan 2000, Bruce Momjian wrote:
Kristofer Munn <kmunn@munn.com> writes:
I've created a sample case that reproduces the error that I will attach
with this message. Basically, I create a 50 column temp table (with no
rows in it) and then run updates on each column in succession. The
backend gets large pretty quick - I'm seeing about 12Megs after running
the enclosed script which does an update on all 50 columns 3 times (150
updates).I confirm the leak in 6.5.* --- but I see no leak in current sources.
Great. Now the big question is should we backpatch, and if so do we
want a 6.5.4. I know you(Tom) have put a number of patches into the
6.5.* branch, and we are at least 2 months away from our next release.Comments?
I'm all for it...I think that snce ppl have been consciously making an
effort to backpatch as appropriate (aren't CVS branches great? *grin*), we
should try and provide periodic releases, as appropriate ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Jan 17 01:10:53 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA75458
for <pgsql-hackers@postgresql.org>;
Mon, 17 Jan 2000 01:10:11 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id CAA09658;
Mon, 17 Jan 2000 02:09:46 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 17 Jan 2000 02:09:46 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Kristofer Munn <kmunn@munn.com>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Temp Table Memory Leak
In-Reply-To: <17178.948087873@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001170208120.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 17 Jan 2000, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I confirm the leak in 6.5.* --- but I see no leak in current sources.
Great. Now the big question is should we backpatch, and if so do we
want a 6.5.4.Do you have a low-risk patch for this? I recall that we did some
fairly extensive changes involving not only temp tables but the regular
relation cache. Extracting a patch that could be trusted seems like
it might be tough.I know you(Tom) have put a number of patches into the 6.5.* branch,
and we are at least 2 months away from our next release.I have been throwing low-risk/high-reward fixes into REL6_5 when I
could, with the thought that we might want to do another 6.5.* release.
But I'm undecided on whether we should or not. It seems like we are
close enough to 7.0 beta cycle that we should focus our effort there.
past experience tends to be that even when we beta 7.0 on the 1st of Feb,
which I haven't heard anyone suggest changing yet, we're still talking
another month, maybe two, before release...
I think it would be nice to put out a 6.5.4 about the same time as we go
beta ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Jan 17 01:31:53 2000
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 BAA79094
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 01:31:01 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA13224;
Mon, 17 Jan 2000 01:13:39 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001170613.BAA13224@candle.pha.pa.us>
Subject: Re: [HACKERS] RE: Getting rid of setheapoverride (was Re:
[COMMITTERS]
heap.c)
In-Reply-To: <16364.948087333@sss.pgh.pa.us> from Tom Lane at "Jan 17,
2000 00:35:33 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 17 Jan 2000 01:13:39 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
Oh,I was just looking at heapoverride stuff quite accidentally.
Yes, this call is ugly and should be replaced by CommandCounterIncrement().OK, I'm running a build now with setheapoverride calls removed.
Will see what happens.About half of the setheapoverride calls surrounded heap_update()
(formerly called heap_replace()) calls. AFAICS there is no need
for these calls unless heap_update itself needs them --- but there
are many calls to heap_update that do not have setheapoverride.
Perhaps heap_replace once needed setheapoverride but no longer does?I am going to try just removing these calls without adding a
CommandCounterIncrement to replace them. If anyone knows that
this is a bad idea, let me know!
Go for it. The setheapoverride name was so confusing, people just
probably left it in, not knowing what it did.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 17 01:32:00 2000
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 BAA79528
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 01:31:50 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA13242;
Mon, 17 Jan 2000 01:15:25 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001170615.BAA13242@candle.pha.pa.us>
Subject: Re: [HACKERS] Temp Table Memory Leak
In-Reply-To: <17178.948087873@sss.pgh.pa.us> from Tom Lane at "Jan 17,
2000 00:44:33 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 17 Jan 2000 01:15:25 -0500 (EST)
CC: Kristofer Munn <kmunn@munn.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I confirm the leak in 6.5.* --- but I see no leak in current sources.
Great. Now the big question is should we backpatch, and if so do we
want a 6.5.4.Do you have a low-risk patch for this? I recall that we did some
fairly extensive changes involving not only temp tables but the regular
relation cache. Extracting a patch that could be trusted seems like
it might be tough.
I remember now. That entire code is changed to do the replacement
before getting to actual cache.
I know you(Tom) have put a number of patches into the 6.5.* branch,
and we are at least 2 months away from our next release.I have been throwing low-risk/high-reward fixes into REL6_5 when I
could, with the thought that we might want to do another 6.5.* release.
But I'm undecided on whether we should or not. It seems like we are
close enough to 7.0 beta cycle that we should focus our effort there.
Seems we can not fix this in 6.5.* without the risk of more bugs. I
agree on focusing on 7.0.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 17 01:31:55 2000
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 BAA79424
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 01:31:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA13413;
Mon, 17 Jan 2000 01:19:19 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001170619.BAA13413@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_dump not in very good shape
In-Reply-To: <Pine.LNX.4.21.0001161848440.1636-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 16, 2000 09:12:20 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 17 Jan 2000 01:19:19 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-01-15, Tom Lane mentioned:
I have repaired the most recently introduced coredump in pg_dump,
but it still crashes on the regression test database.Which brings up the idea why the regression tests don't test pg_dump. It's
just as important to people as the backend. psql already gets tested more
or less. Would it not be a decent idea to do apg_dump regress > out
diff out expected.outat the end of the tests? That way we could catch these problems
earlier. (Especially since I'm not sure how many people use pg_dump at all
during development.)
Actually the megatest is:
pg_dump regress > out
dropdb regression
createdb regression
psql regression < out
pg_dump regress > out2
diff out out2
That is the pg_dump test, and someone usually does it as part of
regression testing before each release.
It would be nice to add this to test/regress/Makefile maybe.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 17 01:29:53 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA78589
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 01:29:35 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA20032;
Mon, 17 Jan 2000 01:29:16 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump not in very good shape
In-reply-to: <Pine.LNX.4.21.0001161828190.1636-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001161828190.1636-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sun, 16 Jan 2000 21:12:01 +0100"
Date: Mon, 17 Jan 2000 01:29:16 -0500
Message-ID: <20029.948090556@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
On 2000-01-15, Tom Lane mentioned:
I am inclined to go ahead and insert vsnprintf into libpq.
I think including this in libpq is the wrong way to go. [snip]
A better idea would be to do what psql does with snprintf: Just include
the [v]snprintf.o file in the compilation (linking) conditionally.
Sorry if I was unclear, but that was exactly what I meant.
BTW, since this is now done in libpq, you could probably remove
snprintf.o from psql ...
regards, tom lane
From bouncefilter Mon Jan 17 01:38:53 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA83250
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 01:38:51 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA20079;
Mon, 17 Jan 2000 01:38:31 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump not in very good shape
In-reply-to: <Pine.LNX.4.21.0001161848440.1636-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001161848440.1636-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sun, 16 Jan 2000 21:12:20 +0100"
Date: Mon, 17 Jan 2000 01:38:31 -0500
Message-ID: <20076.948091111@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
Which brings up the idea why the regression tests don't test pg_dump.
That'd be nice ...
Would it not be a decent idea to do a
pg_dump regress > out
diff out expected.out
at the end of the tests?
There's a couple of small practical problems with that. Number one:
pg_dump regression | wc
118211 565800 3516170
Adding a 3.5meg comparison file to the distribution isn't too
appetizing; nor is the prospect of trying to keep it up to date
via cvs. (*How* much storage did you just add to hub, Marc? ;-))
Number two is that we'd never get consistent dump results across
different platforms. There are the known cross-platform variations
(float roundoff, DST handling, etc) already accounted for by
platform-specific substitute comparison files. Worse, a dump will
see the platform-dependent variations in tuple update order that we
currently mask in many tests by asking for ordered select results.
I don't think anyone will hold still for a bunch of 3.5meg
platform-specific dump comparison files.
In short, it'd be a great idea, but figuring out a practical testing
method will take some work.
regards, tom lane
From bouncefilter Mon Jan 17 01:41:53 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA83709
for <hackers@postgreSQL.org>; Mon, 17 Jan 2000 01:41:33 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA20107;
Mon, 17 Jan 2000 01:41:29 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, hackers@postgreSQL.org
Subject: Re: [HACKERS] flex
In-reply-to: <Pine.LNX.4.21.0001162035480.1636-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001162035480.1636-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sun, 16 Jan 2000 21:13:03 +0100"
Date: Mon, 17 Jan 2000 01:41:28 -0500
Message-ID: <20104.948091288@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
flex has a lexer-specific library (libfl.a), but as far as I can tell
our scanners don't call it. In fact our build process has no provision
for adding -lfl to the link, which I used to think was an oversight, but
now it's starting to seem like a good idea. We could ship scan.c et al
in the same way we handle the yacc/bison output files, and it should
work everywhere.
This puzzles me a bit still, but it seems to work.
I suppose that libfl.a is only needed to support some flex features that
we don't use --- but I haven't bothered to dig in and find out what.
Thanks for taking care of that task; it'd been hanging around on the
"good ideas to get to someday" list for quite a while.
regards, tom lane
From bouncefilter Mon Jan 17 01:57:53 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA86194
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 01:57:36 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA20159;
Mon, 17 Jan 2000 01:56:54 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump not in very good shape
In-reply-to: <200001170619.BAA13413@candle.pha.pa.us>
References: <200001170619.BAA13413@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 17 Jan 2000 01:19:19 -0500"
Date: Mon, 17 Jan 2000 01:56:54 -0500
Message-ID: <20156.948092214@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Actually the megatest is:
pg_dump regress > out
dropdb regression
createdb regression
psql regression < out
pg_dump regress > out2
diff out out2
That is the pg_dump test, and someone usually does it as part of
regression testing before each release.
It would be nice to add this to test/regress/Makefile maybe.
That's a good thought --- it eliminates both the platform-specific
issues and the problem of adding a bulky reference file to the
distribution.
I'd suggest, though, that the test *not* clobber the regression DB.
Instead
pg_dump regression >out
createdb regression2
psql regression2 <out
pg_dump regression >out2
dropdb regression2 -- maybe
diff out out2
This leaves you a better chance of investigating the diff if you
get one.
regards, tom lane
From bouncefilter Mon Jan 17 02:13:54 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA06431
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 02:13:09 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA20201;
Mon, 17 Jan 2000 02:12:48 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] RE: Getting rid of setheapoverride (was Re:
[COMMITTERS] heap.c)
In-reply-to: <200001170613.BAA13224@candle.pha.pa.us>
References: <200001170613.BAA13224@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 17 Jan 2000 01:13:39 -0500"
Date: Mon, 17 Jan 2000 02:12:48 -0500
Message-ID: <20198.948093168@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Oh,I was just looking at heapoverride stuff quite accidentally.
Yes, this call is ugly and should be replaced by CommandCounterIncrement()OK, I'm running a build now with setheapoverride calls removed.
Will see what happens.
Well, it seems to work, but...
About half of the setheapoverride calls surrounded heap_update()
(formerly called heap_replace()) calls. AFAICS there is no need
for these calls unless heap_update itself needs them --- but there
are many calls to heap_update that do not have setheapoverride.
I figured out that the cases where setheapoverride (or, now,
CommandCounterIncrement) were needed were the cases where the
heap_update might be updating a tuple created earlier in the
same command. pg_operator.c has some cases like that, but many of
the other uses of setheapoverride seem to be unnecessary.
However, I'm a little uncomfortable with committing this change,
because my first try at it worked OK at creating things but fell
right over on DROP TABLE. I had replaced the setheapoverride(true)
in heap_drop_with_catalog() (backend/catalog/heap.c) with a
CommandCounterIncrement, and it failed with this backtrace:
(gdb) bt
#0 elog (lev=-1, fmt=0x6b160 "cannot find attribute %d of relation %s")
at elog.c:112
#1 0x1767d8 in build_tupdesc_ind (buildinfo={infotype = 1, i = {
info_id = 19040,
info_name = 0x4a60}},
relation=0x4006ef00, natts=1074198864) at relcache.c:527
#2 0x176554 in RelationBuildTupleDesc (buildinfo={infotype = 1, i = {
info_id = 19040,
info_name = 0x4a60 }},
relation=0x1, natts=1074198864) at relcache.c:437
#3 0x177230 in RelationBuildDesc (buildinfo={infotype = 1, i = {
info_id = 19040,
info_name = 0x4a60 }},
oldrelation=0x4006ef00) at relcache.c:808
#4 0x177b28 in RelationClearRelation (relation=0x4006ef00, rebuildIt=0 '\000')
at relcache.c:1279
#5 0x177bbc in RelationFlushRelation (relationPtr=0xffffffff,
onlyFlushReferenceCountZero=96 '`') at relcache.c:1320
#6 0x177e10 in RelationIdInvalidateRelationCacheByRelationId (
relationId=19040) at relcache.c:1415
#7 0x175968 in CacheIdInvalidate (cacheId=4294967295, hashIndex=438624,
pointer=0x1) at inval.c:544
#8 0x175ae8 in InvalidationMessageCacheInvalidate (message=0x4007cce4)
at inval.c:657
#9 0x175490 in LocalInvalidInvalidate (invalid=0x4007cce4 "r",
function=0x4000c3ca <DINFINITY+9226>, freemember=1 '\001') at inval.c:173
#10 0x175ca4 in ImmediateLocalInvalidation (send=-1 '���') at inval.c:806
#11 0x9d0b0 in AtCommit_LocalCache () at xact.c:687
#12 0x9cf70 in CommandCounterIncrement () at xact.c:520
#13 0xa7a08 in heap_drop_with_catalog (relname=0x4006ef00 "������������")
at heap.c:1528
#14 0xb16ac in RemoveRelation (name=0x40083328 "ff1") at creatinh.c:217
#15 0x13ce84 in ProcessUtility (parsetree=0x40083370, dest=Remote)
at utility.c:201
#16 0x13add0 in pg_exec_query_dest (query_string=0x40024270 "drop table ff1",
dest=Remote, aclOverride=1 '\001') at postgres.c:721
Apparently, if I call CommandCounterIncrement while partway through
dropping a relation, it will try to rebuild the relcache entry for
the relation --- and of course fail. I'm too tired to figure out
whether this is just a small coding error in the new cache invalidation
code or whether it's a serious limitation in the whole design. Hiroshi,
what do you think?
I was able to get around this by simply removing CommandCounterIncrement
from heap_drop_with_catalog entirely --- dropping tables seems to work
fine that way ... but I don't trust it ...
regards, tom lane
From bouncefilter Mon Jan 17 02:53:54 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA14962
for <hackers@postgreSQL.org>; Mon, 17 Jan 2000 02:53:30 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id IAA14054;
Mon, 17 Jan 2000 08:02:03 GMT
Sender: lockhart@hub.org
Message-ID: <3882CC7A.25F9C11F@alumni.caltech.edu>
Date: Mon, 17 Jan 2000 08:02: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: Peter Eisentraut <peter_e@gmx.net>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO list
References: <Pine.LNX.4.21.0001151259300.386-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
* Allow array on int8[]
Done. (Credit to Thomas, thought, he just forgot to apply the patch.)
Thanks. btw, didn't forget, but wanted confirmation that it worked
(which I got a day or two later).
* Make Absolutetime/Relativetime int4 because time_t can be int8 on some
ports
Does this mean the abstime/reltime types or all of them? I thought the
former were deprecated anyway.
abstime should probably be considered deprecated as a user type, but
it is still used extensively internally and within the tuple
structure. I'd be reluctant to wholesale replace it with
timestamp/datetime, since that will take 8 bytes per value rather than
4.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 17 03:09:56 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA23372
for <hackers@postgreSQL.org>; Mon, 17 Jan 2000 03:09:05 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id DAA20308;
Mon, 17 Jan 2000 03:08:59 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO list
In-reply-to: <3882CC7A.25F9C11F@alumni.caltech.edu>
References: <Pine.LNX.4.21.0001151259300.386-100000@localhost.localdomain>
<3882CC7A.25F9C11F@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Mon, 17 Jan 2000 08:02:02 +0000"
Date: Mon, 17 Jan 2000 03:08:59 -0500
Message-ID: <20305.948096539@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Does this mean the abstime/reltime types or all of them? I thought the
former were deprecated anyway.
abstime should probably be considered deprecated as a user type, but
it is still used extensively internally and within the tuple
structure. I'd be reluctant to wholesale replace it with
timestamp/datetime, since that will take 8 bytes per value rather than
4.
I was meaning to ask you which of the date/time types are going to be
left standing when the dust settles. (I know you've said, but the
archives are so messed up right now that I can't find it.)
Timestamp is the only remaining standard type without an array type,
and if it's not going to be deprecated then it ought to have one...
regards, tom lane
From bouncefilter Mon Jan 17 03:18:56 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA24271;
Mon, 17 Jan 2000 03:17:57 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id IAA14114;
Mon, 17 Jan 2000 08:26:29 GMT
Sender: lockhart@hub.org
Message-ID: <3882D234.7A1379C6@alumni.caltech.edu>
Date: Mon, 17 Jan 2000 08:26:28 +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@hub.org>
CC: committers@postgreSQL.org, Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [COMMITTERS] pgsql/src/include/catalog (pg_type.h)
References: <200001170129.UAA01587@hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hmm, numeric array type was missing too. Added.
Of the standard types, only 'timestamp' seems not to have an array
type; should it be added, or are we going to remove that type for 7.0
anyway?
Will be removed/replaced.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 17 03:23:54 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA24927
for <hackers@postgreSQL.org>; Mon, 17 Jan 2000 03:23:20 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id IAA14131;
Mon, 17 Jan 2000 08:31:52 GMT
Sender: lockhart@hub.org
Message-ID: <3882D378.71F6A86@alumni.caltech.edu>
Date: Mon, 17 Jan 2000 08:31:52 +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: hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO list
References: <Pine.LNX.4.21.0001151259300.386-100000@localhost.localdomain>
<3882CC7A.25F9C11F@alumni.caltech.edu>
<20305.948096539@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I was meaning to ask you which of the date/time types are going to be
left standing when the dust settles. (I know you've said, but the
archives are so messed up right now that I can't find it.)
Timestamp is the only remaining standard type without an array type,
and if it's not going to be deprecated then it ought to have one...
"timestamp" will continue, but *all* of the code will come from a
renamed "datetime". So don't bother adding anything for timestamp,
since it will magically appear when datetime gets renamed.
btw, I will make "datetime" a synonym for "timestamp", so existing
apps should work without change.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 17 04:21:56 2000
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 EAA36933
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 04:21:10 -0500 (EST) (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 SAA01877; Mon, 17 Jan 2000 18:19:31 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] RE: Getting rid of setheapoverride (was Re:
[COMMITTERS] heap.c)
Date: Mon, 17 Jan 2000 18:25:06 +0900
Message-ID: <001c01bf60cc$bdc0fe80$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <20198.948093168@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]Oh,I was just looking at heapoverride stuff quite accidentally.
Yes, this call is ugly and should be replaced byCommandCounterIncrement()
OK, I'm running a build now with setheapoverride calls removed.
Will see what happens.Well, it seems to work, but...
About half of the setheapoverride calls surrounded heap_update()
(formerly called heap_replace()) calls. AFAICS there is no need
for these calls unless heap_update itself needs them --- but there
are many calls to heap_update that do not have setheapoverride.I figured out that the cases where setheapoverride (or, now,
CommandCounterIncrement) were needed were the cases where the
heap_update might be updating a tuple created earlier in the
same command. pg_operator.c has some cases like that, but many of
the other uses of setheapoverride seem to be unnecessary.However, I'm a little uncomfortable with committing this change,
because my first try at it worked OK at creating things but fell
right over on DROP TABLE. I had replaced the setheapoverride(true)
in heap_drop_with_catalog() (backend/catalog/heap.c) with a
CommandCounterIncrement, and it failed with this backtrace:(gdb) bt
#0 elog (lev=-1, fmt=0x6b160 "cannot find attribute %d of relation %s")
at elog.c:112
#1 0x1767d8 in build_tupdesc_ind (buildinfo={infotype = 1, i = {
info_id = 19040,
info_name = 0x4a60}},
relation=0x4006ef00, natts=1074198864) at relcache.c:527
#2 0x176554 in RelationBuildTupleDesc (buildinfo={infotype = 1, i = {
info_id = 19040,
info_name = 0x4a60 }},
relation=0x1, natts=1074198864) at relcache.c:437
#3 0x177230 in RelationBuildDesc (buildinfo={infotype = 1, i = {
info_id = 19040,
info_name = 0x4a60 }},
oldrelation=0x4006ef00) at relcache.c:808
#4 0x177b28 in RelationClearRelation (relation=0x4006ef00,
rebuildIt=0 '\000')
at relcache.c:1279
#5 0x177bbc in RelationFlushRelation (relationPtr=0xffffffff,
onlyFlushReferenceCountZero=96 '`') at relcache.c:1320
#6 0x177e10 in RelationIdInvalidateRelationCacheByRelationId (
relationId=19040) at relcache.c:1415
#7 0x175968 in CacheIdInvalidate (cacheId=4294967295, hashIndex=438624,
pointer=0x1) at inval.c:544
#8 0x175ae8 in InvalidationMessageCacheInvalidate (message=0x4007cce4)
at inval.c:657
#9 0x175490 in LocalInvalidInvalidate (invalid=0x4007cce4 "r",
function=0x4000c3ca <DINFINITY+9226>, freemember=1 '\001') at
inval.c:173
#10 0x175ca4 in ImmediateLocalInvalidation (send=-1 '���') at inval.c:806
#11 0x9d0b0 in AtCommit_LocalCache () at xact.c:687
#12 0x9cf70 in CommandCounterIncrement () at xact.c:520
#13 0xa7a08 in heap_drop_with_catalog (relname=0x4006ef00 "������������")
at heap.c:1528
#14 0xb16ac in RemoveRelation (name=0x40083328 "ff1") at creatinh.c:217
#15 0x13ce84 in ProcessUtility (parsetree=0x40083370, dest=Remote)
at utility.c:201
#16 0x13add0 in pg_exec_query_dest (query_string=0x40024270 "drop
table ff1",
dest=Remote, aclOverride=1 '\001') at postgres.c:721Apparently, if I call CommandCounterIncrement while partway through
dropping a relation, it will try to rebuild the relcache entry for
the relation --- and of course fail. I'm too tired to figure out
whether this is just a small coding error in the new cache invalidation
code or whether it's a serious limitation in the whole design. Hiroshi,
what do you think?
Hmmm,CommandCounterIncrement() was about to rebuild relation decriptor
for the half dropped table and failed. It seems impossible to call Command-
CounterIncrement() in heap_drop_with_catalog.
I don't understand why DeleteTypeTuple() require setheapoverride().
Does anyone know ?
If no one knows,we had better remove setheapoverride().
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Jan 17 05:50:56 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA60625
for <hackers@postgresql.org>; Mon, 17 Jan 2000 05:50:01 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12A9jZ-000143-00; Mon, 17 Jan 2000 10:50:05 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12A9jT-0005dQ-00; Mon, 17 Jan 2000 10:49:59 +0000
Date: Mon, 17 Jan 2000 10:49:59 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: hackers@postgresql.org
Subject: Re: [HACKERS] flex
Message-ID: <20000117104959.D21506@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <200001160235.VAA26882@candle.pha.pa.us>
<Pine.LNX.4.21.0001162035480.1636-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <Pine.LNX.4.21.0001162035480.1636-100000@localhost.localdomain>;
from peter_e@gmx.net on Sun, Jan 16, 2000 at 09:13:03PM +0100
On Sun, Jan 16, 2000 at 09:13:03PM +0100, Peter Eisentraut wrote:
This puzzles me a bit still, but it seems to work. GNU suggests putting
yacc and lex files in distributions, so I can't imagine why they would do
that if you need to have lib[f]l.a anyway.$ nm /usr/lib/libfl.a
libmain.o:
00000000 t gcc2_compiled.
00000000 T main
U yylexlibyywrap.o:
00000000 t gcc2_compiled.
00000000 T yywrap
I think those are defaults for the case where you just have a lex file, but
didn't bother with defining a main() after the last %% eg:
%%
A putchar('b');
%%
When linked with -lfl, you get an executable. In the postgresql case, life
is more complicated and the parser calls yylex rather than a fake main(), so
-lfl isn't needed.
Cheers,
Patrick
From bouncefilter Mon Jan 17 06:08:56 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA65691
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 06:07:59 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Puma.DoCS.UU.SE (e99re41@Puma.DoCS.UU.SE [130.238.9.112])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA00333;
Mon, 17 Jan 2000 12:07:48 +0100 (MET)
Received: from localhost (e99re41@localhost) by Puma.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA08604;
Mon, 17 Jan 2000 12:07:44 +0100
X-Authentication-Warning: Puma.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 17 Jan 2000 12:07:43 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump not in very good shape
In-Reply-To: <20029.948090556@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.10001171205210.8593-100000@Puma.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 17 Jan 2000, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
On 2000-01-15, Tom Lane mentioned:
I am inclined to go ahead and insert vsnprintf into libpq.
I think including this in libpq is the wrong way to go. [snip]
A better idea would be to do what psql does with snprintf: Just include
the [v]snprintf.o file in the compilation (linking) conditionally.Sorry if I was unclear, but that was exactly what I meant.
BTW, since this is now done in libpq, you could probably remove
snprintf.o from psql ...
Hmm, maybe this is not what I meant. I meant adding the linking line to
pg_dump, not libpq. But I guess as long as we don't tell anyone about it
(vsnprintf being in libpq) we can safely take it out later if someone has
a better plan.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 17 06:13:56 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA66344
for <hackers@postgreSQL.org>; Mon, 17 Jan 2000 06:13:48 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Puma.DoCS.UU.SE (e99re41@Puma.DoCS.UU.SE [130.238.9.112])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA00935;
Mon, 17 Jan 2000 12:13:40 +0100 (MET)
Received: from localhost (e99re41@localhost) by Puma.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA08608;
Mon, 17 Jan 2000 12:13:35 +0100
X-Authentication-Warning: Puma.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 17 Jan 2000 12:13:35 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO list
In-Reply-To: <3882CC7A.25F9C11F@alumni.caltech.edu>
Message-ID: <Pine.GSO.4.02A.10001171210490.8593-100000@Puma.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 17 Jan 2000, Thomas Lockhart wrote:
* Make Absolutetime/Relativetime int4 because time_t can be int8 on some
ports
Does this mean the abstime/reltime types or all of them? I thought the
former were deprecated anyway.abstime should probably be considered deprecated as a user type, but
it is still used extensively internally and within the tuple
structure. I'd be reluctant to wholesale replace it with
timestamp/datetime, since that will take 8 bytes per value rather than
4.
Just so I understand this: The official SQL data types are "timestamp" and
"interval", right? Everything else will eventually be an alias or phased
out or whatever?
I've been itching to change the pg_shadow.valuntil column to timestamp
anyway, I suppose that would be a step in the right direction, or not?
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 17 07:44:57 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA84647
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 07:44:10 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max03-063.enterprise.net
[194.72.196.63])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id MAA29280
for <pgsql-hackers@postgreSQL.org>; Mon, 17 Jan 2000 12:44:08 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id MAA12727
for <pgsql-hackers@postgreSQL.org>; Mon, 17 Jan 2000 12:43:44 GMT
Message-Id: <200001171243.MAA12727@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Foreign keys: unexpected result from ALTER TABLE... ADD CONSTRAINT...
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0
Date: Mon, 17 Jan 2000 12:43:44 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id HAA84705
I cannot do this pair of table creations directly, because they are mutually
dependent.
create table purchased_job
(
supplier char(10) not null
references supplier (id) match full,
specification text,
del_point char(2) not null
references location (id) match full,
import_licence bool default 'f',
import_duty numeric(12,2),
terms char(3),
deliv_clear numeric(12,2),
foreign key (product, supplier) references product_supplier (product,
supplier) match full
)
inherits (job)
;
create table product_supplier
(
product char(10) not null
references purchased_job (product) match full,
supplier char(10) not null
references supplier (id) match full,
primary key (product, supplier)
)
;
so I omitted the foreign key specification from the creation of purchased_job
and tried to add it afterwards, but (after fixing a bug in gram.y) I found
that ALTER TABLE ... ADD CONSTRAINT is not yet implemented. Is there, then, any
way to create this mutual dependency?
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"And, behold, I come quickly; and my reward is with me,
to give every man according as his work shall be."
Revelation 22:12
From bouncefilter Mon Jan 17 08:06:58 2000
Received: from meryl.it.uu.se (meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA90236
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 08:06:11 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Puma.DoCS.UU.SE (e99re41@Puma.DoCS.UU.SE [130.238.9.112])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id OAA10573;
Mon, 17 Jan 2000 14:05:56 +0100 (MET)
Received: from localhost (e99re41@localhost) by Puma.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id OAA10756;
Mon, 17 Jan 2000 14:05:52 +0100
X-Authentication-Warning: Puma.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 17 Jan 2000 14:05:51 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Oliver Elphick <olly@lfix.co.uk>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Foreign keys: unexpected result from ALTER TABLE...
ADD CONSTRAINT...
In-Reply-To: <200001171243.MAA12727@linda.lfix.co.uk>
Message-ID: <Pine.GSO.4.02A.10001171401260.8593-100000@Puma.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 17 Jan 2000, Oliver Elphick wrote:
I cannot do this pair of table creations directly, because they are mutually
dependent.
I don't think this will ever work. I can't really decode your intentions
here but I recall that translating proper relational schemas (you know,
the ones with the bubbles and lines) into tables never creates this sort
of situation. Then again I could be wrong.
create table purchased_job
(
supplier char(10) not null
references supplier (id) match full,
specification text,
del_point char(2) not null
references location (id) match full,
import_licence bool default 'f',
import_duty numeric(12,2),
terms char(3),
deliv_clear numeric(12,2),foreign key (product, supplier) references product_supplier (product,
supplier) match full
)
inherits (job)
;create table product_supplier
(
product char(10) not null
references purchased_job (product) match full,
supplier char(10) not null
references supplier (id) match full,primary key (product, supplier)
)
;so I omitted the foreign key specification from the creation of purchased_job
and tried to add it afterwards, but (after fixing a bug in gram.y) I found
that ALTER TABLE ... ADD CONSTRAINT is not yet implemented. Is there, then, any
way to create this mutual dependency?
Thanks for that fix, that was me changing the grammar for an ALTER TABLE /
ALTER COLUMN implementation, which now works btw.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 17 08:52:58 2000
Received: from pmail1.gmx.net (pmail1.gmx.net [194.221.183.71])
by hub.org (8.9.3/8.9.3) with SMTP id IAA98848
for <pgsql-hackers@postgresql.org>;
Mon, 17 Jan 2000 08:52:13 -0500 (EST) (envelope-from hakan42@gmx.de)
Received: (qmail 17673 invoked by uid 0); 17 Jan 2000 13:52:11 -0000
Received: from ns1148.munich.netsurf.de (HELO taubnessel.pcp.local)
(195.180.235.148)
by pmail1.gmx.net with SMTP; 17 Jan 2000 13:52:11 -0000
From: Hakan Tandogan <hakan42@gmx.de>
To: pgsql-hackers@postgresql.org
Subject: Auto-lowercasing of column names?
Date: Mon, 17 Jan 2000 14:45:42 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <00011714543200.09747@taubnessel.pcp.local>
Content-Transfer-Encoding: 8bit
Hi,
I'm sending this to -hackers instead of -users because I think I'm
asking for a new feature in psql.
My Problem: If I run a sql file with create-table-statements through
psql, all the column names get automagically lowercased. On the other hand, the
Object-Relational-Mapping tool I'm using recreates all its objects from a
ResultSet, getting the lowercase names, and compares them with uppercase ones,
thus failing silently.
I'm working around this issue by enclosing the column names in ",
leading to slightly ugly ddl files (create table USERROLE ("ROLEID" serial
PRIMARY KEY, "PERMISSION" varchar);) and the necessity to change the default
data files (enclosing column names in insert statements with ").
Would it be possible to add a flag to psql, telling it to accept the
column names as they are in the ddl file?
Regards,
Hakan
--
Hakan Tandogan hakan@iconsult.com
ICONSULT Tandogan - Egerer GbR Tel.: +49-9131-9047-0
Memelstrasse 38 - D-91052 Erlangen Fax.: +49-9131-9047-77
"Any sufficiently advanced bug is indistinguishable from a feature"
From bouncefilter Mon Jan 17 09:07:01 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA05849
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 09:06:30 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max04-059.enterprise.net
[194.72.196.179])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id OAA21064;
Mon, 17 Jan 2000 14:06:27 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id OAA14889;
Mon, 17 Jan 2000 14:06:02 GMT
Message-Id: <200001171406.OAA14889@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Foreign keys: unexpected result from ALTER TABLE... ADD
CONSTRAINT...
In-Reply-To: Message from Peter Eisentraut <e99re41@DoCS.UU.SE> of "Mon,
17 Jan 2000 14:05:51 +0100."
<Pine.GSO.4.02A.10001171401260.8593-100000@Puma.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10001171401260.8593-100000@Puma.DoCS.UU.SE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 17 Jan 2000 14:06:01 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Peter Eisentraut wrote:
On Mon, 17 Jan 2000, Oliver Elphick wrote:
I cannot do this pair of table creations directly, because they are mutual
ly
dependent.
I don't think this will ever work. I can't really decode your intentions
here but I recall that translating proper relational schemas (you know,
the ones with the bubbles and lines) into tables never creates this sort
of situation. Then again I could be wrong.
The idea is that suppliers of products can only supply products that are
purchased, rather than manufactured; and purchased products must have
suppliers. However, it is possible for there to be more than one potential
supplier of a product; the one listed in purchased_jobs is the currently
favoured supplier.
I guess I will have to remove the restriction that products listed in
product_suppliers must be purchased; it may indeed become possible for the
to change status from time to time, so that is not too unsatisfactory.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"And, behold, I come quickly; and my reward is with me,
to give every man according as his work shall be."
Revelation 22:12
From bouncefilter Mon Jan 17 09:06:59 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA05826
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 09:06:25 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Puma.DoCS.UU.SE (e99re41@Puma.DoCS.UU.SE [130.238.9.112])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id PAA16054;
Mon, 17 Jan 2000 15:06:20 +0100 (MET)
Received: from localhost (e99re41@localhost) by Puma.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id PAA11329;
Mon, 17 Jan 2000 15:06:16 +0100
X-Authentication-Warning: Puma.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 17 Jan 2000 15:06:15 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Hakan Tandogan <hakan42@gmx.de>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Auto-lowercasing of column names?
In-Reply-To: <00011714543200.09747@taubnessel.pcp.local>
Message-ID: <Pine.GSO.4.02A.10001171503470.8593-100000@Puma.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
This is standard, documented behaviour. No way we can change that. Is
there a reason why your front-end tools cannot compare the names
case-insensitively?
On Mon, 17 Jan 2000, Hakan Tandogan wrote:
Hi,
I'm sending this to -hackers instead of -users because I think I'm
asking for a new feature in psql.My Problem: If I run a sql file with create-table-statements through
psql, all the column names get automagically lowercased. On the other hand, the
Object-Relational-Mapping tool I'm using recreates all its objects from a
ResultSet, getting the lowercase names, and compares them with uppercase ones,
thus failing silently.I'm working around this issue by enclosing the column names in ",
leading to slightly ugly ddl files (create table USERROLE ("ROLEID" serial
PRIMARY KEY, "PERMISSION" varchar);) and the necessity to change the default
data files (enclosing column names in insert statements with ").Would it be possible to add a flag to psql, telling it to accept the
column names as they are in the ddl file?Regards,
Hakan
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 17 09:18:58 2000
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA08378
for <pgsql-hackers@postgresql.org>;
Mon, 17 Jan 2000 09:18:53 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (sfcabop1.nettuno.it [193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id PAA24889;
Mon, 17 Jan 2000 15:15:41 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 12ADrh-0004Iq-00; Mon, 17 Jan 2000 15:14:45 +0000
Message-ID: <38832494.6AE76553@sferacarta.com>
Date: Mon, 17 Jan 2000 15:17:56 +0100
From: Jose Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
"Ansley, Michael" <Michael.Ansley@intec.co.za>,
"'Bruce Momjian '" <pgman@candle.pha.pa.us>,
"'PostgreSQL-development '" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Informix and OUTER join syntax
References: <1BF7C7482189D211B03F00805F8527F748C445@S-NATH-EXCH2>
<3.0.1.32.20000114205251.0109e880@mail.pacifier.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Don Baccus wrote:
At 03:20 AM 1/15/00 +0000, Thomas Lockhart wrote:
I was under the impression that if you used NATURAL JOIN, then the join
would be made on the declared keys.Nope. On column names in common.
(phew!) This is how I remembered it. Though it's in Boston and I'm
in Portland (OR, that is), due to my space-headedness, I can strongly
recommend that interested folks spend some of those $25,000 or so
dollars saved by not using Oracle on a copy of Date's SQL primer :)(I forget the exact title, but it's pretty good. I'll probably pick
up the standard, too, but Date's book is as much critique as explanation
and the SQL 92 standard seems in need of critical comments)- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.************
IMHO "A Guide to THE SQL STANDARD" by Date/Darwen is an interesting
documentation but I'm reading
another very, very interesting book about SQL, here the title in english:
"SQL: The Standard Handbook" (Based on the New SQL Standard ISO 9075:1992(E)
by Stephen Cannan and Gerard Otten.
This a clear explanation of SQL standard made by two persons that colaborated
direct or indirect to establish
such Standard.
Jos���
From bouncefilter Mon Jan 17 09:25:58 2000
Received: from mail2.gmx.net (mail2.gmx.net [194.221.183.62])
by hub.org (8.9.3/8.9.3) with SMTP id JAA09143
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 09:25:40 -0500 (EST) (envelope-from hakan42@gmx.de)
Received: (qmail 8639 invoked by uid 0); 17 Jan 2000 14:25:38 -0000
Received: from ns1148.munich.netsurf.de (HELO taubnessel.pcp.local)
(195.180.235.148)
by mail2.gmx.net with SMTP; 17 Jan 2000 14:25:38 -0000
From: Hakan Tandogan <hakan42@gmx.de>
To: Peter Eisentraut <peter_e@gmx.net>
Subject: Re: [HACKERS] Auto-lowercasing of column names?
Date: Mon, 17 Jan 2000 15:20:32 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.GSO.4.02A.10001171503470.8593-100000@Puma.DoCS.UU.SE>
In-Reply-To: <Pine.GSO.4.02A.10001171503470.8593-100000@Puma.DoCS.UU.SE>
Cc: pgsql-hackers@postgreSQL.org
MIME-Version: 1.0
Message-Id: <00011715275800.10647@taubnessel.pcp.local>
Content-Transfer-Encoding: 8bit
On Mon, 17 Jan 2000, you wrote:
This is standard, documented behaviour. No way we can change that. Is
Thus, a flag to psql, per default keeping the documented behaviour like
it is.
there a reason why your front-end tools cannot compare the names
case-insensitively?
Yes and No. They (the authors) told me to change my ddl scripts. The
bad part is that I can't modify them automatically (except by writing a full SQL
parser ;-) ). Thus, I have to watch for changes to the database schemas / data
and modify my own ddl scripts accordingly. While not a full-time-job by itself,
this solutions simply struck me as "not beautiful (tm)". Well, I guess I can
live a little longer with hand-modifying the ddl files ;-).
Regards,
Hakan
--
Hakan Tandogan hakan@iconsult.com
ICONSULT Tandogan - Egerer GbR Tel.: +49-9131-9047-0
Memelstrasse 38 - D-91052 Erlangen Fax.: +49-9131-9047-77
"Any sufficiently advanced bug is indistinguishable from a feature"
From bouncefilter Mon Jan 17 09:22:58 2000
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 JAA08771
for <pgsql-hackers@postgresql.org>;
Mon, 17 Jan 2000 09:22:25 -0500 (EST)
(envelope-from theo@flame.co.za)
Received: from flame.co.za (flame.flame.co.za [160.124.170.1])
by flame.flame.co.za (8.8.7/8.8.7) with ESMTP id QAA20026
for <pgsql-hackers@postgresql.org>; Mon, 17 Jan 2000 16:28:43 +0200
Sender: theo@flame.flame.co.za
Message-ID: <3883271B.518645BA@flame.co.za>
Date: Mon, 17 Jan 2000 16:28:43 +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
Subject: DefineQueryRewrite: rule plan string too big.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi
Just created a rule and received "rule plan string too big". My rule is around
1000 characters long. I added a debug statement which printed the following from
backend/rewrite/rewriteDefine.c
sizeof(FormData_pg_rewrite) = 60, strlen(actionbuf) = 6328, strlen(qualbuf) = 4279, MaxAttrSize = 8104
so my rule expands to 10667 characters.
Questions I have
1. Is it feasable to increase MaxAttrSize without upsetting the applecart?
2. Does this limitation not severely restrict setting up of rules? Ie. I
want to log any update on any field made to a 16 attribute table.
The rule is as follows
create rule log_accounts as on update to accounts
where new.domain != old.domain or
new.RegistrationDate != old.RegistrationDate or
new.RegistrationType != old.RegistrationType or
new.Amount != old.Amount or
new.BillingType != old.BillingType or
new.ContactEmail != old.ContactEmail or
new.PaperDate != old.PaperDate or
new.PaymentDate != old.PaymentDate or
new.InvoiceCount != old.InvoiceCount or
new.InvoiceNo != old.InvoiceNo or
new.ContractType != old.ContractType or
new.Organisation != old.Organisation or
new.Payed != old.Payed
do insert into accounts_log values (
getpgusername(),
'now'::text,
new.domain,
new.RegistrationDate,
new.RegistrationType,
new.Amount,
new.BillingType,
new.ContactEmail,
new.PaperDate,
new.PaymentDate,
new.InvoiceCount,
new.InvoiceNo,
new.ContractType,
new.Organisation,
new.Payed,
new.PaperContract
);
3. Is there a better way to do this?
TIA
--------
Regards
Theo
From bouncefilter Mon Jan 17 09:35:59 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA13941
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 09:35:35 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max05-014.enterprise.net
[194.72.197.14])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id OAA29344;
Mon, 17 Jan 2000 14:35:32 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id OAA01785;
Mon, 17 Jan 2000 14:34:06 GMT
Message-Id: <200001171434.OAA01785@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: Peter Eisentraut <e99re41@DoCS.UU.SE>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: psql and COPY
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 17 Jan 2000 14:34:06 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Peter, there seem to be problems with the COPY statement when psql is run
with redirected stdin.
If I have a file ${DUMPDIR}/dbdump.product containing:
COPY product FROM stdin;
05 \N 000000 \N \N S D9 t f f f POLY BAGS-BLACK . Single f
...
\.
and I run this command:
psql -e -d bray < ${DUMPDIR}/dbdump.product
no error messages are seen.
If I remove the COPY command from the file and run the COPY frpm inside
psql, I see the errors:
bray=> copy product from '/tmp/dbdump.product';
ERROR: <unnamed> referential integrity violation - key referenced from
product not found in brandname
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"And, behold, I come quickly; and my reward is with me,
to give every man according as his work shall be."
Revelation 22:12
From bouncefilter Mon Jan 17 09:36:59 2000
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 JAA14096
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 09:36:39 -0500 (EST)
(envelope-from theo@flame.co.za)
Received: from flame.co.za (flame.flame.co.za [160.124.170.1])
by flame.flame.co.za (8.8.7/8.8.7) with ESMTP id QAA20068
for <pgsql-hackers@postgreSQL.org>; Mon, 17 Jan 2000 16:43:04 +0200
Sender: theo@flame.flame.co.za
Message-ID: <38832A78.5831175@flame.co.za>
Date: Mon, 17 Jan 2000 16:43:04 +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
Subject: Re: [HACKERS] DefineQueryRewrite: rule plan string too big.
References: <3883271B.518645BA@flame.co.za>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Theo Kramer wrote:
Just created a rule and received "rule plan string too big". My rule is around
1000 characters long. I added a debug statement which printed the following from
backend/rewrite/rewriteDefine.c
Oops forgot to mention: Postgres 6.5.2
--------
Regards
Theo
From bouncefilter Mon Jan 17 09:57:59 2000
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 JAA16999
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 09:56:59 -0500 (EST)
(envelope-from theo@flame.co.za)
Received: from flame.co.za (flame.flame.co.za [160.124.170.1])
by flame.flame.co.za (8.8.7/8.8.7) with ESMTP id RAA20960
for <pgsql-hackers@postgreSQL.org>; Mon, 17 Jan 2000 17:03:31 +0200
Sender: theo@flame.flame.co.za
Message-ID: <38832F42.A7884F11@flame.co.za>
Date: Mon, 17 Jan 2000 17:03:30 +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
Subject: Re: [HACKERS] DefineQueryRewrite: rule plan string too big.
References: <3883271B.518645BA@flame.co.za>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I wrote:
Hi
Just created a rule and received "rule plan string too big". My rule is around
1000 characters long. I added a debug statement which printed the following from
backend/rewrite/rewriteDefine.c
...
3. Is there a better way to do this?
Was being thick... I removed the 'where' clause and now it fits and works.
--------
Regards
Theo
From bouncefilter Mon Jan 17 10:14:59 2000
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 KAA23597
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 10:14:57 -0500 (EST) (envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@postgreSQL.org>
id m12ADjI-0003kMC; Mon, 17 Jan 100 16:06 MET
Sender: wieck
Message-ID: <38832FDC.5B5EC18D@debis.com>
Date: Mon, 17 Jan 2000 16:06:04 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump not in very good shape
References: <200001170619.BAA13413@candle.pha.pa.us>
<20156.948092214@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Actually the megatest is:
pg_dump regress > out
dropdb regression
createdb regression
psql regression < out
pg_dump regress > out2
diff out out2That is the pg_dump test, and someone usually does it as part of
regression testing before each release.It would be nice to add this to test/regress/Makefile maybe.
That's a good thought --- it eliminates both the platform-specific
issues and the problem of adding a bulky reference file to the
distribution.
Still an incomplete test at all.
It doesn't guarantee, that the resulting dump is what you
really need to restore the database. For example, I'm not
sure that FOREIGN KEY constraints are actually dumped
correct (as constraint trigger statements after the data
load). So it might work, and result in the same, wrong dump
again.
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 Jan 17 10:58:59 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA32716
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 10:58:24 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA20876;
Mon, 17 Jan 2000 10:58:15 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Foreign keys: unexpected result from ALTER TABLE... ADD
CONSTRAINT...
In-reply-to: <200001171406.OAA14889@linda.lfix.co.uk>
References: <Pine.GSO.4.02A.10001171401260.8593-100000@Puma.DoCS.UU.SE>
<200001171406.OAA14889@linda.lfix.co.uk>
Comments: In-reply-to "Oliver Elphick" <olly@lfix.co.uk>
message dated "Mon, 17 Jan 2000 14:06:01 +0000"
Date: Mon, 17 Jan 2000 10:58:15 -0500
Message-ID: <20873.948124695@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Oliver Elphick" <olly@lfix.co.uk> writes:
I guess I will have to remove the restriction that products listed in
product_suppliers must be purchased; it may indeed become possible for the
to change status from time to time, so that is not too unsatisfactory.
You could possibly enforce dependencies like that by using a trigger
function, instead of foreign-key stuff.
regards, tom lane
From bouncefilter Mon Jan 17 11:17:05 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA38795
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 11:16:15 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA29001;
Mon, 17 Jan 2000 11:15:49 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001171615.LAA29001@candle.pha.pa.us>
Subject: Re: [HACKERS] RE: Getting rid of setheapoverride (was Re:
[COMMITTERS]
heap.c)
In-Reply-To: <20198.948093168@sss.pgh.pa.us> from Tom Lane at "Jan 17,
2000 02:12:48 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 17 Jan 2000 11:15:49 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=UNKNOWN-8BIT
Content-Transfer-Encoding: 8bit
About half of the setheapoverride calls surrounded heap_update()
(formerly called heap_replace()) calls. AFAICS there is no need
for these calls unless heap_update itself needs them --- but there
are many calls to heap_update that do not have setheapoverride.I figured out that the cases where setheapoverride (or, now,
CommandCounterIncrement) were needed were the cases where the
heap_update might be updating a tuple created earlier in the
same command. pg_operator.c has some cases like that, but many of
the other uses of setheapoverride seem to be unnecessary.
I thought about that this morning and suspected this may be the case,
though I thought tuples would be visible to the same transaction
automatically. Hard to imagine why we would not want such visibility in
all cases.
However, I'm a little uncomfortable with committing this change,
because my first try at it worked OK at creating things but fell
right over on DROP TABLE. I had replaced the setheapoverride(true)
in heap_drop_with_catalog() (backend/catalog/heap.c) with a
CommandCounterIncrement, and it failed with this backtrace:(gdb) bt
#0 elog (lev=-1, fmt=0x6b160 "cannot find attribute %d of relation %s")
at elog.c:112
#1 0x1767d8 in build_tupdesc_ind (buildinfo={infotype = 1, i = {
info_id = 19040,
info_name = 0x4a60}},
relation=0x4006ef00, natts=1074198864) at relcache.c:527
#2 0x176554 in RelationBuildTupleDesc (buildinfo={infotype = 1, i = {
info_id = 19040,
info_name = 0x4a60 }},
relation=0x1, natts=1074198864) at relcache.c:437
#3 0x177230 in RelationBuildDesc (buildinfo={infotype = 1, i = {
info_id = 19040,
info_name = 0x4a60 }},
oldrelation=0x4006ef00) at relcache.c:808
#4 0x177b28 in RelationClearRelation (relation=0x4006ef00, rebuildIt=0 '\000')
at relcache.c:1279
#5 0x177bbc in RelationFlushRelation (relationPtr=0xffffffff,
onlyFlushReferenceCountZero=96 '`') at relcache.c:1320
#6 0x177e10 in RelationIdInvalidateRelationCacheByRelationId (
relationId=19040) at relcache.c:1415
#7 0x175968 in CacheIdInvalidate (cacheId=4294967295, hashIndex=438624,
pointer=0x1) at inval.c:544
#8 0x175ae8 in InvalidationMessageCacheInvalidate (message=0x4007cce4)
at inval.c:657
#9 0x175490 in LocalInvalidInvalidate (invalid=0x4007cce4 "r",
function=0x4000c3ca <DINFINITY+9226>, freemember=1 '\001') at inval.c:173
#10 0x175ca4 in ImmediateLocalInvalidation (send=-1 '���') at inval.c:806
#11 0x9d0b0 in AtCommit_LocalCache () at xact.c:687
#12 0x9cf70 in CommandCounterIncrement () at xact.c:520
#13 0xa7a08 in heap_drop_with_catalog (relname=0x4006ef00 "������������")
at heap.c:1528
#14 0xb16ac in RemoveRelation (name=0x40083328 "ff1") at creatinh.c:217
#15 0x13ce84 in ProcessUtility (parsetree=0x40083370, dest=Remote)
at utility.c:201
#16 0x13add0 in pg_exec_query_dest (query_string=0x40024270 "drop table ff1",
dest=Remote, aclOverride=1 '\001') at postgres.c:721Apparently, if I call CommandCounterIncrement while partway through
dropping a relation, it will try to rebuild the relcache entry for
the relation --- and of course fail. I'm too tired to figure out
whether this is just a small coding error in the new cache invalidation
code or whether it's a serious limitation in the whole design. Hiroshi,
what do you think?I was able to get around this by simply removing CommandCounterIncrement
from heap_drop_with_catalog entirely --- dropping tables seems to work
fine that way ... but I don't trust it ...
With buggy code like that, it seems we could just try removing them all,
and adding them back in as part of beta testing as people find problems.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 17 11:19:11 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA39159;
Mon, 17 Jan 2000 11:18:13 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA29019;
Mon, 17 Jan 2000 11:17:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001171617.LAA29019@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql/src/include/catalog (pg_type.h)
In-Reply-To: <3882D234.7A1379C6@alumni.caltech.edu> from Thomas Lockhart at
"Jan 17, 2000 08:26:28 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Mon, 17 Jan 2000 11:17:26 -0500 (EST)
CC: Tom Lane <tgl@hub.org>, committers@postgreSQL.org,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hmm, numeric array type was missing too. Added.
Of the standard types, only 'timestamp' seems not to have an array
type; should it be added, or are we going to remove that type for 7.0
anyway?Will be removed/replaced.
We are going to internally move everything to the more standard ANSI
names, right, or do we give preference to the older types?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 17 11:19:07 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA39166
for <hackers@postgreSQL.org>; Mon, 17 Jan 2000 11:18:15 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA29027;
Mon, 17 Jan 2000 11:17:58 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001171617.LAA29027@candle.pha.pa.us>
Subject: Re: [HACKERS] TODO list
In-Reply-To: <3882D378.71F6A86@alumni.caltech.edu> from Thomas Lockhart at
"Jan
17, 2000 08:31:52 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Mon, 17 Jan 2000 11:17:58 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I was meaning to ask you which of the date/time types are going to be
left standing when the dust settles. (I know you've said, but the
archives are so messed up right now that I can't find it.)
Timestamp is the only remaining standard type without an array type,
and if it's not going to be deprecated then it ought to have one..."timestamp" will continue, but *all* of the code will come from a
renamed "datetime". So don't bother adding anything for timestamp,
since it will magically appear when datetime gets renamed.btw, I will make "datetime" a synonym for "timestamp", so existing
apps should work without change.
Got it. Never mind.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 17 11:21:15 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA39760
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 11:20:21 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA21001;
Mon, 17 Jan 2000 11:19:59 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Bruce Momjian" <pgman@candle.pha.pa.us>,
"pgsql-hackers" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] RE: Getting rid of setheapoverride (was Re:
[COMMITTERS] heap.c)
In-reply-to: <001c01bf60cc$bdc0fe80$2801007e@tpf.co.jp>
References: <001c01bf60cc$bdc0fe80$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Mon, 17 Jan 2000 18:25:06 +0900"
Date: Mon, 17 Jan 2000 11:19:59 -0500
Message-ID: <20998.948125999@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
Apparently, if I call CommandCounterIncrement while partway through
dropping a relation, it will try to rebuild the relcache entry for
the relation --- and of course fail. I'm too tired to figure out
whether this is just a small coding error in the new cache invalidation
code or whether it's a serious limitation in the whole design. Hiroshi,
what do you think?
Hmmm,CommandCounterIncrement() was about to rebuild relation decriptor
for the half dropped table and failed. It seems impossible to call Command-
CounterIncrement() in heap_drop_with_catalog.
I don't understand why DeleteTypeTuple() require setheapoverride().
As far as I can tell, it doesn't --- drop table seems to work just fine
without it.
I have been thinking some more about this, and have come to the
conclusion that it is only safe to call CommandCounterIncrement
at points where you have a self-consistent catalog tuple state.
In particular it must be possible to build valid relcache entries
from whatever tuples you are making visible with the increment.
For example, it's OK for heap_create to call C.C.I. after creating the
relation's pg_class, pg_type, and pg_attribute entries; the relation
is not finished, since it lacks default and constraint info, but
relcache.c won't have a problem with that. (Note that heap_create
explicitly forces a rebuild of the relcache entry after it's added
that extra stuff!)
It is *not* OK for heap_drop to call C.C.I. where it was doing it,
because it had already deleted the pg_attribute tuples, but was still
holding a refcount lock on the relcache entry for the target relation.
(If the refcount were zero, then relcache.c would have just dropped
the entry instead of trying to rebuild it...)
The heap_drop code was risky even in its original form of
setheapoverride, since had a relcache rebuild been caused during
DeleteTypeTuple(), it would have failed. (This could happen,
in the current state of the code, if an SI Reset message arrives
and gets processed while DeleteTypeTuple is trying to open pg_type.)
Switching to CommandCounterIncrement just exposed the latent bug
by forcing the rebuild attempt to occur.
In short, I have convinced myself that this is all fine. I will
finish ripping out setheapoverride and commit the changes tonight.
Should be able to simplify tqual.c a little bit now that we don't
need the override code.
regards, tom lane
From bouncefilter Mon Jan 17 11:23:01 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA40342
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 11:22:56 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA21024;
Mon, 17 Jan 2000 11:22:53 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump not in very good shape
In-reply-to: <Pine.GSO.4.02A.10001171205210.8593-100000@Puma.DoCS.UU.SE>
References: <Pine.GSO.4.02A.10001171205210.8593-100000@Puma.DoCS.UU.SE>
Comments: In-reply-to Peter Eisentraut <e99re41@DoCS.UU.SE>
message dated "Mon, 17 Jan 2000 12:07:43 +0100"
Date: Mon, 17 Jan 2000 11:22:53 -0500
Message-ID: <21021.948126173@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
A better idea would be to do what psql does with snprintf: Just include
the [v]snprintf.o file in the compilation (linking) conditionally.Sorry if I was unclear, but that was exactly what I meant.
BTW, since this is now done in libpq, you could probably remove
snprintf.o from psql ...
Hmm, maybe this is not what I meant. I meant adding the linking line to
pg_dump, not libpq.
Not a usable answer: that would mean that *every* application using
libpq would have to start including backend/port/snprintf.o, on the
platforms where vsnprintf doesn't exist.
But I guess as long as we don't tell anyone about it
(vsnprintf being in libpq)
It's certainly not going to become a published part of the interface,
if that's what you mean.
regards, tom lane
From bouncefilter Mon Jan 17 11:31:02 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA42321
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 11:30:26 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA21055;
Mon, 17 Jan 2000 11:29:58 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] RE: Getting rid of setheapoverride (was Re:
[COMMITTERS] heap.c)
In-reply-to: <200001171615.LAA29001@candle.pha.pa.us>
References: <200001171615.LAA29001@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 17 Jan 2000 11:15:49 -0500"
Date: Mon, 17 Jan 2000 11:29:58 -0500
Message-ID: <21052.948126598@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I figured out that the cases where setheapoverride (or, now,
CommandCounterIncrement) were needed were the cases where the
heap_update might be updating a tuple created earlier in the
same command. pg_operator.c has some cases like that, but many of
the other uses of setheapoverride seem to be unnecessary.
I thought about that this morning and suspected this may be the case,
though I thought tuples would be visible to the same transaction
automatically. Hard to imagine why we would not want such visibility in
all cases.
Normally you *don't* want tuples created/updated in the current command
to be visible. Consider an UPDATE proceeding by sequential scan. As it
finds tuples it needs to update, the updated versions of those tuples
will get added to the end of the relation. Eventually the UPDATE will
reach those tuples and be scanning its own output! Thanks to the
visibility rule, it will ignore those new tuples as not-yet-visible.
Without that, something as simple as "UPDATE t SET f = f + 1" would be
an infinite loop.
CommandCounterIncrement() is like a statement boundary inside a
transaction: after you call it, you can see the effects of your
prior operation (but no one else can; it's not a commit).
regards, tom lane
From bouncefilter Mon Jan 17 11:36:04 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA46201
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 11:35:38 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA00317;
Mon, 17 Jan 2000 11:33:07 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001171633.LAA00317@candle.pha.pa.us>
Subject: Re: [HACKERS] RE: Getting rid of setheapoverride (was Re:
[COMMITTERS]
heap.c)
In-Reply-To: <20998.948125999@sss.pgh.pa.us> from Tom Lane at "Jan 17,
2000 11:19:59 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 17 Jan 2000 11:33:07 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
As far as I can tell, it doesn't --- drop table seems to work just fine
without it.I have been thinking some more about this, and have come to the
conclusion that it is only safe to call CommandCounterIncrement
at points where you have a self-consistent catalog tuple state.
In particular it must be possible to build valid relcache entries
from whatever tuples you are making visible with the increment.
This is a good analysis.
For example, it's OK for heap_create to call C.C.I. after creating the
relation's pg_class, pg_type, and pg_attribute entries; the relation
is not finished, since it lacks default and constraint info, but
relcache.c won't have a problem with that. (Note that heap_create
explicitly forces a rebuild of the relcache entry after it's added
that extra stuff!)It is *not* OK for heap_drop to call C.C.I. where it was doing it,
because it had already deleted the pg_attribute tuples, but was still
holding a refcount lock on the relcache entry for the target relation.
(If the refcount were zero, then relcache.c would have just dropped
the entry instead of trying to rebuild it...)The heap_drop code was risky even in its original form of
setheapoverride, since had a relcache rebuild been caused during
DeleteTypeTuple(), it would have failed. (This could happen,
in the current state of the code, if an SI Reset message arrives
and gets processed while DeleteTypeTuple is trying to open pg_type.)
Switching to CommandCounterIncrement just exposed the latent bug
by forcing the rebuild attempt to occur.
This is an excellent point. We know we have some instability in
creating/droping tables in separate sessions at the same time. This may
not fix that, but it is clearly an issue that an SI message could arrive
at that time.
In short, I have convinced myself that this is all fine. I will
finish ripping out setheapoverride and commit the changes tonight.
Should be able to simplify tqual.c a little bit now that we don't
need the override code.
I know I am responsible for at least one of those function calls. I
remember asking about it in the past. I have added my first two emails
about this below. I may have added it whenever I did heap_update
because I never knew what it did, and the name was confusing to me.
---------------------------------------------------------------------------
From maillist Fri Aug 14 22:22:06 1998
Date: Fri, 14 Aug 1998 22:22:06 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
XFMstatus: 0000
To: (PostgreSQL-development) <hackers@postgreSQL.org>
Subject: setheapoverride
Content-Length: 346
Status: RO
Can someone tell me what setheapoverride() does? I see it around
heap_replace a lot.
---------------------------------------------------------------------------
Date: Sat, 18 Sep 1999 17:25:43 -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
XFMstatus: 0000
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] setheapoverride() considered harmful
Cc: pgsql-hackers@postgreSQL.org
Content-Length: 628
Status: RO
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
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 17 11:26:05 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA40872
for <hackers@postgreSQL.org>; Mon, 17 Jan 2000 11:25:28 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA14707;
Mon, 17 Jan 2000 16:34:00 GMT
Sender: lockhart@hub.org
Message-ID: <38834477.B9037F62@alumni.caltech.edu>
Date: Mon, 17 Jan 2000 16:33:59 +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: hackers@postgreSQL.org
Subject: Re: [HACKERS] TODO list
References: <Pine.GSO.4.02A.10001171210490.8593-100000@Puma.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The official SQL data types are "timestamp" and
"interval", right? Everything else will eventually be an alias or
phased out or whatever?
No (at least I haven't proposed that). abstime stays as a 4-byte
internal system time type. timestamp and interval become full-featured
date/time types, stealing all of the datetime and timespan code, and
the latter two become synonyms for timestamp and interval.
I've been itching to change the pg_shadow.valuntil column to timestamp
anyway, I suppose that would be a step in the right direction, or not?
At the moment, there are *no* 8-byte date/time types in the system
tables. This would be the first instance of that, and I'm not sure we
should introduce it in just one place.
Has abstime been a problem here?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 17 13:09:01 2000
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 NAA71983
for <hackers@postgreSQL.org>; Mon, 17 Jan 2000 13:08:19 -0500 (EST)
(envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <hackers@postgreSQL.org>
id m12AGRE-0003kMC; Mon, 17 Jan 100 18:59 MET
Sender: wieck
Message-ID: <38835888.4CF4257D@debis.com>
Date: Mon, 17 Jan 2000 18:59:36 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Peter Eisentraut <peter_e@gmx.net>,
Bruce Momjian <pgman@candle.pha.pa.us>,
hackers@postgreSQL.org
Subject: Re: [HACKERS] flex
References: <Pine.LNX.4.21.0001162035480.1636-100000@localhost.localdomain>
<20104.948091288@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
flex has a lexer-specific library (libfl.a), but as far as I can tell
our scanners don't call it. In fact our build process has no provision
for adding -lfl to the link, which I used to think was an oversight, but
now it's starting to seem like a good idea. We could ship scan.c et al
in the same way we handle the yacc/bison output files, and it should
work everywhere.This puzzles me a bit still, but it seems to work.
I suppose that libfl.a is only needed to support some flex features that
we don't use --- but I haven't bothered to dig in and find out what.
AFAIK, flex's libfl.a only contains a main() and a noop variant of
yywrap(). The main() in there only calls yylex() repeatedly so you can
write a scan.l that does text replacement etc. and simply compile the
generated C source into a standalone executable. Our backend already
contains a yywrap() (and a main() of course), so there are no symbols
that libfl.a could potentially resolve. Thus, it's not needed.
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 Jan 17 13:37:04 2000
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 NAA79587
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 13:36:01 -0500 (EST) (envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@postgreSQL.org>
id m12AGs3-0003kMC; Mon, 17 Jan 100 19:27 MET
Sender: wieck
Message-ID: <38835F06.9C0B7FDF@debis.com>
Date: Mon, 17 Jan 2000 19:27:18 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Foreign keys: unexpected result from ALTER TABLE... ADD
CONSTRAINT...
References: <Pine.GSO.4.02A.10001171401260.8593-100000@Puma.DoCS.UU.SE>
<200001171406.OAA14889@linda.lfix.co.uk>
<20873.948124695@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
"Oliver Elphick" <olly@lfix.co.uk> writes:
I guess I will have to remove the restriction that products listed in
product_suppliers must be purchased; it may indeed become possible for the
to change status from time to time, so that is not too unsatisfactory.You could possibly enforce dependencies like that by using a trigger
function, instead of foreign-key stuff.
In fact, ALTER TABLE ADD CONSTRAINT should do it!
It's absolutely legal and makes sense in some case. The constraints
must be deferrable then, and you must INSERT and/or UPDATE both rows
referring to each other in the same transaction while the constraints
are in deferred state.
A normal trigger is never deferrable, so it will be fired at the end
of the statement, not at COMMIT. Thus, a regular trigger will never
work for that!
In the mean time, you can setup the same RI triggers by hand using
CREATE CONSTRAINT TRIGGER with the appropriate builtin RI_FKey
functions. These commands are exactly what ALTER TABLE has to issue.
The functions are named RI_FKey_<action>_<event>, where <action> is
one of "check", "noaction", "restrict", "cascade", "setnull" or
"setdefault" and <event> is "ins", "upd" or "del". "check" has to be
used on the referencing table at INSERT and UPDATE. The others are
for the PK table to issue the requested action. Don't forget to add
"noaction" for the cases, where you don't want an action, otherwise
the deferred trigger queue manager will not notice if it has to raise
the "triggered data change violation" exception.
All RI_FKey functions take the following arguments:
* The constraint name
* The match type (FULL for now)
* The primary key tables name
* The referencing tables name
* Followed by pairs of PK-attrib, FK-attrib names.
With CREATE CONSTRAINT TRIGGER (which I added first so someone could
already work on pg_dump - what noone does up to now :-( ), you can
specify deferrability and initial deferred state for the trigger. And
it correctly sets up the PK<->FK tables relationships in pg_trigger,
so that DROPping one of them removes all the triggers using it from
the other one. Needless to say that dropping and recreating a PK
table looses all the references! But dropping and recreating the
referencing tables therefore doesn't put the PK table into an
unusable state.
So Peter, if you're working on ALTER TABLE ADD CONSTRAINT, let it
setup the appropriate RI triggers. Look at analyze.c how to do so.
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 Jan 17 15:19:02 2000
Received: from flex.flex.ro (IDENT:root@[193.230.255.4])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA04435
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 15:18:12 -0500 (EST) (envelope-from teo@flex.ro)
Received: from flex.ro (IDENT:teo@teo.flex.ro [193.230.255.3])
by flex.flex.ro (8.9.3/8.9.3) with ESMTP id XAA31314
for <pgsql-hackers@postgreSQL.org>; Mon, 17 Jan 2000 23:21:41 +0200
Sender: teo@flex.flex.ro
Message-ID: <38837919.881E79CC@flex.ro>
Date: Mon, 17 Jan 2000 22:18:33 +0200
From: Constantin Teodorescu <teo@flex.ro>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Unique constraint for inherited tables
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I am defining a table t1 with a NOT NULL field f1 and UNIQUE field f2.
(it automatically defines t1_f2_key unique index)
I am defining now a new table t2 that inherits t1 table and add some
columns.
The NOT NULL constraint is preserved for f1 field, the UNIQUE for f2 not
(the index t2_f2_key) is not defined.
Wouldn't be normal that the unique constraint to be inherited also in
t2?
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA
From bouncefilter Mon Jan 17 19:00:06 2000
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 TAA53778
for <hackers@postgresql.org>; Mon, 17 Jan 2000 19:00:00 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62669 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S149527AbQAQX7V>;
Tue, 18 Jan 2000 00:59:21 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12AMAM-00009p-00
for hackers@postgresql.org; Tue, 18 Jan 2000 01:06:34 +0100
Date: Tue, 18 Jan 2000 01:06:33 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: bugs@postgresql.org?
Message-ID: <Pine.LNX.4.21.0001170314580.1636-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
In my feeble frenzy to enforce a GNU-compliant user interface throughout
all client programs I have also been starting to stick a
Report bugs to <bugs@postgresql.org>.
into the --help output. (RMS would be proud.)
I have seen vague references to this email address being recommended for
bug reports, but I'm just wondering if this is still active or desirable
or whatever. Furthermore I'm not sure if this is a mailing list and who
gets this?
The current de facto procedure that bug reporters have to subscribe to the
hackers list is certainly not very user-friendly.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 17 19:09:06 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA58243
for <hackers@postgresql.org>; Mon, 17 Jan 2000 19:08:18 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id UAA16930;
Mon, 17 Jan 2000 20:08:15 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 17 Jan 2000 20:08:14 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Peter Eisentraut <peter_e@gmx.net>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] bugs@postgresql.org?
In-Reply-To: <Pine.LNX.4.21.0001170314580.1636-100000@localhost.localdomain>
Message-ID: <Pine.BSF.4.21.0001172007570.46499-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 18 Jan 2000, Peter Eisentraut wrote:
In my feeble frenzy to enforce a GNU-compliant user interface throughout
all client programs I have also been starting to stick aReport bugs to <bugs@postgresql.org>.
pgsql-bugs@postgresql.org ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Jan 18 00:20:11 2000
Received: from corvette.mascari.com (dhcp26142035.columbus.rr.com
[24.26.142.35]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA26112
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 00:19:14 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id AAA10762
for <pgsql-hackers@postgresql.org>; Tue, 18 Jan 2000 00:17:43 -0500
Sender: postgres@corvette.mascari.com
Message-ID: <3883B101.E0593FE7@mascari.com>
Date: Mon, 17 Jan 2000 19:17:05 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Is pg_dump still broken?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
On Sunday, I downloaded the newest snapshot of pg_dump, with Tom's fixes
applied (it no longer dumps core when dumping indexes). However, pg_dump
is incorrectly dumping argument lists for trigger procedures:
test=# drop trigger mytrigger on mytable;
DROP
test=# create trigger mytrigger
before insert on mytable
for each row execute procedure autoinc ('myfield', 'myseq');
CREATE
[postgres@ferrari /tmp]$ pg_dump test
...
CREATE TRIGGER "mytrigger" BEFORE INSERT ON "mytable" FOR EACH ROW
EXECUTE PROCEDURE autoinc ('myfield', 'myfieldmyseq');
...
Note the second parameter to autoinc() -- it should be 'myseq', not
'myfieldmyseq'. I suspect someone isn't doing a resetPQExpBuffer()
somewhere. Can anyone confirm this?
Mike Mascari
From bouncefilter Mon Jan 17 19:14:06 2000
Received: from hu.tm.ee (ppp134.tele2.ee [212.107.33.134])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA58772
for <pgsql-hackers@postgresql.org>;
Mon, 17 Jan 2000 19:13:46 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 974DC13383; Tue, 18 Jan 2000 02:19:17 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <3883B185.7484996E@tm.ee>
Date: Tue, 18 Jan 2000 02:19:17 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Foreign keys: unexpected result from ALTER TABLE... ADD
CONSTRAINT...
References: <Pine.GSO.4.02A.10001171401260.8593-100000@Puma.DoCS.UU.SE>
<200001171406.OAA14889@linda.lfix.co.uk>
<20873.948124695@sss.pgh.pa.us> <38835F06.9C0B7FDF@debis.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jan Wieck wrote:
With CREATE CONSTRAINT TRIGGER (which I added first so someone could
already work on pg_dump - what noone does up to now :-( ), you can
specify deferrability and initial deferred state for the trigger. And
it correctly sets up the PK<->FK tables relationships in pg_trigger,
so that DROPping one of them removes all the triggers using it from
the other one. Needless to say that dropping and recreating a PK
table looses all the references! But dropping and recreating the
referencing tables therefore doesn't put the PK table into an
unusable state.
Oracle solves these kind of problems by having a CREATE OR REPLACE command,
that keeps as much of related objects as possible if there is already an
object by that name.
Does anyone know if it is ANSI SQL ?
--------------------------
Hannu
From bouncefilter Mon Jan 17 19:57:08 2000
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 TAA66510
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 19:56:56 -0500 (EST) (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 JAA02180 for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 09:56:53 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: How to ignore system indexes
Date: Tue, 18 Jan 2000 10:02:31 +0900
Message-ID: <001001bf614f$b242dbe0$2801007e@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 V5.00.2314.1300
Importance: Normal
Hi all,
I'm trying to implement REINDEX command.
Because the command is to repair system indexes,we
coundn't rely on system indexes when we call the
command.
I added locally an option of standalone postgres to ignore
system indexes and am add/changing ignore_system_
indexes stuff.
There are fairly many places using system indexes.
Probably I would be able to change them.
But is it preferable or possible to force other developers
to take ignore_system_indexes mode into account ?
Is it better to limit changes required for REINDEX
command ?
Comments ? Better ideas ?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Jan 17 21:05:09 2000
Received: from www.geocrawler.com (sourceforge.net [209.81.8.17])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA82803
for <pgsql-hackers@hub.org>; Mon, 17 Jan 2000 21:04:53 -0500 (EST)
(envelope-from nobody@www.geocrawler.com)
Received: (from nobody@localhost)
by www.geocrawler.com (8.9.3/8.9.3) id SAA10563;
Mon, 17 Jan 2000 18:04:55 -0800
Date: Mon, 17 Jan 2000 18:04:55 -0800
Message-Id: <200001180204.SAA10563@www.geocrawler.com>
To: pgsql-hackers@hub.org
Subject: plpgsql -record in -record out
From: "Adam Walczykiewicz" <archiver@db.geocrawler.com>
Reply-To: "Adam Walczykiewicz" <adam.walczykiewicz@multiuser.com.pl>
This message was sent from Geocrawler.com by "Adam Walczykiewicz" <adam.walczykiewicz@multiuser.com.pl>
Be sure to reply to that address.
Hi
Is possible to send a record(more than 8 fields)
to the function
in plpgsql then modified it and send back???
I've tried:...
CREATE FUNCTION modrec(rec_client) RETURNS
rec_client)
(...)
and call it
SELECT modrec
(name::rec_client,age::rec_client..._)
but it failed. The only method I found
is to send record as a text and exctract it inside
,modified and send back as a text.
Thanks for any sugesstions.
Adam
Geocrawler.com - The Knowledge Archive
From bouncefilter Mon Jan 17 21:25:19 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA85494;
Mon, 17 Jan 2000 21:24:45 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id CAA15189;
Tue, 18 Jan 2000 02:29:54 GMT
Sender: lockhart@hub.org
Message-ID: <3883D022.8386A215@alumni.caltech.edu>
Date: Tue, 18 Jan 2000 02:29: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: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Tom Lane <tgl@hub.org>, committers@postgreSQL.org,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql/src/include/catalog (pg_type.h)
References: <200001171617.LAA29019@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
We are going to internally move everything to the more standard ANSI
names, right, or do we give preference to the older types?
Well, that could be up for discussion. The "internal" abstime/reltime
types are direct copies of Unix system time, which most systems
support at a fundamental level. Moving to timestamp/interval will
double the storage size of those fields, with no increase in
functionality afaik.
Peter brought up changing one field to timestamp; that would have the
benefit of being able to specify times past y2038.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 17 21:54:11 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA92151
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 21:53:36 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id CAA15526;
Tue, 18 Jan 2000 02:58:18 GMT
Sender: lockhart@hub.org
Message-ID: <3883D6CA.CDE9FEF5@alumni.caltech.edu>
Date: Tue, 18 Jan 2000 02:58: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: Alfred Perlstein <bright@wintelcom.net>
CC: admin <admin@wtbwts.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org,
scrappy@hub.org
Subject: Re: FreeBSD postgresql doc-HOWTO was: Re: [HACKERS] Revised
nonblocking patches + quasi docs
References: <20000114111430.A824@fw.wintelcom.net>
<Pine.BSF.4.10.10001141401330.84869-100000@server.b0x.com>
<20000114120516.D824@fw.wintelcom.net>
<387FE733.49D9A679@alumni.caltech.edu>
<20000115060608.K508@fw.wintelcom.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
setup my enviornment... (this ought to be mentioned in the docs)
But afaik this isn't required for me to run on postgresql.org, a
FreeBSD machine set up by Marc/scrappy.
then in the pgsql/doc/src dir:
gmake all \
HSTYLE=/usr/local/share/sgml/docbook/dsssl/modular/html/ \
PSTYLE=/usr/local/share/sgml/docbook/dsssl/modular/print/ \
That works too. I usually just set up a src/Makefile.custom with the
two lines defining HSTYLE and PSTYLE.
Btw, does anyone have some fixes so gvim doesn't barf doing syntax
highlighting on these sgml files?
Let us know when you find them; I can help with emacs...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 17 22:05:09 2000
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 WAA96772
for <pgsql-hackers@postgresql.org>;
Mon, 17 Jan 2000 22:04:23 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id MAA23940
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 12:04:21 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id MAA31649
for <pgsql-hackers@postgresql.org>; Tue, 18 Jan 2000 12:04:21 +0900
To: pgsql-hackers@postgresql.org
Subject: multi-byte support broken in current
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000118120421G.t-ishii@sra.co.jp>
Date: Tue, 18 Jan 2000 12:04:21 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 5
The multi-byte support in current had been broken for a while due to
missing compile flag in Makefile.global.in. I have just committed fix
for the problem, and should be ok now.
--
Tatsuo Ishii
From bouncefilter Mon Jan 17 23:17:10 2000
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 XAA10618
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 23:16:34 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA07081;
Mon, 17 Jan 2000 23:04:12 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001180404.XAA07081@candle.pha.pa.us>
Subject: Re: [HACKERS] How to ignore system indexes
In-Reply-To: <001001bf614f$b242dbe0$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 18, 2000 10:02:31 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 17 Jan 2000 23:04:12 -0500 (EST)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I'm trying to implement REINDEX command.
Because the command is to repair system indexes,we
coundn't rely on system indexes when we call the
command.I added locally an option of standalone postgres to ignore
system indexes and am add/changing ignore_system_
indexes stuff.There are fairly many places using system indexes.
Probably I would be able to change them.
But is it preferable or possible to force other developers
to take ignore_system_indexes mode into account ?
Is it better to limit changes required for REINDEX
command ?
One solution is to use pg_upgrade. It allows an initdb and recreate of
all tables without reload.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 17 23:51:10 2000
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 XAA17845
for <pgsql-hackers@postgreSQL.org>;
Mon, 17 Jan 2000 23:50:57 -0500 (EST) (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 NAA02299; Tue, 18 Jan 2000 13:50:28 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] How to ignore system indexes
Date: Tue, 18 Jan 2000 13:56:04 +0900
Message-ID: <001901bf6170$531b6940$2801007e@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: <200001180404.XAA07081@candle.pha.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]I'm trying to implement REINDEX command.
Because the command is to repair system indexes,we
coundn't rely on system indexes when we call the
command.I added locally an option of standalone postgres to ignore
system indexes and am add/changing ignore_system_
indexes stuff.There are fairly many places using system indexes.
Probably I would be able to change them.
But is it preferable or possible to force other developers
to take ignore_system_indexes mode into account ?
Is it better to limit changes required for REINDEX
command ?One solution is to use pg_upgrade. It allows an initdb and recreate of
all tables without reload.
--
Isn't it a big charge to execute pg_upgrade for a huge database ?
I have never used pg_upgrade.
Is pg_upgrade available now ?
Is pg_upgrade reliable ?
My design is as follows.
postgres -P test /* I'm using -P as a new option temporarily */.
reindex database test; (all system indexes of a db)
reindex table pg_class; (all indexes of a system table)
reindex index pg_index_indexrelid_index; (a system index)
If we could ignore system indexes,it won't be difficult to implement
REINDEX command itself..
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Tue Jan 18 00:10:11 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA24181
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 00:09:25 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA08441;
Tue, 18 Jan 2000 00:09:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001180509.AAA08441@candle.pha.pa.us>
Subject: Re: [HACKERS] How to ignore system indexes
In-Reply-To: <001901bf6170$531b6940$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 18, 2000 01:56:04 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 18 Jan 2000 00:09:14 -0500 (EST)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
One solution is to use pg_upgrade. It allows an initdb and recreate of
all tables without reload.
--Isn't it a big charge to execute pg_upgrade for a huge database ?
I have never used pg_upgrade.
Is pg_upgrade available now ?
Is pg_upgrade reliable ?
It has been around since 6.3? It allows initdb, recreates the tables,
then moves the data files back into place. There is even a manual page.
My design is as follows.
postgres -P test /* I'm using -P as a new option temporarily */.
reindex database test; (all system indexes of a db)
reindex table pg_class; (all indexes of a system table)
reindex index pg_index_indexrelid_index; (a system index)If we could ignore system indexes,it won't be difficult to implement
REINDEX command itself..
Not sure how to find all those places.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 00:11:11 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA24376
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 00:10:21 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA29140;
Tue, 18 Jan 2000 00:09:58 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] How to ignore system indexes
In-reply-to: <001001bf614f$b242dbe0$2801007e@tpf.co.jp>
References: <001001bf614f$b242dbe0$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Tue, 18 Jan 2000 10:02:31 +0900"
Date: Tue, 18 Jan 2000 00:09:58 -0500
Message-ID: <29137.948172198@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
There are fairly many places using system indexes.
Probably I would be able to change them.
But is it preferable or possible to force other developers
to take ignore_system_indexes mode into account ?
Is it really necessary to touch all those places?
Seems to me that if a person needs to rebuild system indexes,
he would be firing up a standalone backend and running
REINDEX --- and darn little else. As long as none of the
support code required by REINDEX insists on using an index,
it doesn't matter what the rest of the system requires.
You might even think about doing the reindex in bootstrap mode,
though I don't know if that would be easier or harder.
regards, tom lane
From bouncefilter Tue Jan 18 00:48:14 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA36380
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 00:48:09 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA08878;
Tue, 18 Jan 2000 00:47:58 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001180547.AAA08878@candle.pha.pa.us>
Subject: Re: [HACKERS] How to ignore system indexes
In-Reply-To: <001c01bf6177$94d73ec0$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 18, 2000 02:48:01 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 18 Jan 2000 00:47:58 -0500 (EST)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]One solution is to use pg_upgrade. It allows an initdb and
recreate of
all tables without reload.
--Isn't it a big charge to execute pg_upgrade for a huge database ?
I have never used pg_upgrade.
Is pg_upgrade available now ?
Is pg_upgrade reliable ?It has been around since 6.3? It allows initdb, recreates the tables,
then moves the data files back into place. There is even a manual page.I know the command but does 6.5 have it ?
Sure, but it is disabled in 6.5 because we changed the binary table
format from 6.4 to 6.5. However, I have already recommended people use
it who have broken system indexes, and it worked.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 00:43:11 2000
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 AAA35817
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 00:42:33 -0500 (EST) (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 OAA02340; Tue, 18 Jan 2000 14:42:24 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] How to ignore system indexes
Date: Tue, 18 Jan 2000 14:48:01 +0900
Message-ID: <001c01bf6177$94d73ec0$2801007e@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: <200001180509.AAA08441@candle.pha.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]One solution is to use pg_upgrade. It allows an initdb and
recreate of
all tables without reload.
--Isn't it a big charge to execute pg_upgrade for a huge database ?
I have never used pg_upgrade.
Is pg_upgrade available now ?
Is pg_upgrade reliable ?It has been around since 6.3? It allows initdb, recreates the tables,
then moves the data files back into place. There is even a manual page.
I know the command but does 6.5 have it ?
My design is as follows.
postgres -P test /* I'm using -P as a new option temporarily */.
reindex database test; (all system indexes of a db)
reindex table pg_class; (all indexes of a system table)
reindex index pg_index_indexrelid_index; (a system index)If we could ignore system indexes,it won't be difficult to implement
REINDEX command itself..Not sure how to find all those places.
I would only change the stuff required for REINDEX command,
though I know almost all those places.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Tue Jan 18 00:43:11 2000
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 AAA35822
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 00:42:49 -0500 (EST) (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 OAA02341; Tue, 18 Jan 2000 14:42:42 +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] How to ignore system indexes
Date: Tue, 18 Jan 2000 14:48:19 +0900
Message-ID: <001d01bf6177$9f6593a0$2801007e@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
In-Reply-To: <29137.948172198@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
There are fairly many places using system indexes.
Probably I would be able to change them.
But is it preferable or possible to force other developers
to take ignore_system_indexes mode into account ?Is it really necessary to touch all those places?
Seems to me that if a person needs to rebuild system indexes,
he would be firing up a standalone backend and running
REINDEX --- and darn little else. As long as none of the
support code required by REINDEX insists on using an index,
it doesn't matter what the rest of the system requires.
OK,I would limit changes only for REINDEX command.
You might even think about doing the reindex in bootstrap mode,
though I don't know if that would be easier or harder.
Yes,bootstrap mode is a natural selection. Jan has already tried
it and there was a problem of time quliafication. I don't know it is
a big obstacle or not. I prefer standalone postgres because
there's a possibility to call various SQL commands together
with REINDEX command.
Of cource,time qualification is no longer a problem in standalone
postgres.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Tue Jan 18 00:52:16 2000
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 AAA36840
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 00:51:17 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id OAA07515
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 14:51:15 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id OAA01812
for <pgsql-hackers@postgresql.org>; Tue, 18 Jan 2000 14:51:14 +0900
To: pgsql-hackers@postgresql.org
Subject: pg_proc.h changed
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000118145114M.t-ishii@sra.co.jp>
Date: Tue, 18 Jan 2000 14:51:14 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 23
Hi,
I have added two built-in functions:
pg_char_to_encoding() -- convert encoding string to encoding id
pg_encoding_to_char() -- convert encoding id to encoding string
Main purpose for this is to allow psql -l to print encoding names
rather than encoding ids (sample output from psql shown below) in a
multibyte enabled installation.
List of databases
Database | Owner | Encoding
------------+---------+----------
regression | t-ishii | EUC_JP
template1 | t-ishii | EUC_JP
test | t-ishii | EUC_JP
(3 rows)
This is much more "user friendly" IMHO.
initdb required.
--
Tatsuo Ishii
From bouncefilter Tue Jan 18 01:01:10 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA38137;
Tue, 18 Jan 2000 00:59:49 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA09212;
Tue, 18 Jan 2000 00:53:50 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001180553.AAA09212@candle.pha.pa.us>
Subject: Re: [PATCHES] docs done Re: [HACKERS] LIBPQ patches ...
In-Reply-To: <20000116160043.I508@fw.wintelcom.net> from Alfred Perlstein at
"Jan 16, 2000 04:00:45 pm"
To: Alfred Perlstein <bright@wintelcom.net>
Date: Tue, 18 Jan 2000 00:53:50 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Don Baccus <dhogaza@pacifier.com>,
pgsql-hackers@postgreSQL.org, pgsql-patches@postgreSQL.org,
Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Applied.
* Tom Lane <tgl@sss.pgh.pa.us> [000109 08:18] wrote:
Don Baccus <dhogaza@pacifier.com> writes:
At 05:27 PM 1/8/00 -0500, Tom Lane wrote:
I also object strongly to the lack of documentation.
... I know there are some folks who aren't native-english speakers, so
perhaps you don't want to require that the implementor of such patches
provide the final documentation wording. But the information should
be there and spelled out in a form that can be very easily moved to
the docs.Oh, absolutely. Thomas, our master of the docs, has always had the
policy of "give me some words, I'll take care of formatting and
editing..."I was probably too harsh on Alfred last night, since in fact his code
was fairly well commented, and some minimal doco could have been
extracted from the routine headers. But on a change like this, I think
some paragraphs of coherent high-level explanation are needed: what it
does, when and why you'd use it. I didn't see that anywhere...Here's the revised patch, it includes sgml docs and changes to
ensure that old style connections behave the way they are expected
to:Index: doc/src/sgml/libpq.sgml =================================================================== RCS file: /home/pgcvs/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.25 diff -u -c -r1.25 libpq.sgml *** doc/src/sgml/libpq.sgml 2000/01/14 05:33:13 1.25 --- doc/src/sgml/libpq.sgml 2000/01/17 03:40:30 *************** *** 377,382 **** --- 377,386 ---- changed in the future. </para> <para> + These functions leave the socket in a non-blocking state as if + <function>PQsetnonblocking</function> had been called. + </para> + <para> These functions are not thread-safe. </para> </listitem> *************** *** 1168,1175 **** --- 1172,1229 ---- Applications that do not like these limitations can instead use the underlying functions that <function>PQexec</function> is built from: <function>PQsendQuery</function> and <function>PQgetResult</function>. + </para> + <para> + Older programs that used this functionality as well as + <function>PQputline</function> and <function>PQputnbytes</function> + could block waiting to send data to the backend, to + address that issue, the function <function>PQsetnonblocking</function> + was added. + </para> + <para> + Old applications can neglect to use <function>PQsetnonblocking</function> + and get the older potentially blocking behavior. Newer programs can use + <function>PQsetnonblocking</function> to achieve a completely non-blocking + connection to the backend.<itemizedlist> + <listitem> + <para> + <function>PQsetnonblocking</function> Sets the state of the connection + to non-blocking. + <synopsis> + int PQsetnonblocking(PGconn *conn) + </synopsis> + this function will ensure that calls to + <function>PQputline</function>, <function>PQputnbytes</function>, + <function>PQsendQuery</function> and <function>PQendcopy</function> + will not block but instead return an error if they need to be called + again. + </para> + <para> + When a database connection has been set to non-blocking mode and + <function>PQexec</function> is called, it will temporarily set the state + of the connection to blocking until the <function>PQexec</function> + completes. + </para> + <para> + More of libpq is expected to be made safe for + <function>PQsetnonblocking</function> functionality in the near future. + </para> + </listitem> + + <listitem> + <para> + <function>PQisnonblocking</function> + Returns the blocking status of the database connection. + <synopsis> + int PQisnonblocking(const PGconn *conn) + </synopsis> + Returns TRUE if the connection is set to non-blocking mode, + FALSE if blocking. + </para> + </listitem> + <listitem> <para> <function>PQsendQuery</function> *************** *** 1267,1286 ****<listitem>
<para>
<function>PQsocket</function>
Obtain the file descriptor number for the backend connection socket.
! A valid descriptor will be >= 0; a result of -1 indicates that
no backend connection is currently open.
<synopsis>
int PQsocket(const PGconn *conn);
</synopsis>
<function>PQsocket</function> should be used to obtain the backend socket descriptor
in preparation for executing <function>select</function>(2). This allows an
! application to wait for either backend responses or other conditions.
If the result of <function>select</function>(2) indicates that data can be read from
the backend socket, then <function>PQconsumeInput</function> should be called to read the
data; after which, <function>PQisBusy</function>, <function>PQgetResult</function>,
and/or <function>PQnotifies</function> can be used to process the response.
</para>
</listitem>--- 1321,1363 ----<listitem> <para> + <function>PQflush</function> Attempt to flush any data queued to the backend, + returns 0 if successful (or if the send queue is empty) or EOF if it failed for + some reason. + <synopsis> + int PQflush(PGconn *conn); + </synopsis> + <function>PQflush</function> needs to be called on a non-blocking connection + before calling <function>select</function> to determine if a responce has + arrived. If 0 is returned it ensures that there is no data queued to the + backend that has not actually been sent. Only applications that have used + <function>PQsetnonblocking</function> have a need for this. + </para> + </listitem> + + <listitem> + <para> <function>PQsocket</function> Obtain the file descriptor number for the backend connection socket. ! A valid descriptor will be >= 0; a result of -1 indicates that no backend connection is currently open. <synopsis> int PQsocket(const PGconn *conn); </synopsis> <function>PQsocket</function> should be used to obtain the backend socket descriptor in preparation for executing <function>select</function>(2). This allows an ! application using a blocking connection to wait for either backend responses or ! other conditions. If the result of <function>select</function>(2) indicates that data can be read from the backend socket, then <function>PQconsumeInput</function> should be called to read the data; after which, <function>PQisBusy</function>, <function>PQgetResult</function>, and/or <function>PQnotifies</function> can be used to process the response. + </para> + <para> + Non-blocking connections (that have used <function>PQsetnonblocking</function>) + should not use <function>select</function> until <function>PQflush</function> + has returned 0 indicating that there is no buffered data waiting to be sent + to the backend. </para> </listitem>Index: src/interfaces/libpq/fe-connect.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-connect.c,v retrieving revision 1.111 diff -u -c -r1.111 fe-connect.c *** src/interfaces/libpq/fe-connect.c 2000/01/16 21:18:52 1.111 --- src/interfaces/libpq/fe-connect.c 2000/01/17 02:35:56 *************** *** 594,624 **** return 0; }- - /* ---------- - * connectMakeNonblocking - - * Make a connection non-blocking. - * Returns 1 if successful, 0 if not. - * ---------- - */ - static int - connectMakeNonblocking(PGconn *conn) - { - #ifndef WIN32 - if (fcntl(conn->sock, F_SETFL, O_NONBLOCK) < 0) - #else - if (ioctlsocket(conn->sock, FIONBIO, &on) != 0) - #endif - { - printfPQExpBuffer(&conn->errorMessage, - "connectMakeNonblocking -- fcntl() failed: errno=%d\n%s\n", - errno, strerror(errno)); - return 0; - } - - return 1; - } - /* ---------- * connectNoDelay - * Sets the TCP_NODELAY socket option. --- 594,599 ---- *************** *** 789,795 **** * Ewan Mellor <eem21@cam.ac.uk>. * ---------- */ #if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL) ! if (!connectMakeNonblocking(conn)) goto connect_errReturn; #endif--- 764,770 ---- * Ewan Mellor <eem21@cam.ac.uk>. * ---------- */ #if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL) ! if (PQsetnonblocking(conn, TRUE) != 0) goto connect_errReturn; #endif***************
*** 898,904 ****
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (!connectMakeNonblocking(conn))
goto connect_errReturn;
#endif--- 873,879 ---- /* This makes the connection non-blocking, for all those cases which forced us not to do it above. */ #if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL) ! if (PQsetnonblocking(conn, TRUE) != 0) goto connect_errReturn; #endif*************** *** 1720,1725 **** --- 1695,1701 ---- conn->inBuffer = (char *) malloc(conn->inBufSize); conn->outBufSize = 8 * 1024; conn->outBuffer = (char *) malloc(conn->outBufSize); + conn->nonblocking = FALSE; initPQExpBuffer(&conn->errorMessage); initPQExpBuffer(&conn->workBuffer); if (conn->inBuffer == NULL || *************** *** 1830,1835 **** --- 1806,1812 ---- conn->lobjfuncs = NULL; conn->inStart = conn->inCursor = conn->inEnd = 0; conn->outCount = 0; + conn->nonblocking = FALSE;}
Index: src/interfaces/libpq/fe-exec.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-exec.c,v retrieving revision 1.86 diff -u -c -r1.86 fe-exec.c *** src/interfaces/libpq/fe-exec.c 1999/11/11 00:10:14 1.86 --- src/interfaces/libpq/fe-exec.c 2000/01/14 22:47:07 *************** *** 13,18 **** --- 13,19 ---- */ #include <errno.h> #include <ctype.h> + #include <fcntl.h>#include "postgres.h"
#include "libpq-fe.h"
***************
*** 24,30 ****
#include <unistd.h>
#endif- /* keep this in same order as ExecStatusType in libpq-fe.h */ const char *const pgresStatus[] = { "PGRES_EMPTY_QUERY", --- 25,30 ---- *************** *** 514,526 **** conn->curTuple = NULL;/* send the query to the backend; */
! /* the frontend-backend protocol uses 'Q' to designate queries */
! if (pqPutnchar("Q", 1, conn) ||
! pqPuts(query, conn) ||
! pqFlush(conn))
{
! handleSendFailure(conn);
! return 0;
}/* OK, it's launched! */ --- 514,566 ---- conn->curTuple = NULL;/* send the query to the backend; */
!
! /*
! * in order to guarantee that we don't send a partial query
! * where we would become out of sync with the backend and/or
! * block during a non-blocking connection we must first flush
! * the send buffer before sending more data
! *
! * an alternative is to implement 'queue reservations' where
! * we are able to roll up a transaction
! * (the 'Q' along with our query) and make sure we have
! * enough space for it all in the send buffer.
! */
! if (pqIsnonblocking(conn))
{
! /*
! * the buffer must have emptied completely before we allow
! * a new query to be buffered
! */
! if (pqFlush(conn))
! return 0;
! /* 'Q' == queries */
! /* XXX: if we fail here we really ought to not block */
! if (pqPutnchar("Q", 1, conn) ||
! pqPuts(query, conn))
! {
! handleSendFailure(conn);
! return 0;
! }
! /*
! * give the data a push, ignore the return value as
! * ConsumeInput() will do any aditional flushing if needed
! */
! (void) pqFlush(conn);
! }
! else
! {
! /*
! * the frontend-backend protocol uses 'Q' to
! * designate queries
! */
! if (pqPutnchar("Q", 1, conn) ||
! pqPuts(query, conn) ||
! pqFlush(conn))
! {
! handleSendFailure(conn);
! return 0;
! }
}/* OK, it's launched! */ *************** *** 574,580 **** --- 614,630 ---- * we will NOT block waiting for more input. */ if (pqReadData(conn) < 0) + { + /* + * for non-blocking connections + * try to flush the send-queue otherwise we may never get a + * responce for something that may not have already been sent + * because it's in our write buffer! + */ + if (pqIsnonblocking(conn)) + (void) pqFlush(conn); return 0; + } /* Parsing of the data waits till later. */ return 1; } *************** *** 1088,1093 **** --- 1138,1153 ---- { PGresult *result; PGresult *lastResult; + bool savedblocking; + + /* + * we assume anyone calling PQexec wants blocking behaviour, + * we force the blocking status of the connection to blocking + * for the duration of this function and restore it on return + */ + savedblocking = pqIsnonblocking(conn); + if (PQsetnonblocking(conn, FALSE) == -1) + return NULL;/*
* Silently discard any prior query result that application didn't
***************
*** 1102,1115 ****
PQclear(result);
printfPQExpBuffer(&conn->errorMessage,
"PQexec: you gotta get out of a COPY state yourself.\n");
! return NULL;
}
PQclear(result);
}/* OK to send the message */
if (!PQsendQuery(conn, query))
! return NULL;/* * For backwards compatibility, return the last result if there are --- 1162,1176 ---- PQclear(result); printfPQExpBuffer(&conn->errorMessage, "PQexec: you gotta get out of a COPY state yourself.\n"); ! /* restore blocking status */ ! goto errout; } PQclear(result); }/* OK to send the message */
if (!PQsendQuery(conn, query))
! goto errout; /* restore blocking status *//* * For backwards compatibility, return the last result if there are *************** *** 1142,1148 **** --- 1203,1217 ---- result->resultStatus == PGRES_COPY_OUT) break; } + + if (PQsetnonblocking(conn, savedblocking) == -1) + return NULL; return lastResult; + + errout: + if (PQsetnonblocking(conn, savedblocking) == -1) + return NULL; + return NULL; }***************
*** 1431,1438 ****
"PQendcopy() -- I don't think there's a copy in progress.\n");
return 1;
}! (void) pqFlush(conn); /* make sure no data is waiting to be sent */
/* Return to active duty */ conn->asyncStatus = PGASYNC_BUSY; --- 1500,1516 ---- "PQendcopy() -- I don't think there's a copy in progress.\n"); return 1; } + + /* + * make sure no data is waiting to be sent, + * abort if we are non-blocking and the flush fails + */ + if (pqFlush(conn) && pqIsnonblocking(conn)) + return (1);! /* non blocking connections may have to abort at this point. */
! if (pqIsnonblocking(conn) && PQisBusy(conn))
! return (1);/* Return to active duty */ conn->asyncStatus = PGASYNC_BUSY; *************** *** 2025,2028 **** --- 2103,2192 ---- return 1; else return 0; + } + + /* PQsetnonblocking: + sets the PGconn's database connection non-blocking if the arg is TRUE + or makes it non-blocking if the arg is FALSE, this will not protect + you from PQexec(), you'll only be safe when using the non-blocking + API + Needs to be called only on a connected database connection. + */ + + int + PQsetnonblocking(PGconn *conn, int arg) + { + int fcntlarg; + + arg = (arg == TRUE) ? 1 : 0; + /* early out if the socket is already in the state requested */ + if (arg == conn->nonblocking) + return (0); + + /* + * to guarantee constancy for flushing/query/result-polling behavior + * we need to flush the send queue at this point in order to guarantee + * proper behavior. + * this is ok because either they are making a transition + * _from_ or _to_ blocking mode, either way we can block them. + */ + /* if we are going from blocking to non-blocking flush here */ + if (!pqIsnonblocking(conn) && pqFlush(conn)) + return (-1); + + + #ifdef USE_SSL + if (conn->ssl) + { + printfPQExpBuffer(&conn->errorMessage, + "PQsetnonblocking() -- not supported when using SSL\n"); + return (-1); + } + #endif /* USE_SSL */ + + #ifndef WIN32 + fcntlarg = fcntl(conn->sock, F_GETFL, 0); + if (fcntlarg == -1) + return (-1); + + if ((arg == TRUE && + fcntl(conn->sock, F_SETFL, fcntlarg | O_NONBLOCK) == -1) || + (arg == FALSE && + fcntl(conn->sock, F_SETFL, fcntlarg & ~O_NONBLOCK) == -1)) + #else + fcntlarg = arg; + if (ioctlsocket(conn->sock, FIONBIO, &fcntlarg) != 0) + #endif + { + printfPQExpBuffer(&conn->errorMessage, + "PQsetblocking() -- unable to set nonblocking status to %s\n", + arg == TRUE ? "TRUE" : "FALSE"); + return (-1); + } + + conn->nonblocking = arg; + + /* if we are going from non-blocking to blocking flush here */ + if (pqIsnonblocking(conn) && pqFlush(conn)) + return (-1); + + return (0); + } + + /* return the blocking status of the database connection, TRUE == nonblocking, + FALSE == blocking + */ + int + PQisnonblocking(const PGconn *conn) + { + + return (pqIsnonblocking(conn)); + } + + /* try to force data out, really only useful for non-blocking users */ + int + PQflush(PGconn *conn) + { + + return (pqFlush(conn)); } Index: src/interfaces/libpq/fe-misc.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-misc.c,v retrieving revision 1.33 diff -u -c -r1.33 fe-misc.c *** src/interfaces/libpq/fe-misc.c 1999/11/30 03:08:19 1.33 --- src/interfaces/libpq/fe-misc.c 2000/01/12 03:12:14 *************** *** 86,91 **** --- 86,122 ---- { size_t avail = Max(conn->outBufSize - conn->outCount, 0);+ /* + * if we are non-blocking and the send queue is too full to buffer this + * request then try to flush some and return an error + */ + if (pqIsnonblocking(conn) && nbytes > avail && pqFlush(conn)) + { + /* + * even if the flush failed we may still have written some + * data, recalculate the size of the send-queue relative + * to the amount we have to send, we may be able to queue it + * afterall even though it's not sent to the database it's + * ok, any routines that check the data coming from the + * database better call pqFlush() anyway. + */ + if (nbytes > Max(conn->outBufSize - conn->outCount, 0)) + { + printfPQExpBuffer(&conn->errorMessage, + "pqPutBytes -- pqFlush couldn't flush enough" + " data: space available: %d, space needed %d\n", + Max(conn->outBufSize - conn->outCount, 0), nbytes); + return EOF; + } + } + + /* + * is the amount of data to be sent is larger than the size of the + * output buffer then we must flush it to make more room. + * + * the code above will make sure the loop conditional is never + * true for non-blocking connections + */ while (nbytes > avail) { memcpy(conn->outBuffer + conn->outCount, s, avail); *************** *** 548,553 **** --- 579,592 ---- return EOF; }+ /* + * don't try to send zero data, allows us to use this function + * without too much worry about overhead + */ + if (len == 0) + return (0); + + /* while there's still data to send */ while (len > 0) { /* Prevent being SIGPIPEd if backend has closed the connection. */ *************** *** 556,561 **** --- 595,601 ---- #endifint sent; + #ifdef USE_SSL if (conn->ssl) sent = SSL_write(conn->ssl, ptr, len); *************** *** 585,590 **** --- 625,632 ---- case EWOULDBLOCK: break; #endif + case EINTR: + continue;case EPIPE:
#ifdef ECONNRESET
***************
*** 616,628 ****
ptr += sent;
len -= sent;
}
if (len > 0)
{
/* We didn't send it all, wait till we can send more */- /* At first glance this looks as though it should block. I think - * that it will be OK though, as long as the socket is - * non-blocking. */ if (pqWait(FALSE, TRUE, conn)) return EOF; } --- 658,688 ---- ptr += sent; len -= sent; } + if (len > 0) { /* We didn't send it all, wait till we can send more */ + + /* + * if the socket is in non-blocking mode we may need + * to abort here + */ + #ifdef USE_SSL + /* can't do anything for our SSL users yet */ + if (conn->ssl == NULL) + { + #endif + if (pqIsnonblocking(conn)) + { + /* shift the contents of the buffer */ + memmove(conn->outBuffer, ptr, len); + conn->outCount = len; + return EOF; + } + #ifdef USE_SSL + } + #endifif (pqWait(FALSE, TRUE, conn)) return EOF; } Index: src/interfaces/libpq/libpq-fe.h =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-fe.h,v retrieving revision 1.55 diff -u -c -r1.55 libpq-fe.h *** src/interfaces/libpq/libpq-fe.h 2000/01/15 05:37:21 1.55 --- src/interfaces/libpq/libpq-fe.h 2000/01/17 02:35:56 *************** *** 263,268 **** --- 263,275 ---- extern int PQputnbytes(PGconn *conn, const char *buffer, int nbytes); extern int PQendcopy(PGconn *conn);+ /* Set blocking/nonblocking connection to the backend */ + extern int PQsetnonblocking(PGconn *conn, int arg); + extern int PQisnonblocking(const PGconn *conn); + + /* Force the write buffer to be written (or at least try) */ + extern int PQflush(PGconn *conn); + /* * "Fast path" interface --- not really recommended for application * use Index: src/interfaces/libpq/libpq-int.h =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/libpq-int.h,v retrieving revision 1.16 diff -u -c -r1.16 libpq-int.h *** src/interfaces/libpq/libpq-int.h 2000/01/15 05:37:21 1.16 --- src/interfaces/libpq/libpq-int.h 2000/01/17 02:35:56 *************** *** 214,219 **** --- 214,222 ---- int inEnd; /* offset to first position after avail * data */+ int nonblocking; /* whether this connection is using a blocking + * socket to the backend or not */ + /* Buffer for data not yet sent to backend */ char *outBuffer; /* currently allocated buffer */ int outBufSize; /* allocated size of buffer */ *************** *** 299,303 **** --- 302,312 ---- #define strerror(A) (sys_errlist[(A)]) #endif /* sunos4 */ #endif /* !strerror */ + + /* + * this is so that we can check is a connection is non-blocking internally + * without the overhead of a function call + */ + #define pqIsnonblocking(conn) (conn->nonblocking)#endif /* LIBPQ_INT_H */
************
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 01:54:11 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA49913
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 01:53:19 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id BAA82341
for pgsql-hackers@postgresql.org; Tue, 18 Jan 2000 01:40:23 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: mr_hopkins@earthlink.net (Micheal H.)
X-Newsgroups: comp.databases.postgresql.hackers
Subject: jdbc question
Message-ID: <38840aea.7517991@news.earthlink.net>
X-Newsreader: Forte Free Agent 1.11/32.235
Lines: 52
X-Complaints-To: abuse@earthlink.net
X-Trace: newsread1.prod.itd.earthlink.net 948177567 209.179.129.226 (Mon,
17 Jan 2000 22:39:27 PST)
Organization: EarthLink Network, Inc.
X-ELN-Date: Mon Jan 17 22:39:27 2000
Date: Tue, 18 Jan 2000 06:39:28 GMT
To: pgsql-hackers@postgresql.org
I got the pgsql jdbc drivers and their names were jdbc6.5-1.1.jar and
jdbc6.5-1.2.jar. OK everything I've read refers to postgresql.jar
I've tried adding the location of the files to the class path as well
as renaming them, one by one to postgresql.jar and adding the file
name to the classpath. Nothing seems to work. Now I'm not a java pro
so perhaps something's wrong with my code or my understanding of what
to do with the .jar file(s). Here's the code.....It compiles but
never gets past "Failed to load postgresql driver". Would greatly
appreacieate any assistance........
import java.sql.*;
public class SelectApp {
public static void main(String args[]) {
String url = "jdbc:postgresql://gina/testdb";
try {
Class.forName("postgresql.Driver");
}
catch(Exception e) {
System.out.println("Failed to load postgresql
driver.");
return;
}
System.out.println("Loaded driver successfully");
try {
Connection con =
DriverManager.getConnection(url, "", "");
Statement select = con.createStatement();
ResultSet result = select.executeQuery("select
* from cities");
System.out.println("Got results:");
while(result.next()) { // process results one
row at a time
int key = result.getInt(1);
String val = result.getString(2);
System.out.println("key = " + key);
System.out.println("val = " + val);
}
select.close();
con.close();
}
catch(Exception e) {
e.printStackTrace();
}
}
}
From bouncefilter Tue Jan 18 01:54:10 2000
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 BAA49939
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 01:53:37 -0500 (EST) (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 PAA02376; Tue, 18 Jan 2000 15:52:46 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] How to ignore system indexes
Date: Tue, 18 Jan 2000 15:58:23 +0900
Message-ID: <002001bf6181$69795ce0$2801007e@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: <200001180547.AAA08878@candle.pha.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
[Charset iso-8859-1 unsupported, filtering to ASCII...]
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]One solution is to use pg_upgrade. It allows an initdb and
recreate of
all tables without reload.
--Isn't it a big charge to execute pg_upgrade for a huge database ?
I have never used pg_upgrade.
Is pg_upgrade available now ?
Is pg_upgrade reliable ?It has been around since 6.3? It allows initdb, recreates the tables,
then moves the data files back into place. There is even amanual page.
I know the command but does 6.5 have it ?
Sure, but it is disabled in 6.5 because we changed the binary table
format from 6.4 to 6.5. However, I have already recommended people use
it who have broken system indexes, and it worked.
It seems pg_upgrade is too complicated to recover system indexes.
In addtion,could pg_upgrade/pg_dump/vacuum etc ... work even when
a critical system index is broken ?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp.
From bouncefilter Tue Jan 18 02:32:10 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA60571
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 02:31:43 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA29582;
Tue, 18 Jan 2000 02:31:26 -0500 (EST)
To: Mike Mascari <mascarm@mascari.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Is pg_dump still broken?
In-reply-to: <3883B101.E0593FE7@mascari.com>
References: <3883B101.E0593FE7@mascari.com>
Comments: In-reply-to Mike Mascari <mascarm@mascari.com>
message dated "Mon, 17 Jan 2000 19:17:05 -0500"
Date: Tue, 18 Jan 2000 02:31:26 -0500
Message-ID: <29579.948180686@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Mike Mascari <mascarm@mascari.com> writes:
Note the second parameter to autoinc() -- it should be 'myseq', not
'myfieldmyseq'. I suspect someone isn't doing a resetPQExpBuffer()
somewhere. Can anyone confirm this?
Yup, you're right. I note the procedure name isn't getting quoted,
either. Fix committed.
regards, tom lane
From bouncefilter Tue Jan 18 04:14:12 2000
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 EAA83798
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 04:13:17 -0500 (EST) (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 SAA02433 for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 18:13:15 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: Index recreation in vacuum
Date: Tue, 18 Jan 2000 18:18:52 +0900
Message-ID: <002101bf6195$09437360$2801007e@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 V5.00.2314.1300
Importance: Normal
Hi all,
I'm trying to implement REINDEX command.
REINDEX operation itself is available everywhere and
I've thought about applying it to VACUUM.
.
My plan is as follows.
Add a new option to force index recreation in vacuum
and if index recreation is specified.
1) invalidate all indexes of the target table
2) vacuum the target table(heap table only)
3) internal commit and truncation
4) recreate and validate all indexes of the table.
The problem is how to invalidate/validate indexes.
Of cource natural way is to drop/create indexes but the
definition of indexes would be lost in case of abort/crash.
Now I'm inclined to use relhasindex of pg_class to
validate/invalidate indexes of a table at once.
I remember many people have referred to index recreation
in vacuum.
Any comment would be greatly appreciated.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Tue Jan 18 08:04:16 2000
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA33557
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 08:03:17 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9C1460.dip0.t-ipconnect.de
(root@p3E9C1460.dip0.t-ipconnect.de [62.156.20.96])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id OAA31866
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 14:04:51 +0100 (CET)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id NAA01525
for pgsql-hackers@postgresql.org; Tue, 18 Jan 2000 13:58:40 +0100
Date: Tue, 18 Jan 2000 13:58:40 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Cannot compile psql
Message-ID: <20000118135840.A1519@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
I just tried recompiling the latest source for the first time in weeks, but
it appears I cannot compile pgsql. My source should be up-to-date since I
use cvsup everytime I go online. But during compile I get:
gcc -I../../interfaces/libpq -I../../include -I../../backend -O2 -Wall -Wmissing-prototypes -c -o common.o common.c
In file included from ../../include/postgres.h:41,
from ../../interfaces/libpq/pqsignal.h:20,
from common.c:23:
../../include/utils/mcxt.h:25: syntax error before `MemoryContext'
make[2]: *** [common.o] Error 1
Is this a problem on my site?
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Tue Jan 18 08:04:16 2000
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA33567
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 08:03:25 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9C1460.dip0.t-ipconnect.de
(root@p3E9C1460.dip0.t-ipconnect.de [62.156.20.96])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id OAA31867
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 14:04:51 +0100 (CET)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id OAA01606
for pgsql-hackers@postgresql.org; Tue, 18 Jan 2000 14:01:14 +0100
Date: Tue, 18 Jan 2000 14:01:14 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: FETCH syntax
Message-ID: <20000118140114.A1599@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
I've just send a patch to gram.y to allow FETCH without FROM/IN to the
patches list. Since I do not have the complete source checked out I cannot
commit it myself.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Tue Jan 18 08:55:16 2000
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 IAA43587;
Tue, 18 Jan 2000 08:54:35 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id WAA08170;
Tue, 18 Jan 2000 22:54:34 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id WAA06824;
Tue, 18 Jan 2000 22:54:34 +0900
To: meskes@postgresql.org
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cannot compile psql
In-Reply-To: Your message of "Tue, 18 Jan 2000 13:58:40 +0100"
<20000118135840.A1519@fam-meskes.de>
References: <20000118135840.A1519@fam-meskes.de>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000118225433V.t-ishii@sra.co.jp>
Date: Tue, 18 Jan 2000 22:54:33 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 23
I just tried recompiling the latest source for the first time in weeks, but
it appears I cannot compile pgsql. My source should be up-to-date since I
use cvsup everytime I go online. But during compile I get:gcc -I../../interfaces/libpq -I../../include -I../../backend -O2 -Wall -Wmissing-prototypes -c -o common.o common.c
In file included from ../../include/postgres.h:41,
from ../../interfaces/libpq/pqsignal.h:20,
from common.c:23:
../../include/utils/mcxt.h:25: syntax error before `MemoryContext'
make[2]: *** [common.o] Error 1Is this a problem on my site?
I assume you have configured --with-mb=something *before*
make. --with-mb does not seem to work anymore. Try:
make distclean
./configure --enable-multibyte[=something]
Seems we have to warn if --with-mb is used, otherwise multibyte users
would complain about it.
--
Tatsuo Ishii
From bouncefilter Tue Jan 18 09:02:15 2000
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 JAA47884;
Tue, 18 Jan 2000 09:01:33 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id XAA08444;
Tue, 18 Jan 2000 23:01:31 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id XAA06898;
Tue, 18 Jan 2000 23:01:31 +0900
To: meskes@postgresql.org
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cannot compile psql
In-Reply-To: Your message of "Tue, 18 Jan 2000 13:58:40 +0100"
<20000118135840.A1519@fam-meskes.de>
References: <20000118135840.A1519@fam-meskes.de>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000118230130H.t-ishii@sra.co.jp>
Date: Tue, 18 Jan 2000 23:01:30 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 12
I just tried recompiling the latest source for the first time in weeks, but
it appears I cannot compile pgsql. My source should be up-to-date since I
use cvsup everytime I go online. But during compile I get:
Sorry, my previous mail was wrong.
You are compiling psql, right? I do not see any problem on my Linux
box (based on RH 5.2). Maybe make distclean and re-configure would
help.
--
Tatsuo Ishii
From bouncefilter Tue Jan 18 09:09:15 2000
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA48865
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 09:08:49 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (sfcabop1.nettuno.it [193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id PAA10082;
Tue, 18 Jan 2000 15:08:44 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 12AaET-0000jx-00; Tue, 18 Jan 2000 15:07:45 +0000
Message-ID: <38847472.DC3C84AA@sferacarta.com>
Date: Tue, 18 Jan 2000 15:10:58 +0100
From: Jose Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] date/time problem in v6.5.3 and 7.0.0 ...
References: <Pine.BSF.4.21.0001142201470.46499-100000@thelab.hub.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
The Hermit Hacker wrote:
I can add days to now(), but not subtract?
=====================================
template1=> select now() + '30 days';
?column?
------------------------------
Sun Feb 13 22:00:33 2000 AST
(1 row)template1=> select now() - '30 days';
ERROR: Unable to identify an operator '-' for types 'timestamp' and 'unknown'
You will have to retype this query using an explicit cast
template1=> select version();
version
---------------------------------------------------------------------
PostgreSQL 7.0.0 on i386-unknown-freebsd4.0, compiled by gcc 2.95.2
(1 row)Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org************
Try using standard names (TIMESTAMP instead of now() and INTERVA) as in:
hygea=> select current_timestamp + interval '30 day';
?column?
--------------------------
17/02/2000 16:00:28.00 CET
(1 row)
hygea=> select current_timestamp - interval '30 day';
?column?
--------------------------
19/12/1999 16:00:44.00 CET
(1 row)
hygea=> select now() - '30 day';
ERROR: Unable to identify an operator '-' for types 'timestamp' and 'unknown'
You will have to retype this query using an explicit cast
Jos���
From bouncefilter Tue Jan 18 09:32:16 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA54702
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 09:31:58 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA16622;
Tue, 18 Jan 2000 14:40:27 GMT
Sender: lockhart@hub.org
Message-ID: <38847B5B.DA4BEE00@alumni.caltech.edu>
Date: Tue, 18 Jan 2000 14:40:27 +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: Jose Soares <jose@sferacarta.com>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] date/time problem in v6.5.3 and 7.0.0 ...
References: <Pine.BSF.4.21.0001142201470.46499-100000@thelab.hub.org>
<38847472.DC3C84AA@sferacarta.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I can add days to now(), but not subtract?
The problem is that it is meaningful to subtract two absolute times,
giving a delta time as a result, *and* it is meaningful to subtract a
delta time from an absolute time, giving another absolute time as a
result.
So your unspecified field could be either one, and Postgres can't
decide what it should be for you ;)
The error message is intentionally vague, since by the time the
message is printed the parser has lost track of whether there were
zero candidates or too many candidates.
- Thomas
=====================================
template1=> select now() + '30 days';
?column?
------------------------------
Sun Feb 13 22:00:33 2000 AST
(1 row)template1=> select now() - '30 days';
ERROR: Unable to identify an operator '-' for types 'timestamp' and 'unknown'
You will have to retype this query using an explicit cast
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Jan 18 12:59:21 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id MAA08773
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 12:59:04 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 27233 invoked from network); 18 Jan 2000 17:58:59 -0000
Received: from h-62.96.159.219.host.de.colt.net (root@62.96.159.219)
by pille.addcom.de with SMTP; 18 Jan 2000 17:58:59 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id QAA02655
for pgsql-hackers@postgresql.org; Tue, 18 Jan 2000 16:27:03 +0100
Date: Tue, 18 Jan 2000 16:27:03 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: patches list
Message-ID: <20000118162703.A2645@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
It seems I'm not allowed to send to the patches list. Does it make sense to
have this list being closed?
----- Forwarded message from owner-pgsql-patches@postgreSQL.org -----
From: owner-pgsql-patches@postgreSQL.org
Date: Tue, 18 Jan 2000 08:04:35 -0500 (EST)
To: owner-pgsql-patches@postgreSQL.org, meskes@postgreSQL.org
Subject: BOUNCE pgsql-patches@postgreSQL.org: Non-member submission from [Michael Meskes <meskes@postgresql.org>]
From bouncefilter Tue Jan 18 08:04:25 2000
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA33568
for <pgsql-patches@postgresql.org>; Tue, 18 Jan 2000 08:03:25 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9C1460.dip0.t-ipconnect.de (root@p3E9C1460.dip0.t-ipconnect.de [62.156.20.96])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id OAA31906
for <pgsql-patches@postgresql.org>; Tue, 18 Jan 2000 14:05:08 +0100 (CET)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id OAA01598
for pgsql-patches@postgresql.org; Tue, 18 Jan 2000 14:00:17 +0100
Date: Tue, 18 Jan 2000 14:00:17 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Patches <pgsql-patches@postgresql.org>
Subject: FETCH syntax
Message-ID: <20000118140017.A1586@fam-meskes.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="AhhlLboLdkugWU4S"
User-Agent: Mutt/1.0i
...
----- End forwarded message -----
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Tue Jan 18 12:59:23 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id MAA08779
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 12:59:10 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 27308 invoked from network); 18 Jan 2000 17:59:08 -0000
Received: from h-62.96.159.219.host.de.colt.net (root@62.96.159.219)
by pille.addcom.de with SMTP; 18 Jan 2000 17:59:08 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id QAA02676
for pgsql-hackers@postgresql.org; Tue, 18 Jan 2000 16:29:29 +0100
Date: Tue, 18 Jan 2000 16:29:29 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: FETCH syntax
Message-ID: <20000118162929.A2664@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="6c2NcOVqGQ03X4Wi"
User-Agent: Mutt/1.0i
--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Since this patch is not big I send it here instead. I do not have the
complete source checked out so I cannot commit it myself.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
--6c2NcOVqGQ03X4Wi
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="fetch.patch.gz"
Content-Transfer-Encoding: base64
H4sICMiGhDgAA2ZldGNoLnBhdGNoAO1XbW/bNhD+LP+KQ+EBiSXVkh3ntQmSZgqazi+F43Tb
J4GRaVmYRKoSlc5r899HipQsuY7hbN66DzOQkLo73t3z8HQiTdMEP0HR68VrmgS+NskwvEcE
7GOwO6cH9mnXho5lWQ1d15VhzaYrbGxlc3kJpt07NI5Al8PlZQM0bYoYekApdgmKsAHI83Ca
uhFmczp1vRBl6aqUPzKWSHvhgRulqQEBmeLflRf5f5YRTwlmQVhG8P3ERYnPFjFuQMP8QUzg
TcqSC02jMXMDHkGMMU0YClUcfZ2ZiI7C0B3FBgwQm4tRqGQgMctI8CmTaY5idp/iwkQlfRdj
L0DhOAvxGIeIBZTwnHKqTk5yqvJBUiXjfg7Y3PVovCggV+Lkrh9x8kBT9YAIChd/cKAq/wdK
Q4zIhUwiS1KaVEgIHlF4oQnn7jRIiAFTPHOFSjrjMuyJHA1IcEQfsdSV5GxY/txSkKA8GmYR
1+FHTJgBHo0iPlFriycvlPutHpG/VM3Ick7jigO/oPP40M75lKMgFFrib5e/tqDyBjNvfsci
dqrdOJPrd3XmYCbU7px+diNEFquF1tC/Wf7s0llCIzcgebHL8vgiB630AS0C5xCh3/CQTvFe
Kd8/U5bBDPaaHTg/h7HTv5rcfnT2FV1HRwZ/c/V8cmiVFag9qZGYF8vMzqHZOVsqeIoDkSEX
d88aeiGWOEW6QtOraIJUlASXzlCY4kLRbHLJnsgcWvtESZ/E8BUUOZso0SUl+taU6FVK3oC1
rySFjzo0U0BeKqpkvL26/unnq/GPhf5JjZiDW+OzuvRmNK6uXGGzs/RYkl1n9aCyDauswlpW
QfozOavaYPTReWG9imXfFOrutqFWmSvUCfUqYU/Lolotz1KxJNR+tjoP/k51FsW5Axo2l8eW
YLo7APPdQXT+MggJI6/tf76ZdmXnkE30xDbsrviIH1hG7+jfaqKT8b2zzcbmjPzfQbfpoJLS
jQ10bZHtvgPsppO9rET+033sRVC+O4S1XWwLCLzIzsTpsvZx5kdEmYR8ISBfW+QFHPfWliDO
VMVLp1WNyjexsCo+xzWrQlhaXb29G/XvJ466y1g9dZk5Ng7LNohD6u8NR5Pba8d4lX9l2sUy
IJRBmsWCPMzvY1kaEL+M8qpoufXYuUyeZKDdcgYfJr+22tpaxO2WuJugLOTb3oaS3pVueApw
61GSsqqPpi1ASlh2N+/v/H7bE6dlCYyD7/e1Wlwrj2hBxK9eqQwC/OIILItDnBYZfIWh88uk
vtIuGf0wvh2N60oz127Aa4u4CmgVp7lyjBNAh/nLUQXaKb3fjEeDUr3OYH344X2/r0x4Ias2
ImPxupZu+SRnvsF97PLX+BNgLwhovRAAAA==
--6c2NcOVqGQ03X4Wi--
From bouncefilter Tue Jan 18 12:59:20 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id MAA08772
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 12:59:03 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 27216 invoked from network); 18 Jan 2000 17:58:56 -0000
Received: from h-62.96.159.219.host.de.colt.net (root@62.96.159.219)
by pille.addcom.de with SMTP; 18 Jan 2000 17:58:56 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id QAA02695
for pgsql-hackers@postgresql.org; Tue, 18 Jan 2000 16:31:06 +0100
Date: Tue, 18 Jan 2000 16:31:06 +0100
From: Michael Meskes <meskes@postgresql.org>
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cannot compile psql
Message-ID: <20000118163106.B2679@fam-meskes.de>
Mail-Followup-To: pgsql-hackers@postgresql.org
References: <20000118135840.A1519@fam-meskes.de>
<20000118230130H.t-ishii@sra.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <20000118230130H.t-ishii@sra.co.jp>;
from t-ishii@sra.co.jp on Tue, Jan 18, 2000 at 11:01:30PM +0900
On Tue, Jan 18, 2000 at 11:01:30PM +0900, Tatsuo Ishii wrote:
Sorry, my previous mail was wrong.
No problem.
You are compiling psql, right? I do not see any problem on my Linux
Yes, as part of the complete source tree.
box (based on RH 5.2). Maybe make distclean and re-configure would
help.
I will try it and tell you. :-)
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Tue Jan 18 10:52:16 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA77765;
Tue, 18 Jan 2000 10:51:50 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA00374;
Tue, 18 Jan 2000 10:51:48 -0500 (EST)
To: Michael Meskes <meskes@postgresql.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Cannot compile psql
In-reply-to: <20000118135840.A1519@fam-meskes.de>
References: <20000118135840.A1519@fam-meskes.de>
Comments: In-reply-to Michael Meskes <meskes@postgresql.org>
message dated "Tue, 18 Jan 2000 13:58:40 +0100"
Date: Tue, 18 Jan 2000 10:51:48 -0500
Message-ID: <371.948210708@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Meskes <meskes@postgresql.org> writes:
../../include/utils/mcxt.h:25: syntax error before `MemoryContext'
That line reads
extern DLLIMPORT MemoryContext CurrentMemoryContext;
I'll bet you are trying to compile with a Windoze-oriented config.h
that causes DLLIMPORT to expand to something nonempty. Try
reconfiguring.
regards, tom lane
From bouncefilter Tue Jan 18 11:16:16 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA84716
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 11:15:16 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id RAA215806
for <pgsql-hackers@postgreSQL.org>; Tue, 18 Jan 2000 17:15:10 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALNQAA>; Tue, 18 Jan 2000 17:15:08 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC20E@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] [hackers]development suggestion needed (filepath as
symlink)
Date: Tue, 18 Jan 2000 17:15:06 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
Yes, that's about the sum of it. Why not the links? I think
that it's an elegant way of designing the whole thing.
The only problem with symlinks is, that it does not solve the
"too many files in one directory to give optimal performance"
problem for those that have tons of tables.
Andreas
From bouncefilter Tue Jan 18 12:59:19 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id MAA08750
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 12:58:56 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 27178 invoked from network); 18 Jan 2000 17:58:51 -0000
Received: from h-62.96.159.219.host.de.colt.net (root@62.96.159.219)
by pille.addcom.de with SMTP; 18 Jan 2000 17:58:51 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id RAA00370
for pgsql-hackers@postgresql.org; Tue, 18 Jan 2000 17:52:25 +0100
Date: Tue, 18 Jan 2000 17:52:25 +0100
From: Michael Meskes <meskes@postgresql.org>
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cannot compile psql
Message-ID: <20000118175225.A361@fam-meskes.de>
Mail-Followup-To: pgsql-hackers@postgresql.org
References: <20000118135840.A1519@fam-meskes.de>
<20000118230130H.t-ishii@sra.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <20000118230130H.t-ishii@sra.co.jp>;
from t-ishii@sra.co.jp on Tue, Jan 18, 2000 at 11:01:30PM +0900
On Tue, Jan 18, 2000 at 11:01:30PM +0900, Tatsuo Ishii wrote:
You are compiling psql, right? I do not see any problem on my Linux
box (based on RH 5.2). Maybe make distclean and re-configure would
help.
Unfortunately no. It didn't help.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Tue Jan 18 12:31:23 2000
Received: from sirius.edu.sollentuna.se (sirius.edu.sollentuna.se
[195.67.128.12]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA01283
for <hackers@postgreSQL.org>; Tue, 18 Jan 2000 12:30:28 -0500 (EST)
(envelope-from mha@sollentuna.net)
Received: by sirius.edu.sollentuna.se with Internet Mail Service (5.5.2448.0)
id <WJ7XSLMY>; Tue, 18 Jan 2000 18:30:17 +0100
Message-ID:
<215896B6B5E1CF11BC5600805FFEA821026E11B9@sirius.edu.sollentuna.se>
From: Magnus Hagander <mha@sollentuna.net>
To: "'Peter Eisentraut'" <peter_e@gmx.net>, hackers@postgreSQL.org
Subject: RE: [HACKERS] Help from a Windows programmer needed!
Date: Tue, 18 Jan 2000 18:30:17 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
The Windows makefile for psql is still in prehistoric state. Is there
someone who uses Visual C++ or whatever it was that could update it?
Otherwise psql will no longer be supported on non-cygwin systems!
Ok. I've done this, patch to follow on the patches list within a couple of
minutes.
//Magnus
From bouncefilter Tue Jan 18 13:09:28 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA14133
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 13:08:40 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA02731;
Tue, 18 Jan 2000 13:08:21 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001181808.NAA02731@candle.pha.pa.us>
Subject: Re: [HACKERS] How to ignore system indexes
In-Reply-To: <002001bf6181$69795ce0$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 18, 2000 03:58:23 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 18 Jan 2000 13:08:21 -0500 (EST)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sure, but it is disabled in 6.5 because we changed the binary table
format from 6.4 to 6.5. However, I have already recommended people use
it who have broken system indexes, and it worked.It seems pg_upgrade is too complicated to recover system indexes.
In addtion,could pg_upgrade/pg_dump/vacuum etc ... work even when
a critical system index is broken ?
Yes, pg_dumpall -s may not work with broken system indexes.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 13:32:27 2000
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 NAA27289
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 13:31:46 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA02988;
Tue, 18 Jan 2000 13:21:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001181821.NAA02988@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <002101bf6195$09437360$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 18, 2000 06:18:52 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 18 Jan 2000 13:21:37 -0500 (EST)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
Hi all,
I'm trying to implement REINDEX command.
REINDEX operation itself is available everywhere and
I've thought about applying it to VACUUM.
That is a good idea. Vacuuming of indexes can be very slow.
.
My plan is as follows.Add a new option to force index recreation in vacuum
and if index recreation is specified.
Couldn't we auto-recreate indexes based on the number of tuples moved by
vacuum, or do we update indexes as we move them?
1) invalidate all indexes of the target table
2) vacuum the target table(heap table only)
3) internal commit and truncation
4) recreate and validate all indexes of the table.The problem is how to invalidate/validate indexes.
Of cource natural way is to drop/create indexes but the
definition of indexes would be lost in case of abort/crash.
My idea would be to create a new index that is a random index name.
Then, do rename(), which is an atomic OS operation putting the new index
file in place of the old name. Seems that would work well.
Now I'm inclined to use relhasindex of pg_class to
validate/invalidate indexes of a table at once.
There are a few calls to CatalogIndexInsert() that know the system table they
are using and know it has indexes, so it does not check that field. You
could add cases for that.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 13:25:19 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id NAA24019
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 13:24:20 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 1827 invoked by uid 1001); 18 Jan 2000 18:23:59 -0000
Date: Tue, 18 Jan 2000 13:23:59 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Michael Meskes <meskes@postgresql.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] patches list
In-Reply-To: <20000118162703.A2645@fam-meskes.de>
Message-ID: <Pine.BSF.4.05.10001181323180.1099-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 18 Jan 2000, Michael Meskes wrote:
It seems I'm not allowed to send to the patches list. Does it make sense to
have this list being closed?
subscribe to pgsql-loophole and you'll be able to post to any of the
lists.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Tue Jan 18 13:32:26 2000
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 NAA27097
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 13:31:39 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA05099;
Tue, 18 Jan 2000 13:26:23 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001181826.NAA05099@candle.pha.pa.us>
Subject: Re: [HACKERS] [hackers]development suggestion needed (filepath as
symlink)
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC20E@sdexcsrv1.f000.d0188.sd.spardat.at>
from Zeugswetter Andreas SB at "Jan 18, 2000 05:15:06 pm"
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
Date: Tue, 18 Jan 2000 13:26:23 -0500 (EST)
CC: "'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Yes, that's about the sum of it. Why not the links? I think
that it's an elegant way of designing the whole thing.The only problem with symlinks is, that it does not solve the
"too many files in one directory to give optimal performance"
problem for those that have tons of tables.Andreas
Is that really a problem on modern operating systems? We could actually
hash the file names into directory buckets and access them that way, and
have one directory that old symlinks to the hashed files.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 14:07:19 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA39022
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 14:06:43 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA24860;
Tue, 18 Jan 2000 15:04:00 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 18 Jan 2000 15:04:00 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] [hackers]development suggestion needed (filepath as
symlink)
In-Reply-To: <200001181826.NAA05099@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001181500440.23487-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 18 Jan 2000, Bruce Momjian wrote:
Yes, that's about the sum of it. Why not the links? I think
that it's an elegant way of designing the whole thing.The only problem with symlinks is, that it does not solve the
"too many files in one directory to give optimal performance"
problem for those that have tons of tables.Andreas
Is that really a problem on modern operating systems? We could actually
hash the file names into directory buckets and access them that way, and
have one directory that old symlinks to the hashed files.
Personally, except in *exceptional* circumstances, I hate symlinks...that
was one of my first projects whenI started working at th eocal University,
was to get rid of the garbage "revision control" system they had for
packages installed on the system ...
IMHO, there have been several methods of doing this, some easier then
others, wihtout having to use symlinks for them ... can we *please* avoid
using them?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Jan 18 14:08:21 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA39320;
Tue, 18 Jan 2000 14:08:12 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA14719;
Tue, 18 Jan 2000 14:07:52 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001181907.OAA14719@candle.pha.pa.us>
Subject: Re: [HACKERS] FETCH syntax
In-Reply-To: <20000118162929.A2664@fam-meskes.de> from Michael Meskes at "Jan
18, 2000 04:29:29 pm"
To: Michael Meskes <meskes@postgreSQL.org>
Date: Tue, 18 Jan 2000 14:07:52 -0500 (EST)
CC: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Applied.
Since this patch is not big I send it here instead. I do not have the
complete source checked out so I cannot commit it myself.Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
[Attachment, skipping...]
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 14:10:18 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA39743;
Tue, 18 Jan 2000 14:10:14 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA14974;
Tue, 18 Jan 2000 14:09:47 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001181909.OAA14974@candle.pha.pa.us>
Subject: Re: [PATCHES] docs done Re: [HACKERS] LIBPQ patches ...
In-Reply-To: <20000116160043.I508@fw.wintelcom.net> from Alfred Perlstein at
"Jan 16, 2000 04:00:45 pm"
To: Alfred Perlstein <bright@wintelcom.net>
Date: Tue, 18 Jan 2000 14:09:46 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Don Baccus <dhogaza@pacifier.com>,
pgsql-hackers@postgreSQL.org, pgsql-patches@postgreSQL.org,
Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Applied, or did I already say that?
* Tom Lane <tgl@sss.pgh.pa.us> [000109 08:18] wrote:
Don Baccus <dhogaza@pacifier.com> writes:
At 05:27 PM 1/8/00 -0500, Tom Lane wrote:
I also object strongly to the lack of documentation.
... I know there are some folks who aren't native-english speakers, so
perhaps you don't want to require that the implementor of such patches
provide the final documentation wording. But the information should
be there and spelled out in a form that can be very easily moved to
the docs.Oh, absolutely. Thomas, our master of the docs, has always had the
policy of "give me some words, I'll take care of formatting and
editing..."I was probably too harsh on Alfred last night, since in fact his code
was fairly well commented, and some minimal doco could have been
extracted from the routine headers. But on a change like this, I think
some paragraphs of coherent high-level explanation are needed: what it
does, when and why you'd use it. I didn't see that anywhere...Here's the revised patch, it includes sgml docs and changes to
ensure that old style connections behave the way they are expected
to:
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 14:33:20 2000
Received: from relay.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA47158
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 14:32:52 -0500 (EST) (envelope-from dms@wplus.net)
X-Real-To: pgsql-hackers@postgreSQL.org
Received: from wplus.net (ppdms.dialup.wplus.net [195.131.52.71])
by relay.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id WAA70643;
Tue, 18 Jan 2000 22:28:15 +0300 (MSK)
Message-ID: <3884BF59.81329C8E@wplus.net>
Date: Tue, 18 Jan 2000 22:30:34 +0300
From: Dmitry Samersoff <dms@wplus.net>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: ru,en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Index recreation in vacuum
References: <200001181821.NAA02988@candle.pha.pa.us>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
The problem is how to invalidate/validate indexes.
Of cource natural way is to drop/create indexes but the
definition of indexes would be lost in case of abort/crash.My idea would be to create a new index that is a random index name.
Then, do rename(), which is an atomic OS operation putting the new index
file in place of the old name. Seems that would work well.
Yes, but it can cause disk space problem for very large indices.
Moreover, you need firts unlink old index file than do rename(),
it is not atomic.
May be better way is to create tmp file containing index description,
undestandable for vacuum.
--
Dmitry Samersoff, DM\S
dms@wplus.net http://devnull.wplus.net
* There will come soft rains
From bouncefilter Tue Jan 18 14:37:20 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA48355
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 14:37:05 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA16687;
Tue, 18 Jan 2000 14:36:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001181936.OAA16687@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <3884BF59.81329C8E@wplus.net> from Dmitry Samersoff at "Jan 18,
2000 10:30:34 pm"
To: Dmitry Samersoff <dms@wplus.net>
Date: Tue, 18 Jan 2000 14:36:37 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset koi8-r unsupported, filtering to ASCII...]
Bruce Momjian wrote:
The problem is how to invalidate/validate indexes.
Of cource natural way is to drop/create indexes but the
definition of indexes would be lost in case of abort/crash.My idea would be to create a new index that is a random index name.
Then, do rename(), which is an atomic OS operation putting the new index
file in place of the old name. Seems that would work well.Yes, but it can cause disk space problem for very large indices.
Well, one would hope you have enough disk space free for that.
Moreover, you need firts unlink old index file than do rename(),
it is not atomic.
rename - change the name of a file
int
rename(const char *from, const char *to);
...
Rename() causes the link named from to be renamed as to. If to exists, it
is first removed. Both from and to must be of the same type (that is,
both directories or both non-directories), and must reside on the same
file system.
May be better way is to create tmp file containing index description,
undestandable for vacuum.
That would work too. pg_dump call for just the index, and run it though
a pg_exec_desc() call to recreate.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 14:38:22 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA48450
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 14:37:44 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA16702;
Tue, 18 Jan 2000 14:37:31 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001181937.OAA16702@candle.pha.pa.us>
Subject: Re: [PATCHES] docs done Re: [HACKERS] LIBPQ patches ...
In-Reply-To: <20000118115303.F8736@fw.wintelcom.net> from Alfred Perlstein at
"Jan 18, 2000 11:53:04 am"
To: Alfred Perlstein <bright@wintelcom.net>
Date: Tue, 18 Jan 2000 14:37:31 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
* Bruce Momjian <pgman@candle.pha.pa.us> [000118 11:49] wrote:
Applied, or did I already say that?
Just one mail was sent, but I cc'd patches and hackers as well as
yourself on the message, sorry for duplicates, but since the mailing
contained my revised patch I sent to -patches as well.I'll be a bit less zealous in the future. :)
No, that is fine. I usually catch that, but I was not sure in this
case. Seems I only sent out one, and had not already sent it. It is
good to hit multiple lists with something that has been discussed this
much.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 14:43:20 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA49406
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 14:42:49 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA17153;
Tue, 18 Jan 2000 14:42:24 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001181942.OAA17153@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <3884BF59.81329C8E@wplus.net> from Dmitry Samersoff at "Jan 18,
2000 10:30:34 pm"
To: Dmitry Samersoff <dms@wplus.net>
Date: Tue, 18 Jan 2000 14:42:24 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
My idea would be to create a new index that is a random index name.
Then, do rename(), which is an atomic OS operation putting the new index
file in place of the old name. Seems that would work well.Yes, but it can cause disk space problem for very large indices.
Moreover, you need firts unlink old index file than do rename(),
it is not atomic.May be better way is to create tmp file containing index description,
undestandable for vacuum.
The beauty of doing a temp index while keeping the old one is that you
can recover right away, and maybe allow the old index to be used while
you vacuum?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 14:30:21 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA43254
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 14:30:01 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id LAA18553;
Tue, 18 Jan 2000 11:53:04 -0800 (PST)
Date: Tue, 18 Jan 2000 11:53:04 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [PATCHES] docs done Re: [HACKERS] LIBPQ patches ...
Message-ID: <20000118115303.F8736@fw.wintelcom.net>
References: <20000116160043.I508@fw.wintelcom.net>
<200001181909.OAA14974@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200001181909.OAA14974@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Tue, Jan 18, 2000 at 02:09:46PM
-0500
* Bruce Momjian <pgman@candle.pha.pa.us> [000118 11:49] wrote:
Applied, or did I already say that?
Just one mail was sent, but I cc'd patches and hackers as well as
yourself on the message, sorry for duplicates, but since the mailing
contained my revised patch I sent to -patches as well.
I'll be a bit less zealous in the future. :)
sorry,
-Alfred
From bouncefilter Tue Jan 18 15:27:19 2000
Received: from relay.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA59214
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 15:26:25 -0500 (EST) (envelope-from dms@wplus.net)
X-Real-To: pgsql-hackers@postgreSQL.org
Received: from wplus.net (ppdms.dialup.wplus.net [195.131.52.71])
by relay.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id XAA78376;
Tue, 18 Jan 2000 23:22:25 +0300 (MSK)
Message-ID: <3884CC0C.B6DF19A2@wplus.net>
Date: Tue, 18 Jan 2000 23:24:44 +0300
From: Dmitry Samersoff <dms@wplus.net>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: ru,en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Index recreation in vacuum
References: <200001181936.OAA16687@candle.pha.pa.us>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
[Charset koi8-r unsupported, filtering to ASCII...]
Bruce Momjian wrote:
The problem is how to invalidate/validate indexes.
Of cource natural way is to drop/create indexes but the
definition of indexes would be lost in case of abort/crash.My idea would be to create a new index that is a random index name.
Then, do rename(), which is an atomic OS operation putting the new index
file in place of the old name. Seems that would work well.Yes, but it can cause disk space problem for very large indices.
Well, one would hope you have enough disk space free for that.
At least noticed by vacuum
...
Rename() causes the link named from to be renamed as to. If to exists, it
is first removed. Both from and to must be of the same type (that is,
Ok. I agree.
--
Dmitry Samersoff, DM\S
dms@wplus.net http://devnull.wplus.net
* there will come soft rains
From bouncefilter Tue Jan 18 15:46:19 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA65246
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 15:46:07 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA26658;
Tue, 18 Jan 2000 15:45:47 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001182045.PAA26658@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <3884CC0C.B6DF19A2@wplus.net> from Dmitry Samersoff at "Jan 18,
2000 11:24:44 pm"
To: Dmitry Samersoff <dms@wplus.net>
Date: Tue, 18 Jan 2000 15:45:47 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Well, one would hope you have enough disk space free for that.
At least noticed by vacuum
...
Rename() causes the link named from to be renamed as to. If to exists, it
is first removed. Both from and to must be of the same type (that is,Ok. I agree.
You start to think this way when you start looking for conflicting
situations.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 17:35:20 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA97628
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 17:34:35 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA02249;
Tue, 18 Jan 2000 17:32:56 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Dmitry Samersoff <dms@wplus.net>, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Index recreation in vacuum
In-reply-to: <200001181942.OAA17153@candle.pha.pa.us>
References: <200001181942.OAA17153@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Tue, 18 Jan 2000 14:42:24 -0500"
Date: Tue, 18 Jan 2000 17:32:55 -0500
Message-ID: <2246.948234775@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
The beauty of doing a temp index while keeping the old one is that you
can recover right away, and maybe allow the old index to be used while
you vacuum?
Huh? You've got the whole table locked exclusively for the duration
of the vacuum anyway.
In fact, the instant that vacuum does its internal commit, the old index
contents are actually *wrong*, and there is no possible value in keeping
them after that. Might as well blow them away and recover the disk
space for use in constructing the new indexes.
Also, I agree with Dmitry's concern about peak disk space usage. If
we are rebuilding large btree indexes then we are going to see about a
2X-normal peak usage anyway, for the sort temp file and the new index.
Making it 3X instead is just asking for trouble. Especially since,
if you fail to rebuild the index, you are left with a corrupt index;
it doesn't agree with the vacuumed table...
regards, tom lane
From bouncefilter Tue Jan 18 17:37:22 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA98130
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 17:36:49 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA04121;
Tue, 18 Jan 2000 17:36:23 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001182236.RAA04121@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <2246.948234775@sss.pgh.pa.us> from Tom Lane at "Jan 18,
2000 05:32:55 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 18 Jan 2000 17:36:23 -0500 (EST)
CC: Dmitry Samersoff <dms@wplus.net>, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
The beauty of doing a temp index while keeping the old one is that you
can recover right away, and maybe allow the old index to be used while
you vacuum?Huh? You've got the whole table locked exclusively for the duration
of the vacuum anyway.In fact, the instant that vacuum does its internal commit, the old index
contents are actually *wrong*, and there is no possible value in keeping
them after that. Might as well blow them away and recover the disk
space for use in constructing the new indexes.
Oh, I thought the vacuum itself would use the index during processing.
Also, I agree with Dmitry's concern about peak disk space usage. If
we are rebuilding large btree indexes then we are going to see about a
2X-normal peak usage anyway, for the sort temp file and the new index.
Making it 3X instead is just asking for trouble. Especially since,
if you fail to rebuild the index, you are left with a corrupt index;
it doesn't agree with the vacuumed table...
OK.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 18:22:29 2000
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 SAA10409
for <hackers@postgresql.org>; Tue, 18 Jan 2000 18:21:49 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64471 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S194588AbQARXVH>;
Wed, 19 Jan 2000 00:21:07 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12Ai2k-0003l4-00; Wed, 19 Jan 2000 00:28:10 +0100
Date: Wed, 19 Jan 2000 00:28:10 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] TODO list
In-Reply-To: <38834477.B9037F62@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0001180146070.411-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-17, Thomas Lockhart mentioned:
The official SQL data types are "timestamp" and
"interval", right? Everything else will eventually be an alias or
phased out or whatever?No (at least I haven't proposed that). abstime stays as a 4-byte
internal system time type. timestamp and interval become full-featured
date/time types, stealing all of the datetime and timespan code, and
the latter two become synonyms for timestamp and interval.
Okay, so we have "timestamp" and "interval" as offical types, a few
"datetime" sort of things as aliases for backwards compatibility, and
"abstime" as a more or less internal type with less precision and storage
requirements. Sounds clear to me. This also puts the original TODO item
into a much clearer light.
I've been itching to change the pg_shadow.valuntil column to timestamp
anyway, I suppose that would be a step in the right direction, or not?At the moment, there are *no* 8-byte date/time types in the system
tables. This would be the first instance of that, and I'm not sure we
should introduce it in just one place.Has abstime been a problem here?
No. I just thought this could be done, but in view of your explanation I
am now wiser ...
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 18 18:22:27 2000
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 SAA10492
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 18:22:19 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61136 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S219157AbQARXVe>;
Wed, 19 Jan 2000 00:21:34 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12Ai2t-0003lK-00; Wed, 19 Jan 2000 00:28:19 +0100
Date: Wed, 19 Jan 2000 00:28:19 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Oliver Elphick <olly@lfix.co.uk>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] psql and COPY
In-Reply-To: <200001171434.OAA01785@linda.lfix.co.uk>
Message-ID: <Pine.LNX.4.21.0001180209140.411-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Sorry, I can't reproduce that. I have not been able to keep up with RI, so
I can't seem to get a usable table configuration together. I used a script
COPY three FROM STDIN;
\N
\.
on a table CREATE TABLE three ( a int4 not null ) and it gives me proper
error messages either way.
I am almost tempted to say that this is a bug in COPY, though I sure don't
want to blame anyone before I see it. Could you send me a complete test
case please?
-Peter
On 2000-01-17, Oliver Elphick mentioned:
Peter, there seem to be problems with the COPY statement when psql is run
with redirected stdin.If I have a file ${DUMPDIR}/dbdump.product containing:
COPY product FROM stdin;
05 \N 000000 \N \N S D9 t f f f POLY BAGS-BLACK . Single f
...
\.and I run this command:
psql -e -d bray < ${DUMPDIR}/dbdump.productno error messages are seen.
If I remove the COPY command from the file and run the COPY frpm inside
psql, I see the errors:bray=> copy product from '/tmp/dbdump.product';
ERROR: <unnamed> referential integrity violation - key referenced from
product not found in brandname
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 18 18:22:22 2000
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 SAA10499
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 18:22:20 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61233 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S210969AbQARXVk>;
Wed, 19 Jan 2000 00:21:40 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12Ai31-0003lT-00; Wed, 19 Jan 2000 00:28:27 +0100
Date: Wed, 19 Jan 2000 00:28:27 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Jan Wieck <wieck@debis.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Foreign keys: unexpected result from ALTER TABLE...
ADD CONSTRAINT...
In-Reply-To: <38835F06.9C0B7FDF@debis.com>
Message-ID: <Pine.LNX.4.21.0001180148520.411-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-17, Jan Wieck mentioned:
So Peter, if you're working on ALTER TABLE ADD CONSTRAINT, let it
setup the appropriate RI triggers. Look at analyze.c how to do so.
My priority is actually ALTER TABLE / DROP COLUMN, at least in a crude
'use at your own risk, all your defaults and constraints are gone' way if
I can't figure it out better by then. The ALTER TABLE / ALTER COLUMN /
SET|DROP DEFAULT was just a by-product.
I have been looking into all this ALTER TABLE code (or at least similar
code which it would have to peruse, since there is not a lot of ALTER
TABLE code) and I think I have a good understanding of what would need to
happen, but I don't think I want to risk that now. (After all, I just
_think_ I understand it.) We'll see.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 18 18:22:21 2000
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 SAA10484
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 18:22:18 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61151 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S219165AbQARXVf>;
Wed, 19 Jan 2000 00:21:35 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12Ai36-0003lV-00; Wed, 19 Jan 2000 00:28:32 +0100
Date: Wed, 19 Jan 2000 00:28:32 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_dump not in very good shape
In-Reply-To: <21021.948126173@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001180145290.411-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-17, Tom Lane mentioned:
Hmm, maybe this is not what I meant. I meant adding the linking line to
pg_dump, not libpq.Not a usable answer: that would mean that *every* application using
libpq would have to start including backend/port/snprintf.o, on the
platforms where vsnprintf doesn't exist.
Nevermind. I got it all backwards.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 18 18:32:21 2000
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 SAA14900
for <hackers@postgresql.org>; Tue, 18 Jan 2000 18:31:39 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62197 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S176154AbQARXa6>;
Wed, 19 Jan 2000 00:30:58 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12AiCY-0003vH-00
for hackers@postgresql.org; Wed, 19 Jan 2000 00:38:18 +0100
Date: Wed, 19 Jan 2000 00:38:18 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: gperf anyone?
Message-ID: <Pine.LNX.4.21.0001170003210.1636-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
A while ago I played around with gperf (GNU perfect hash function
generator), abusing the keyword lookup in parser/keyword.c as playground.
Now before I delete this I was wondering if this would perhaps be of use
to the general public. I don't know how huge the speed advantage of this
is, I'm sure the parser/scanner speed is the least of our problems. But I
thunk especially ecpg could benefit from this. Btw., gperf is used by GCC,
so it's not a toy.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 18 18:37:21 2000
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 SAA17430
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 18:37:00 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62753 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S190491AbQARXgS>;
Wed, 19 Jan 2000 00:36:18 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12AiHg-0003vN-00; Wed, 19 Jan 2000 00:43:36 +0100
Date: Wed, 19 Jan 2000 00:43:36 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] multi-byte support broken in current
In-Reply-To: <20000118120421G.t-ishii@sra.co.jp>
Message-ID: <Pine.LNX.4.21.0001190041260.11420-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Huh? MULTIBYTE is defined in include/config.h, where it should be, when
you configure with --enable-multibyte. I explicitly removed the
-DMULTIBYTE option from the compile line. Perhaps the portions of the code
that were "broken" need to include c.h? The -DMULTIBYTE thing ought to go.
On 2000-01-18, Tatsuo Ishii mentioned:
The multi-byte support in current had been broken for a while due to
missing compile flag in Makefile.global.in. I have just committed fix
for the problem, and should be ok now.
--
Tatsuo Ishii************
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 18 19:32:21 2000
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 TAA32841
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 19:32:06 -0500 (EST) (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 JAA02758; Wed, 19 Jan 2000 09:30:21 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Dmitry Samersoff" <dms@wplus.net>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Index recreation in vacuum
Date: Wed, 19 Jan 2000 09:35:58 +0900
Message-ID: <000101bf6215$27831300$2801007e@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 V5.00.2314.1300
Importance: Normal
In-Reply-To: <200001182236.RAA04121@candle.pha.pa.us>
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]Bruce Momjian <pgman@candle.pha.pa.us> writes:
The beauty of doing a temp index while keeping the old one is that you
can recover right away, and maybe allow the old index to be used while
you vacuum?Huh? You've got the whole table locked exclusively for the duration
of the vacuum anyway.In fact, the instant that vacuum does its internal commit, the old index
contents are actually *wrong*, and there is no possible value in keeping
them after that. Might as well blow them away and recover the disk
space for use in constructing the new indexes.Oh, I thought the vacuum itself would use the index during processing.
It's a big charge for vacuum to keep consistency between heap table and
indexes. The main point of index recreation in vacuum is to invalidate the
indexes of the target table. Temp indexes or renaming technique is no
longer needed once indexes are invalidated.
Once again,how to invalidate/validate indexes ?
I want to avoid dropping indexes because the definition is lost and
'commit' is needed internally.
My proposal is to use relhasindex of pg_class.
How about ?
relhasindex is true -- all indexes of the table are valid if the table has
indexes.
relhasindex is false -- either the table has no indexes or all indexes
of the table are invalid
CREATE INDEX/DROP INDEX/DROP TABLE/VACUUM/REINDEX
would be able to ignore relhasindex.
Am I misusing relhasindex ?
If reindexing vacuum crashes,indexes of the target table would be invalid.
To recover indexes there would be 2 ways.
1) vacuum again
2) reindex the table
Note that we would be able to REINDEX user tables under postmaster.
Comments ?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Tue Jan 18 19:46:22 2000
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 TAA35513
for <hackers@postgreSQL.org>; Tue, 18 Jan 2000 19:45:37 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA07846;
Tue, 18 Jan 2000 19:36:00 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001190036.TAA07846@candle.pha.pa.us>
Subject: Re: [HACKERS] gperf anyone?
In-Reply-To: <Pine.LNX.4.21.0001170003210.1636-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 19, 2000 00:38:18 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 18 Jan 2000 19:36:00 -0500 (EST)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
A while ago I played around with gperf (GNU perfect hash function
generator), abusing the keyword lookup in parser/keyword.c as playground.
Now before I delete this I was wondering if this would perhaps be of use
to the general public. I don't know how huge the speed advantage of this
is, I'm sure the parser/scanner speed is the least of our problems. But I
thunk especially ecpg could benefit from this. Btw., gperf is used by GCC,
so it's not a toy.
keywords are a fixed array, with a binary search to find a match. Could
gperf be faster? We also can not distribute GNU code.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 19:39:21 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA34386
for <hackers@postgresql.org>; Tue, 18 Jan 2000 19:39:17 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id UAA27928;
Tue, 18 Jan 2000 20:39:25 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 18 Jan 2000 20:39:25 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Peter Eisentraut <peter_e@gmx.net>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] gperf anyone?
In-Reply-To: <Pine.LNX.4.21.0001170003210.1636-100000@localhost.localdomain>
Message-ID: <Pine.BSF.4.21.0001182039020.23487-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 19 Jan 2000, Peter Eisentraut wrote:
A while ago I played around with gperf (GNU perfect hash function
generator), abusing the keyword lookup in parser/keyword.c as playground.
Now before I delete this I was wondering if this would perhaps be of use
to the general public. I don't know how huge the speed advantage of this
is, I'm sure the parser/scanner speed is the least of our problems. But I
thunk especially ecpg could benefit from this. Btw., gperf is used by GCC,
so it's not a toy.
Okay, that post told me absolutely nothing :( What would we use it
for? What is its purpose?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Jan 18 20:09:30 2000
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 UAA41943
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 20:08:39 -0500 (EST) (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 KAA02790; Wed, 19 Jan 2000 10:08:02 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Index recreation in vacuum
Date: Wed, 19 Jan 2000 10:13:40 +0900
Message-ID: <000201bf621a$6b9baf20$2801007e@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 V5.00.2314.1300
Importance: Normal
In-Reply-To: <200001181821.NAA02988@candle.pha.pa.us>
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us][Charset iso-8859-1 unsupported, filtering to ASCII...]
Hi all,
I'm trying to implement REINDEX command.
REINDEX operation itself is available everywhere and
I've thought about applying it to VACUUM.That is a good idea. Vacuuming of indexes can be very slow.
.
My plan is as follows.Add a new option to force index recreation in vacuum
and if index recreation is specified.Couldn't we auto-recreate indexes based on the number of tuples moved by
vacuum,
Yes,we could probably do it. But I'm not sure the availability of new
vacuum.
New vacuum would give us a big advantage that
1) Much faster than current if vacuum remove/moves many tuples.
2) Does shrink index files
But in case of abort/crash
1) couldn't choose index scan for the table
2) unique constraints of the table would be lost
I don't know how people estimate this disadvantage.
Now I'm inclined to use relhasindex of pg_class to
validate/invalidate indexes of a table at once.There are a few calls to CatalogIndexInsert() that know the
system table they
are using and know it has indexes, so it does not check that field. You
could add cases for that.
I think there aren't so many places to check.
I would examine it if my idea is OK.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Tue Jan 18 20:07:30 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA41691
for <hackers@postgreSQL.org>; Tue, 18 Jan 2000 20:07:11 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id RAA05232;
Tue, 18 Jan 2000 17:29:34 -0800 (PST)
Date: Tue, 18 Jan 2000 17:29:34 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>, hackers@postgreSQL.org
Subject: Re: [HACKERS] gperf anyone?
Message-ID: <20000118172933.N8736@fw.wintelcom.net>
References: <Pine.LNX.4.21.0001170003210.1636-100000@localhost.localdomain>
<200001190036.TAA07846@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200001190036.TAA07846@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Tue, Jan 18, 2000 at 07:36:00PM
-0500
* Bruce Momjian <pgman@candle.pha.pa.us> [000118 17:14] wrote:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
A while ago I played around with gperf (GNU perfect hash function
generator), abusing the keyword lookup in parser/keyword.c as playground.
Now before I delete this I was wondering if this would perhaps be of use
to the general public. I don't know how huge the speed advantage of this
is, I'm sure the parser/scanner speed is the least of our problems. But I
thunk especially ecpg could benefit from this. Btw., gperf is used by GCC,
so it's not a toy.keywords are a fixed array, with a binary search to find a match. Could
gperf be faster?
yes:
~ % gperf
/* starting time is 21:10:49 */
postgresql
really
kicks
butt
/* C code produced by gperf version 2.1 (K&R C version) */
/* Command-line: gperf */
#define MIN_WORD_LENGTH 4
#define MAX_WORD_LENGTH 10
#define MIN_HASH_VALUE 4
#define MAX_HASH_VALUE 10
/*
4 keywords
7 is the maximum key range
*/
static int
hash (str, len)
register char *str;
register unsigned int len;
{
static unsigned char hash_table[] =
{
10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 0, 10,
10, 10, 10, 10, 10, 10, 10, 0, 0, 10,
10, 10, 0, 10, 0, 0, 0, 10, 10, 10,
10, 0, 10, 10, 10, 10, 10, 10,
};
return len + hash_table[str[len - 1]] + hash_table[str[0]];
}
char *
in_word_set (str, len)
register char *str;
register unsigned int len;
{
static char * wordlist[] =
{
"", "", "", "",
"butt",
"kicks",
"really",
"", "", "",
"postgresql",
};
if (len <= MAX_WORD_LENGTH && len >= MIN_WORD_LENGTH)
{
register int key = hash (str, len);
if (key <= MAX_HASH_VALUE && key >= MIN_HASH_VALUE)
{
register char *s = wordlist[key];
if (*s == *str && !strcmp (str + 1, s + 1))
return s;
}
}
return 0;
}
/* ending time is 21:10:58 */
A perfect hash should be much faster at the trivial expense of some space.
From the distribution:
While teaching a data structures course at University of California,
Irvine, I developed a program called GPERF that generates perfect hash
functions for sets of key words. A perfect hash function is simply:
A hash function and a data structure that allows
recognition of a key word in a set of words using
exactly 1 probe into the data structure.
We also can not distribute GNU code.
I'm pretty sure that the code the gperf outputs is not covered under the
GPL, just gperf itself.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
From bouncefilter Tue Jan 18 20:34:30 2000
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 UAA48651
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 20:33:46 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA13890;
Wed, 19 Jan 2000 10:33:40 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-28 [133.137.84.28])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA11784;
Wed, 19 Jan 2000 10:33:37 +0900
To: lockhart@alumni.caltech.edu
Cc: scrappy@hub.org, jose@sferacarta.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] date/time problem in v6.5.3 and 7.0.0 ...
In-Reply-To: <38847B5B.DA4BEE00@alumni.caltech.edu>
References: <Pine.BSF.4.21.0001142201470.46499-100000@thelab.hub.org>
<38847472.DC3C84AA@sferacarta.com>
<38847B5B.DA4BEE00@alumni.caltech.edu>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000119103518I.t-ishii@sra.co.jp>
Date: Wed, 19 Jan 2000 10:35:18 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 13
I can add days to now(), but not subtract?
The problem is that it is meaningful to subtract two absolute times,
giving a delta time as a result, *and* it is meaningful to subtract a
delta time from an absolute time, giving another absolute time as a
result.
It would be nice if we could decide '30 days' is a delta time because
it is not suitable for an absolute time representation. Would it be
hard?
--
Tatsuo Ishii
From bouncefilter Tue Jan 18 20:49:30 2000
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 UAA50227
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 20:48:53 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA15188;
Wed, 19 Jan 2000 10:48:51 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA12090;
Wed, 19 Jan 2000 10:48:50 +0900
To: peter_e@gmx.net
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] multi-byte support broken in current
In-Reply-To: Your message of "Wed, 19 Jan 2000 00:43:36 +0100 (CET)"
<Pine.LNX.4.21.0001190041260.11420-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001190041260.11420-100000@localhost.localdomain>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000119104850Q.t-ishii@sra.co.jp>
Date: Wed, 19 Jan 2000 10:48:50 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 14
Huh? MULTIBYTE is defined in include/config.h, where it should be, when
you configure with --enable-multibyte. I explicitly removed the
-DMULTIBYTE option from the compile line. Perhaps the portions of the code
that were "broken" need to include c.h? The -DMULTIBYTE thing ought to go.
Oh, I see. I reverted back my change to Makefile.global. Sorry for the
confusion.
BTW, while running configure, --with-mb is silently ignored. This is
not good since users might believe multibyte has been enabled. I have
added checking for --with-mb. If it is specified, configure now prints
an error message and exits.
--
Tatsuo Ishii
From bouncefilter Tue Jan 18 21:24:31 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA58593
for <hackers@postgreSQL.org>; Tue, 18 Jan 2000 21:24:19 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (ip175.pdx2.pacifier.com [216.65.144.175])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id SAA13512;
Tue, 18 Jan 2000 18:22:38 -0800 (PST)
Message-Id: <3.0.1.32.20000118174928.00ef0370@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 18 Jan 2000 17:49:28 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>, Peter Eisentraut <peter_e@gmx.net>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] gperf anyone?
Cc: hackers@postgreSQL.org
In-Reply-To: <200001190036.TAA07846@candle.pha.pa.us>
References: <Pine.LNX.4.21.0001170003210.1636-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 07:36 PM 1/18/00 -0500, Bruce Momjian wrote:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
A while ago I played around with gperf (GNU perfect hash function
generator), abusing the keyword lookup in parser/keyword.c as playground.
Now before I delete this I was wondering if this would perhaps be of use
to the general public. I don't know how huge the speed advantage of this
is, I'm sure the parser/scanner speed is the least of our problems. But I
thunk especially ecpg could benefit from this. Btw., gperf is used by GCC,
so it's not a toy.keywords are a fixed array, with a binary search to find a match. Could
gperf be faster? We also can not distribute GNU code.
I wondered about this last, i.e. the use of GNU code since Postgres
is licensed differently.
The reality is that looking up keywords form a tiny fraction of the
time spent by any language system I can think of. The current binary
search on a fixed array might be faster, might be slower than a perfect
hash on a particular machine depending on the calculation done to
do the hashing.
Whether faster or slower, though, I can't imagine either method taking
noticably more than 0% of the total time to process a query, even the
most simple queries.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Tue Jan 18 20:51:30 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA50462
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 20:51:06 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA11421;
Tue, 18 Jan 2000 20:50:50 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001190150.UAA11421@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <000201bf621a$6b9baf20$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 19, 2000 10:13:40 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 18 Jan 2000 20:50:50 -0500 (EST)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Add a new option to force index recreation in vacuum
and if index recreation is specified.Couldn't we auto-recreate indexes based on the number of tuples moved by
vacuum,Yes,we could probably do it. But I'm not sure the availability of new
vacuum.New vacuum would give us a big advantage that
1) Much faster than current if vacuum remove/moves many tuples.
2) Does shrink index filesBut in case of abort/crash
1) couldn't choose index scan for the table
2) unique constraints of the table would be lostI don't know how people estimate this disadvantage.
That's why I was recommending rename(). The actual window of
vunerability goes from perhaps hours to fractions of a second.
In fact, if I understand this right, you could make the vulerability
zero by just performing the rename as one operation.
In fact, for REINDEX cases where you don't have a lock on the entire
table as you do in vacuum, you could reindex the table with a simple
read-lock on the base table and index, and move the new index into place
with the users seeing no change. Only people traversing the index
during the change would have a problem. You just need an exclusive
access on the index for the duration of the rename() so no one is
traversing the index during the rename().
Destroying the index and recreating opens a large time span that there
is no index, and you have to jury-rig something so people don't try to
use the index. With rename() you just put the new index in place with
one operation. Just don't let people traverse the index during the
change. The pointers to the heap tuples is the same in both indexes.
In fact, with WAL, we will allow multiple physical files for the same
table by appending the table oid to the file name. In this case, the
old index could be deleted by rename, and people would continue to use
the old index until they deleted the open file pointers. Not sure how
this works in practice because new tuples would not be inserted into the
old copy of the index.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 20:53:30 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA50635
for <hackers@postgreSQL.org>; Tue, 18 Jan 2000 20:52:34 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA11497;
Tue, 18 Jan 2000 20:52:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001190152.UAA11497@candle.pha.pa.us>
Subject: Re: [HACKERS] gperf anyone?
In-Reply-To: <20000118172933.N8736@fw.wintelcom.net> from Alfred Perlstein at
"Jan 18, 2000 05:29:34 pm"
To: Alfred Perlstein <bright@wintelcom.net>
Date: Tue, 18 Jan 2000 20:52:17 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
A perfect hash should be much faster at the trivial expense of some space.
From the distribution:
While teaching a data structures course at University of California,
Irvine, I developed a program called GPERF that generates perfect hash
functions for sets of key words. A perfect hash function is simply:A hash function and a data structure that allows
recognition of a key word in a set of words using
exactly 1 probe into the data structure.We also can not distribute GNU code.
I'm pretty sure that the code the gperf outputs is not covered under the
GPL, just gperf itself.
Can you run our keywords.c using our method and gperf and see if there
is any speed difference?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 21:05:30 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA55990
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 21:04:31 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA11990;
Tue, 18 Jan 2000 21:04:11 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001190204.VAA11990@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <200001190150.UAA11421@candle.pha.pa.us> from Bruce Momjian at
"Jan 18, 2000 08:50:50 pm"
To: Bruce Momjian <pgman@candle.pha.pa.us>
Date: Tue, 18 Jan 2000 21:04:11 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I don't know how people estimate this disadvantage.
That's why I was recommending rename(). The actual window of
vunerability goes from perhaps hours to fractions of a second.In fact, if I understand this right, you could make the vulerability
zero by just performing the rename as one operation.In fact, for REINDEX cases where you don't have a lock on the entire
table as you do in vacuum, you could reindex the table with a simple
read-lock on the base table and index, and move the new index into place
with the users seeing no change. Only people traversing the index
during the change would have a problem. You just need an exclusive
access on the index for the duration of the rename() so no one is
traversing the index during the rename().Destroying the index and recreating opens a large time span that there
is no index, and you have to jury-rig something so people don't try to
use the index. With rename() you just put the new index in place with
one operation. Just don't let people traverse the index during the
change. The pointers to the heap tuples is the same in both indexes.In fact, with WAL, we will allow multiple physical files for the same
table by appending the table oid to the file name. In this case, the
old index could be deleted by rename, and people would continue to use
the old index until they deleted the open file pointers. Not sure how
this works in practice because new tuples would not be inserted into the
old copy of the index.
Maybe I am all wrong here. Maybe most of the advantage of rename() are
meaningless with reindex using during vacuum, which is the most
important use of reindex.
Let's look at index using during vacuum. Right now, how does vacuum
handle indexes when it moves a tuple? Does it do each index update as
it moves a tuple? Is that why it is so slow?
If we don't do that and vacuum fails, what state is the table left in?
If we don't update the index for every tuple, the index is invalid in a
vacuum failure. rename() is not going to help us here. It keeps the
old index around, but the index is invalid anyway, right?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 21:23:31 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA58427
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 21:23:03 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA12708;
Tue, 18 Jan 2000 21:22:38 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001190222.VAA12708@candle.pha.pa.us>
Subject: Re: [HACKERS] [hackers]development suggestion needed (filepath as
symlink)
In-Reply-To: <388520E3.D192ED7B@alumni.caltech.edu> from Thomas Lockhart at
"Jan 19, 2000 02:26:43 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 18 Jan 2000 21:22:38 -0500 (EST)
CC: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Yes, that's about the sum of it. Why not the links? I think
that it's an elegant way of designing the whole thing.The only problem with symlinks is, that it does not solve the
"too many files in one directory to give optimal performance"
problem for those that have tons of tables.Is that really a problem on modern operating systems? We could actually
hash the file names into directory buckets and access them that way, and
have one directory that old symlinks to the hashed files.imho symlinks is exactly the wrong way to head on this. If the system
needs to know the true location of something, then it may as well
refer to that location explicitly. Our storage manager should learn
how to deal with explicit locations, and we shouldn't implement this
just as a patch on the table creation code.
OK, no symlinks.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 21:15:31 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA57255
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 21:14:33 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id CAA19986;
Wed, 19 Jan 2000 02:22:55 GMT
Sender: lockhart@hub.org
Message-ID: <38851FFF.63E90AE4@alumni.caltech.edu>
Date: Wed, 19 Jan 2000 02:22: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: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: scrappy@hub.org, jose@sferacarta.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] date/time problem in v6.5.3 and 7.0.0 ...
References: <Pine.BSF.4.21.0001142201470.46499-100000@thelab.hub.org>
<38847472.DC3C84AA@sferacarta.com>
<38847B5B.DA4BEE00@alumni.caltech.edu>
<20000119103518I.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I can add days to now(), but not subtract?
The problem is that it is meaningful to subtract two absolute times,
giving a delta time as a result, *and* it is meaningful to subtract a
delta time from an absolute time, giving another absolute time as a
result.It would be nice if we could decide '30 days' is a delta time because
it is not suitable for an absolute time representation. Would it be
hard?
Hmm. I'm not sure how hard it would be. The places where types need to
be matched to operators are fairly well isolated in the parser.
However, we would need a new kind of input function which does not
throw an elog(ERROR), but rather just returns failure if the input
does not get decoded. Then, we could accumulate a list of successfully
decoded types (based on our list of candidate operators), and if that
list is of length one then we have a match.
One way to implement this would be to define an additional input
routine (which the existing input routine would use) which returns an
error rather than throwing an elog() error. Then, our parser could use
this additional routine to discriminate between the candidate types.
The input routine could be found in a similar way to our existing
"implicit coersion" code, which assumes a specific function name for
each type.
The downside to this is that we have built up one additional
assumption about the form and contents of our system tables. But,
since it adds functionality that probably isn't a bad thing.
I do know I'm not likely to find time to work on it for the next
release...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Jan 18 21:19:31 2000
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 VAA57790
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 21:18:58 -0500 (EST) (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 LAA02845; Wed, 19 Jan 2000 11:18:18 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Index recreation in vacuum
Date: Wed, 19 Jan 2000 11:23:55 +0900
Message-ID: <000801bf6224$3bfdd9a0$2801007e@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 V5.00.2314.1300
Importance: Normal
In-Reply-To: <200001190204.VAA11990@candle.pha.pa.us>
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]I don't know how people estimate this disadvantage.
That's why I was recommending rename(). The actual window of
vunerability goes from perhaps hours to fractions of a second.In fact, if I understand this right, you could make the vulerability
zero by just performing the rename as one operation.In fact, for REINDEX cases where you don't have a lock on the entire
table as you do in vacuum, you could reindex the table with a simple
read-lock on the base table and index, and move the new index into place
with the users seeing no change. Only people traversing the index
during the change would have a problem. You just need an exclusive
access on the index for the duration of the rename() so no one is
traversing the index during the rename().Destroying the index and recreating opens a large time span that there
is no index, and you have to jury-rig something so people don't try to
use the index. With rename() you just put the new index in place with
one operation. Just don't let people traverse the index during the
change. The pointers to the heap tuples is the same in both indexes.In fact, with WAL, we will allow multiple physical files for the same
table by appending the table oid to the file name. In this case, the
old index could be deleted by rename, and people would continue to use
the old index until they deleted the open file pointers. Not sure how
this works in practice because new tuples would not be inserted into the
old copy of the index.Maybe I am all wrong here. Maybe most of the advantage of rename() are
meaningless with reindex using during vacuum, which is the most
important use of reindex.Let's look at index using during vacuum. Right now, how does vacuum
handle indexes when it moves a tuple? Does it do each index update as
it moves a tuple? Is that why it is so slow?
Yes,I believe so. It's necessary to keep consistency between heap
table and indexes even in case of abort/crash.
As far as I see,it has been a big charge for vacuum.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Tue Jan 18 21:20:31 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA57841
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 21:19:30 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id CAA19993;
Wed, 19 Jan 2000 02:26:43 GMT
Sender: lockhart@hub.org
Message-ID: <388520E3.D192ED7B@alumni.caltech.edu>
Date: Wed, 19 Jan 2000 02:26:43 +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 <pgman@candle.pha.pa.us>
CC: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] [hackers]development suggestion needed (filepath as
symlink)
References: <200001181826.NAA05099@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Yes, that's about the sum of it. Why not the links? I think
that it's an elegant way of designing the whole thing.The only problem with symlinks is, that it does not solve the
"too many files in one directory to give optimal performance"
problem for those that have tons of tables.Is that really a problem on modern operating systems? We could actually
hash the file names into directory buckets and access them that way, and
have one directory that old symlinks to the hashed files.
imho symlinks is exactly the wrong way to head on this. If the system
needs to know the true location of something, then it may as well
refer to that location explicitly. Our storage manager should learn
how to deal with explicit locations, and we shouldn't implement this
just as a patch on the table creation code.
My $.02...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Jan 18 21:29:31 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA59384
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 21:29:03 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (ip175.pdx2.pacifier.com [216.65.144.175])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id SAA14945;
Tue, 18 Jan 2000 18:27:05 -0800 (PST)
Message-Id: <3.0.1.32.20000118182725.00ef4140@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 18 Jan 2000 18:27:25 -0800
To: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] [hackers]development suggestion needed (filepath
as symlink)
Cc: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
In-Reply-To: <388520E3.D192ED7B@alumni.caltech.edu>
References: <200001181826.NAA05099@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:26 AM 1/19/00 +0000, Thomas Lockhart wrote:
imho symlinks is exactly the wrong way to head on this. If the system
needs to know the true location of something, then it may as well
refer to that location explicitly. Our storage manager should learn
how to deal with explicit locations, and we shouldn't implement this
just as a patch on the table creation code.
That's my feeling too.
We could document the query needed to list where all tables
are located, grouped by tablespace.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Tue Jan 18 21:46:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA65034
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 21:46:12 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA13040;
Tue, 18 Jan 2000 21:45:27 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001190245.VAA13040@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <000801bf6224$3bfdd9a0$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 19, 2000 11:23:55 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 18 Jan 2000 21:45:27 -0500 (EST)
CC: pgsql-hackers <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
In fact, for REINDEX cases where you don't have a lock on the entire
table as you do in vacuum, you could reindex the table with a simple
read-lock on the base table and index, and move the new index into place
with the users seeing no change. Only people traversing the index
during the change would have a problem. You just need an exclusive
access on the index for the duration of the rename() so no one is
traversing the index during the rename().Destroying the index and recreating opens a large time span that there
is no index, and you have to jury-rig something so people don't try to
use the index. With rename() you just put the new index in place with
one operation. Just don't let people traverse the index during the
change. The pointers to the heap tuples is the same in both indexes.In fact, with WAL, we will allow multiple physical files for the same
table by appending the table oid to the file name. In this case, the
old index could be deleted by rename, and people would continue to use
the old index until they deleted the open file pointers. Not sure how
this works in practice because new tuples would not be inserted into the
old copy of the index.Maybe I am all wrong here. Maybe most of the advantage of rename() are
meaningless with reindex using during vacuum, which is the most
important use of reindex.Let's look at index using during vacuum. Right now, how does vacuum
handle indexes when it moves a tuple? Does it do each index update as
it moves a tuple? Is that why it is so slow?Yes,I believe so. It's necessary to keep consistency between heap
table and indexes even in case of abort/crash.
As far as I see,it has been a big charge for vacuum.
OK, how about making a copy of the heap table before starting vacuum,
moving all the tuples in that copy, create new index, and then move the
new heap and indexes over the old version. We already have an exclusive
lock on the table. That would be 100% reliable, with the disadvantage
of using 2x the disk space. Seems like a big win.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 21:52:32 2000
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 VAA65629
for <hackers@postgresql.org>; Tue, 18 Jan 2000 21:51:52 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63541 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S288797AbQASCvL>;
Wed, 19 Jan 2000 03:51:11 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12AlKH-0006m8-00; Wed, 19 Jan 2000 03:58:29 +0100
Date: Wed, 19 Jan 2000 03:58:29 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Date/time types (Re: [HACKERS] Re: [COMMITTERS]
pgsql/src/include/catalog (pg_type.h))
In-Reply-To: <3883D022.8386A215@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0001190047490.11420-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-18, Thomas Lockhart mentioned:
We are going to internally move everything to the more standard ANSI
names, right, or do we give preference to the older types?Well, that could be up for discussion. The "internal" abstime/reltime
We might as well make that change now rather than dragging the old baggage
(8 different types after all!) around for another major release. I don't
mean dropping them but putting forth a clear preference.
Preferred set: timestamp, interval, date, time
timespan: alias to interval, for compatibility
datetime: alias to timestamp, for compatibility
abstime, reltime: deprecated, used only for internal catalogs
I mean that would make sense to me as a user. I have long been confused
about that.
types are direct copies of Unix system time, which most systems
support at a fundamental level. Moving to timestamp/interval will
The problem also seems to be that on some systems they seem to be 8 byte
types (see original TODO item). So either you move it to proper int32
types, thus losing the exact correspondence, or you make them aliases to
timespan and interval as well and lose them sometime.
double the storage size of those fields, with no increase in
functionality afaik.
Isn't storage size in multiples of 8192 anyway? So this probably makes
zero difference in practice.
Peter brought up changing one field to timestamp; that would have the
benefit of being able to specify times past y2038.
The Y2038 problem is next. We could be the first ones to comply. :)
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 18 21:52:32 2000
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 VAA65653
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 21:52:00 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63586 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S305180AbQASCvS>;
Wed, 19 Jan 2000 03:51:18 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12AlKP-0006mB-00; Wed, 19 Jan 2000 03:58:37 +0100
Date: Wed, 19 Jan 2000 03:58:37 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_proc.h changed
In-Reply-To: <20000118145114M.t-ishii@sra.co.jp>
Message-ID: <Pine.LNX.4.21.0001190102590.11420-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
I've been wondering about that. Great!
On 2000-01-18, Tatsuo Ishii mentioned:
Hi,
I have added two built-in functions:
pg_char_to_encoding() -- convert encoding string to encoding id
pg_encoding_to_char() -- convert encoding id to encoding stringMain purpose for this is to allow psql -l to print encoding names
rather than encoding ids (sample output from psql shown below) in a
multibyte enabled installation.List of databases
Database | Owner | Encoding
------------+---------+----------
regression | t-ishii | EUC_JP
template1 | t-ishii | EUC_JP
test | t-ishii | EUC_JP
(3 rows)This is much more "user friendly" IMHO.
initdb required.
--
Tatsuo Ishii************
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 18 21:59:31 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA66712
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 21:59:00 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA13313;
Tue, 18 Jan 2000 21:58:44 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001190258.VAA13313@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <000801bf6224$3bfdd9a0$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 19, 2000 11:23:55 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 18 Jan 2000 21:58:44 -0500 (EST)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Let's look at index using during vacuum. Right now, how does vacuum
handle indexes when it moves a tuple? Does it do each index update as
it moves a tuple? Is that why it is so slow?Yes,I believe so. It's necessary to keep consistency between heap
table and indexes even in case of abort/crash.
As far as I see,it has been a big charge for vacuum.
In fact, maybe we just need to look at the ability to recreate the
entire table/index in one big function. We could do a sequential scan
of the table and if we find > X number of rows that are expired, we
decide to do a full recreate of the table with all new indexes vs.
doing a vacuum. This seems to be the core of what the REINDEX function
is doing anyway.
In fact, I wonder if we should enable a % parameter to VACUUM, so vacuum
does something only of X% of the disk space will be saved by the vacuum.
Currently if someone deletes the first row of a able, every row is moved
to save a few bytes of disk space. That is certainly a waste, and
telling people they have to vacuum every night is probably a waste in
most cases too, but we don't give administrators the ability to control
when a vacuum is a good idea.
We could get ALTER TABLE DROP COLUMN working too by recreating the table
without the dropped column.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 21:53:32 2000
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 VAA65825;
Tue, 18 Jan 2000 21:53:21 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63767 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S294940AbQASCwl>;
Wed, 19 Jan 2000 03:52:41 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12AlLb-0006mG-00; Wed, 19 Jan 2000 03:59:51 +0100
Date: Wed, 19 Jan 2000 03:59:50 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: meskes@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cannot compile psql
In-Reply-To: <20000118225433V.t-ishii@sra.co.jp>
Message-ID: <Pine.LNX.4.21.0001190126140.11420-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-18, Tatsuo Ishii mentioned:
I assume you have configured --with-mb=something *before*
make. --with-mb does not seem to work anymore. Try:make distclean
./configure --enable-multibyte[=something]Seems we have to warn if --with-mb is used, otherwise multibyte users
would complain about it.
I wanted to do that, but as soon as you put that option back in it shows
up in --help output, which is against the point of it being deprecated.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 18 21:54:01 2000
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 VAA65867
for <pgsql-hackers@postgresql.org>;
Tue, 18 Jan 2000 21:53:31 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63799 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S313372AbQASCwx>;
Wed, 19 Jan 2000 03:52:53 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12AlLw-0006mJ-00; Wed, 19 Jan 2000 04:00:12 +0100
Date: Wed, 19 Jan 2000 04:00:12 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] multi-byte support broken in current
In-Reply-To: <20000118120421G.t-ishii@sra.co.jp>
Message-ID: <Pine.LNX.4.21.0001190225470.23390-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Further investigation showed that header files where indeed missing in
some files, in particular the regex code. Is that what was broken? I fixed
that now and removed all the MBFLAGS business. Every file should include
"postgres.h", so it grabs the #define MULTIBYTE 1 from include/config.h.
If you got any more problems with this, let me know and I'll help fix it.
Btw., I tried running the multibyte regression tests, that didn't work so
well.
On 2000-01-18, Tatsuo Ishii mentioned:
The multi-byte support in current had been broken for a while due to
missing compile flag in Makefile.global.in. I have just committed fix
for the problem, and should be ok now.
--
Tatsuo Ishii************
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Jan 18 22:09:34 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA72504
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 22:08:40 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA13965;
Tue, 18 Jan 2000 22:08:25 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001190308.WAA13965@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <000f01bf622a$bf423940$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 19, 2000 12:10:32 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 18 Jan 2000 22:08:25 -0500 (EST)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=UNKNOWN-8BIT
Content-Transfer-Encoding: 8bit
I heard from someone that old vacuum had been like so.
Probably 2x disk space for big tables was a big disadvantage.
That's interesting.
In addition,rename(),unlink(),mv aren't preferable for transaction
control as far as I see. We couldn't avoid inconsistency using
those OS functions.
I disagree. Vacuum can't be rolled back anyway in the sense you can
bring back expire tuples, though I have no idea why you would want to.
You have an exclusive lock on the table. Putting new heap/indexes in
place that match and have no expired tuples seems like it can not fail
in any situation.
Of course, the buffers of the old table have to be marked as invalid,
but with an exclusive lock, that is not a problem. I am sure we do that
anyway���in vacuum.
We have to wait the change of relation file naming if copying
vacuum is needed.
Under the spec we need not rename(),mv etc.
Sorry, I don't agree, yet...
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 22:06:31 2000
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 WAA71762
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 22:05:33 -0500 (EST) (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 MAA02870; Wed, 19 Jan 2000 12:04:55 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Index recreation in vacuum
Date: Wed, 19 Jan 2000 12:10:32 +0900
Message-ID: <000f01bf622a$bf423940$2801007e@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 V5.00.2314.1300
Importance: Normal
In-Reply-To: <200001190245.VAA13040@candle.pha.pa.us>
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]Maybe I am all wrong here. Maybe most of the advantage of
rename() are
meaningless with reindex using during vacuum, which is the most
important use of reindex.Let's look at index using during vacuum. Right now, how does vacuum
handle indexes when it moves a tuple? Does it do each index update as
it moves a tuple? Is that why it is so slow?Yes,I believe so. It's necessary to keep consistency between heap
table and indexes even in case of abort/crash.
As far as I see,it has been a big charge for vacuum.OK, how about making a copy of the heap table before starting vacuum,
moving all the tuples in that copy, create new index, and then move the
new heap and indexes over the old version. We already have an exclusive
lock on the table. That would be 100% reliable, with the disadvantage
of using 2x the disk space. Seems like a big win.
I heard from someone that old vacuum had been like so.
Probably 2x disk space for big tables was a big disadvantage.
In addition,rename(),unlink(),mv aren't preferable for transaction
control as far as I see. We couldn't avoid inconsistency using
those OS functions.
We have to wait the change of relation file naming if copying
vacuum is needed.
Under the spec we need not rename(),mv etc.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Tue Jan 18 22:22:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA77334
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 22:22:30 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA14508;
Tue, 18 Jan 2000 22:22:00 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001190322.WAA14508@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <000f01bf622a$bf423940$2801007e@tpf.co.jp> from Hiroshi Inoue at
"Jan 19, 2000 12:10:32 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 18 Jan 2000 22:22:00 -0500 (EST)
CC: pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
In addition,rename(),unlink(),mv aren't preferable for transaction
control as far as I see. We couldn't avoid inconsistency using
those OS functions.
We have to wait the change of relation file naming if copying
vacuum is needed.
Under the spec we need not rename(),mv etc.
Are you worried the system may crash in the middle of renaming one
table, but not the indexes. That would be a serious problem.
I see now. I can't think of a way around that. The rename() itself is
atomic.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 22:22:31 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA77301
for <hackers@postgreSQL.org>; Tue, 18 Jan 2000 22:22:15 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id DAA20355;
Wed, 19 Jan 2000 03:30:43 GMT
Sender: lockhart@hub.org
Message-ID: <38852FE3.1698BDA9@alumni.caltech.edu>
Date: Wed, 19 Jan 2000 03:30:43 +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: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: Date/time types (Re: [HACKERS] Re: [COMMITTERS]
pgsql/src/include/catalog(pg_type.h))
References: <Pine.LNX.4.21.0001190047490.11420-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
We might as well make that change now rather than dragging the old baggage
(8 different types after all!) around for another major release. I don't
mean dropping them but putting forth a clear preference.
Preferred set: timestamp, interval, date, time
timespan: alias to interval, for compatibility
datetime: alias to timestamp, for compatibility
abstime, reltime: deprecated, used only for internal catalogs
I mean that would make sense to me as a user. I have long been confused
about that.
Hmm. I *think* I state a clear preference in the User's Guide. Is
there another place to mention this? Should we be more explicit?? If
we're going to fix it up, we need some suggestions ;)
The problem also seems to be that on some systems they seem to be 8 byte
types (see original TODO item). So either you move it to proper int32
types, thus losing the exact correspondence, or you make them aliases to
timespan and interval as well and lose them sometime.
That's a detail on 64 bit systems like Alpha/Unix, but afaik one can
force the field into 4 bytes and you get the Right Thing, at least
until 2038. I'd prefer moving to an 8 byte integer, but we don't have
those on enough of our supported platforms, so the 8 byte float is the
next best thing to get past 2038.
double the storage size of those fields, with no increase in
functionality afaik.Isn't storage size in multiples of 8192 anyway? So this probably makes
zero difference in practice.
It actually makes a big difference on the simplest tests, which have a
single small column. Then, the tuple overhead is most obvious, and
(I'm not sure of the actual numbers) going from 40 bytes to 60 bytes
is significant.
Peter brought up changing one field to timestamp; that would have the
benefit of being able to specify times past y2038.The Y2038 problem is next. We could be the first ones to comply. :)
Since we are currently mapping to Unix system time, I'd rather go slow
and wait for a good OS solution. Or we could go to 8 byte integers
with 100ns ticks a la Corba Time (hmm, maybe we can get an
implementation from somewhere which would work on all of our
platforms??). The double we currently have for user time isn't likely
to be what OSes end up using, though with our license they could ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Jan 18 22:43:32 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA83365
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 22:42:36 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA15358;
Tue, 18 Jan 2000 22:41:40 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001190341.WAA15358@candle.pha.pa.us>
Subject: Status on 7.0
To: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>,
Jan Wieck <jwieck@debis.com>
Date: Tue, 18 Jan 2000 22:41:40 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Can I ask how our big open items for 7.0 are doing:
Long tuples/TOAST(Jan)
Foriegn keys/action buffer(Jan)
Unify date/time types(Thomas)
Outer Joins(Thomas)
I am only asking to know if we should continue with the planned Feb 1
beta?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 18 23:42:32 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA98926
for <hackers@postgreSQL.org>; Tue, 18 Jan 2000 23:42:16 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA03757;
Tue, 18 Jan 2000 23:40:49 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
hackers@postgreSQL.org
Subject: Re: [HACKERS] gperf anyone?
In-reply-to: <3.0.1.32.20000118174928.00ef0370@mail.pacifier.com>
References: <Pine.LNX.4.21.0001170003210.1636-100000@localhost.localdomain>
<3.0.1.32.20000118174928.00ef0370@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Tue, 18 Jan 2000 17:49:28 -0800"
Date: Tue, 18 Jan 2000 23:40:49 -0500
Message-ID: <3754.948256849@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
At 07:36 PM 1/18/00 -0500, Bruce Momjian wrote:
I wondered about this last, i.e. the use of GNU code since Postgres
is licensed differently.
AFAIK this is no worse than using flex or bison --- the source code of
gperf is GPL'ed, but its output is not.
Don Baccus <dhogaza@pacifier.com> writes:
Whether faster or slower, though, I can't imagine either method taking
noticably more than 0% of the total time to process a query, even the
most simple queries.
I agree with Don that the performance benefit is likely to be
unmeasurable. Still, there could be a win: we currently have to modify
keywords.c by hand every time we have to add/delete a keyword. Does
gperf offer any aid for maintaining the keyword list? If so, that'd
be sufficient reason to switch to it...
regards, tom lane
From bouncefilter Tue Jan 18 23:39:32 2000
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 XAA98661
for <pgsql-hackers@postgreSQL.org>;
Tue, 18 Jan 2000 23:39:17 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id NAA26045;
Wed, 19 Jan 2000 13:39:16 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-20 [133.137.84.20])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id NAA14414;
Wed, 19 Jan 2000 13:39:13 +0900
To: peter_e@gmx.net
Cc: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] multi-byte support broken in current
In-Reply-To: <Pine.LNX.4.21.0001190225470.23390-100000@localhost.localdomain>
References: <20000118120421G.t-ishii@sra.co.jp>
<Pine.LNX.4.21.0001190225470.23390-100000@localhost.localdomain>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000119134054P.t-ishii@sra.co.jp>
Date: Wed, 19 Jan 2000 13:40:54 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 41
Further investigation showed that header files where indeed missing in
some files, in particular the regex code. Is that what was broken? I fixed
that now and removed all the MBFLAGS business. Every file should include
"postgres.h", so it grabs the #define MULTIBYTE 1 from include/config.h.
If you got any more problems with this, let me know and I'll help fix it.
I did not see such a problem. I just saw -DMULTIBYTE was missing and
thought MB was broken (that was a misunderstanding). Anyway I have
done a cvs up and seen your fixes working well.
Btw., I tried running the multibyte regression tests, that didn't work so
well.
Yes, the regression test (src/test/regress) does not work with
SQL_ASCII because test cases for it is missing in sql/. However, I'm
not certain now including the multibyte test cases in the regression
test suite is a good thing. Maybe src/test/mb is only the right place
for MB and we should remove MB stuffs from the regression.
BTW, src/test/mb tests are broken due to the changes of psql output.
euc_jp .. CREATE DATABASE
ok
sjis .. ok
euc_kr .. CREATE DATABASE
failed
euc_cn .. CREATE DATABASE
failed
euc_tw .. CREATE DATABASE
failed
big5 .. failed
unicode .. CREATE DATABASE
failed
mule_internal .. CREATE DATABASE
failed
I have fixed for EUC_JP and SJIS cases and am going to fix rest of
them. But reading files written in languages that I never understand
is really hard:-)
--
Tatsuo Ishii
From bouncefilter Tue Jan 18 23:57:32 2000
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id XAA00993
for <hackers@postgreSQL.org>; Tue, 18 Jan 2000 23:57:24 -0500 (EST)
(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 LAA28259
for <hackers@postgreSQL.org>; Wed, 19 Jan 2000 11:57:22 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <38854432.54EE2F01@krs.ru>
Date: Wed, 19 Jan 2000 11:57:22 +0700
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: Well...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I hope to get H1B visa Feb 4 and leave for
San-Francisco on Feb 6...
I'll be in Krasnoyarsk till Feb 2.
Good luck!
Vadim
From bouncefilter Wed Jan 19 00:10:33 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA07059
for <hackers@postgreSQL.org>; Wed, 19 Jan 2000 00:10:18 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id VAA15362;
Tue, 18 Jan 2000 21:32:49 -0800 (PST)
Date: Tue, 18 Jan 2000 21:32:49 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Don Baccus <dhogaza@pacifier.com>, Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>, hackers@postgreSQL.org
Subject: Re: [HACKERS] gperf anyone?
Message-ID: <20000118213249.R8736@fw.wintelcom.net>
References: <Pine.LNX.4.21.0001170003210.1636-100000@localhost.localdomain>
<3.0.1.32.20000118174928.00ef0370@mail.pacifier.com>
<3754.948256849@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <3754.948256849@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Tue, Jan 18, 2000 at 11:40:49PM -0500
* Tom Lane <tgl@sss.pgh.pa.us> [000118 21:10] wrote:
At 07:36 PM 1/18/00 -0500, Bruce Momjian wrote:
I wondered about this last, i.e. the use of GNU code since Postgres
is licensed differently.AFAIK this is no worse than using flex or bison --- the source code of
gperf is GPL'ed, but its output is not.Don Baccus <dhogaza@pacifier.com> writes:
Whether faster or slower, though, I can't imagine either method taking
noticably more than 0% of the total time to process a query, even the
most simple queries.I agree with Don that the performance benefit is likely to be
unmeasurable. Still, there could be a win: we currently have to modify
keywords.c by hand every time we have to add/delete a keyword. Does
gperf offer any aid for maintaining the keyword list? If so, that'd
be sufficient reason to switch to it...
any minimal performance boost shows over time, unfortunatly using gperf
will require that you either:
a) require gperf to be installed on a system that compiles postgresql
b) manually maintain the gperf compiled files in your CVS repo
(sort of like syscalls in FreeBSD)
Option B is not that bad at the expense of additional contributor
overhead.
I hope to be able to present some soft of bench to determine
if gperf is worth the additional effort of maintainance in the
near future.
in the meanwhile, happy hacking. :)
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
From bouncefilter Wed Jan 19 02:23:34 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA39013
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 02:23:23 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id CAA81732
for pgsql-hackers@postgresql.org; Wed, 19 Jan 2000 02:00:23 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: mr_hopkins@earthlink.net (Micheal H.)
X-Newsgroups: comp.databases.postgresql.hackers
Subject: examples not included
Message-ID: <388561b8.11364030@news.earthlink.net>
X-Newsreader: Forte Free Agent 1.11/32.235
Lines: 18
X-Complaints-To: abuse@earthlink.net
X-Trace: newsread2.prod.itd.earthlink.net 948264913 209.178.128.79 (Tue,
18 Jan 2000 22:55:13 PST)
Organization: EarthLink Network, Inc.
X-ELN-Date: Tue Jan 18 22:55:13 2000
Date: Wed, 19 Jan 2000 06:55:13 GMT
To: pgsql-hackers@postgresql.org
I recently installed postgresql-{server,devel,jdbc,odbc,perl}-6.5.3-2
and thought I see it referred to alot there was not a
/usr/doc/postgresql-6.5.3/examples directory included anywhere.
I just want a jdbc driver. I got the jdk1.1.8 that I'm running on my
win95 machine and I'd like to create a class that I can run anywhere.
postgresql-jdbc-6.5.3-2 did include jdbc6.5-1.2.jar and
jdbc6.5-1.1.jar based on rpm -ql postgresql-jdbc.
Can I get a clue as to where to get, preferrably a precompiled jdbc
driver and perhaps an indication as to how to use it. I've seen
places where the driver for postgresql is postgresql.Driver and others
where the name is postgresql95.Driver.
Thanks for the help,
I'm trying to help myself but I seem to be in need of a little nudge,
From bouncefilter Wed Jan 19 03:19:35 2000
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA79339
for <hackers@postgresql.org>; Wed, 19 Jan 2000 03:19:34 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9D3DE1.dip0.t-ipconnect.de
(root@p3E9D3DE1.dip0.t-ipconnect.de [62.157.61.225])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id JAA32223
for <hackers@postgresql.org>; Wed, 19 Jan 2000 09:21:00 +0100 (CET)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id IAA00464
for hackers@postgresql.org; Wed, 19 Jan 2000 08:42:05 +0100
Date: Wed, 19 Jan 2000 08:42:05 +0100
From: Michael Meskes <meskes@postgresql.org>
To: hackers@postgresql.org
Subject: Re: [HACKERS] gperf anyone?
Message-ID: <20000119084205.A455@fam-meskes.de>
Mail-Followup-To: hackers@postgresql.org
References: <Pine.LNX.4.21.0001170003210.1636-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <Pine.LNX.4.21.0001170003210.1636-100000@localhost.localdomain>;
from peter_e@gmx.net on Wed, Jan 19, 2000 at 12:38:18AM +0100
On Wed, Jan 19, 2000 at 12:38:18AM +0100, Peter Eisentraut wrote:
is, I'm sure the parser/scanner speed is the least of our problems. But I
thunk especially ecpg could benefit from this. Btw., gperf is used by GCC,
Why do you think ecpg would benefit more from it than the backend? :-)
Both parser are mostly the same. In fact running ecpg appears to use a lot
less time than the subsequent gcc run.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Wed Jan 19 03:20:35 2000
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA79391
for <hackers@postgresql.org>; Wed, 19 Jan 2000 03:19:41 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9D3DE1.dip0.t-ipconnect.de
(root@p3E9D3DE1.dip0.t-ipconnect.de [62.157.61.225])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id JAA32260
for <hackers@postgresql.org>; Wed, 19 Jan 2000 09:21:27 +0100 (CET)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id IAA00467
for hackers@postgresql.org; Wed, 19 Jan 2000 08:43:38 +0100
Date: Wed, 19 Jan 2000 08:43:37 +0100
From: Michael Meskes <meskes@postgresql.org>
To: hackers@postgresql.org
Subject: Re: [HACKERS] gperf anyone?
Message-ID: <20000119084337.B455@fam-meskes.de>
Mail-Followup-To: hackers@postgresql.org
References: <Pine.LNX.4.21.0001170003210.1636-100000@localhost.localdomain>
<3.0.1.32.20000118174928.00ef0370@mail.pacifier.com>
<3754.948256849@sss.pgh.pa.us>
<20000118213249.R8736@fw.wintelcom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <20000118213249.R8736@fw.wintelcom.net>;
from bright@wintelcom.net on Tue, Jan 18, 2000 at 09:32:49PM -0800
On Tue, Jan 18, 2000 at 09:32:49PM -0800, Alfred Perlstein wrote:
any minimal performance boost shows over time, unfortunatly using gperf
will require that you either:a) require gperf to be installed on a system that compiles postgresql
b) manually maintain the gperf compiled files in your CVS repo
(sort of like syscalls in FreeBSD)
Sounds like the way we handle the bison/fley files. Why not do this for
gperf as well.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Wed Jan 19 03:20:38 2000
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA79399
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 03:19:47 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9D3DE1.dip0.t-ipconnect.de
(root@p3E9D3DE1.dip0.t-ipconnect.de [62.157.61.225])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id JAA32271
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 09:21:32 +0100 (CET)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id IAA00479
for pgsql-hackers@postgresql.org; Wed, 19 Jan 2000 08:45:46 +0100
Date: Wed, 19 Jan 2000 08:45:46 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Cannot compile psql
Message-ID: <20000119084546.A471@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
References: <20000118135840.A1519@fam-meskes.de> <371.948210708@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <371.948210708@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Tue, Jan 18, 2000 at 10:51:48AM -0500
On Tue, Jan 18, 2000 at 10:51:48AM -0500, Tom Lane wrote:
Michael Meskes <meskes@postgresql.org> writes:
../../include/utils/mcxt.h:25: syntax error before `MemoryContext'
That line reads
extern DLLIMPORT MemoryContext CurrentMemoryContext;
Yes. Commenting out this line removes the message but of course gives some
compiler errors.
I'll bet you are trying to compile with a Windoze-oriented config.h
Shouldn't have that since I only run PostgreSQL in Linux.
that causes DLLIMPORT to expand to something nonempty. Try
reconfiguring.
I tried make distclean followed by a new configure to no avail.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Wed Jan 19 03:20:35 2000
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA79390
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 03:19:41 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9D3DE1.dip0.t-ipconnect.de
(root@p3E9D3DE1.dip0.t-ipconnect.de [62.157.61.225])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id JAA32261
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 09:21:27 +0100 (CET)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id IAA00482
for pgsql-hackers@postgresql.org; Wed, 19 Jan 2000 08:47:10 +0100
Date: Wed, 19 Jan 2000 08:47:10 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] patches list
Message-ID: <20000119084710.B471@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
References: <20000118162703.A2645@fam-meskes.de>
<Pine.BSF.4.05.10001181323180.1099-100000@paprika.michvhf.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <Pine.BSF.4.05.10001181323180.1099-100000@paprika.michvhf.com>;
from vev@michvhf.com on Tue, Jan 18, 2000 at 01:23:59PM -0500
On Tue, Jan 18, 2000 at 01:23:59PM -0500, Vince Vielhaber wrote:
subscribe to pgsql-loophole and you'll be able to post to any of the
lists.
Hmm, I though I was on that list. Maybe my mail was send from the wrong
address. I usually do my PostgreSQL stuff from my postgres.org account.
Unfortunately I cannot check because I deleted it.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Wed Jan 19 03:06:34 2000
Received: from hu.tm.ee (ppp237.tele2.ee [212.107.33.237])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA52922
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 03:05:57 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 8E0ED13251; Wed, 19 Jan 2000 10:11:28 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <388571B0.BDE5CC2@tm.ee>
Date: Wed, 19 Jan 2000 10:11:28 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>,
Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Status on 7.0
References: <200001190341.WAA15358@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Can I ask how our big open items for 7.0 are doing:
Long tuples/TOAST(Jan)
Foriegn keys/action buffer(Jan)
Unify date/time types(Thomas)
Outer Joins(Thomas)
Will we also have a possibility to ALTER constraints (NULL, CHECK, FOREIGN
KEY)
AFAIK, we can currently only change UNIQUE (by dropping the UNIQUE index),
--------------
Hannu
From bouncefilter Wed Jan 19 03:43:38 2000
Received: from sirius.edu.sollentuna.se (sirius.edu.sollentuna.se
[195.67.128.12]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA86265
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 03:42:57 -0500 (EST)
(envelope-from mha@sollentuna.net)
Received: by sirius.edu.sollentuna.se with Internet Mail Service (5.5.2448.0)
id <WJ7XSM5J>; Wed, 19 Jan 2000 09:42:56 +0100
Message-ID:
<215896B6B5E1CF11BC5600805FFEA821026E11C3@sirius.edu.sollentuna.se>
From: Magnus Hagander <mha@sollentuna.net>
To: "'Peter Eisentraut'" <peter_e@gmx.net>
Cc: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: RE: [PATCHES] Patch for Win32 support
Date: Wed, 19 Jan 2000 09:42:53 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Hi!
Here is a patch to bring both libpq and psql to a state
where it compiles on
win32 (native) again. A lot of things have changed, and I
have not been able
to keep up with them all, so it has been broken for quite a while.
After this patch, at least it compiles. It also talks"basic talk" to the
server, but I have not yet tested all things. Sending
queries, and using
e.g. \d or \dt works fine. The rest will have to be tested further.
It also bumps the version on libpq.dll to 7.0.Shouldn't the library version number be 2.1?
It probably should. But the previous one (the one that is out with 6.5.x) is
versioned 6.5. If we switched back to 2.1, then any sane installation
program would refuse to install that DLL if the 6.5 DLL was already
installed. Which would be bad.
//Magnus
From bouncefilter Wed Jan 19 03:43:37 2000
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net
[194.217.242.39]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA86280
for <hackers@postgresql.org>; Wed, 19 Jan 2000 03:43:08 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1)
id 12Aqhn-000BES-0B
for hackers@postgreSQL.org; Wed, 19 Jan 2000 08:43:07 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id IAA23955; Wed, 19 Jan 2000 08:42:59 GMT
Message-Id: <200001190842.IAA23955@mtcc.demon.co.uk>
Date: Wed, 19 Jan 2000 08:42:59 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Solaris breakage - lastest CVS
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: xEF5hX1rOXRm3W+aaoZ4YQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc
The latest source does not compile on Solaris 7 due to
a missing include from a modified file.
Here is a patch to fix it:-
Keith.
*** src/backend/utils/init/miscinit.c.orig Sun Jan 16 12:23:42 2000
--- src/backend/utils/init/miscinit.c Sun Jan 16 12:27:01 2000
***************
*** 18,23 ****
--- 18,24 ----
#include <signal.h>
#include <sys/stat.h>
#include <sys/file.h>
+ #include <fcntl.h>
#include <unistd.h>
#include <grp.h>
#include <pwd.h>From bouncefilter Wed Jan 19 05:24:36 2000
Received: from onestone.elsinore.klever.net (root@onestone.elsinore.klever.net
[207.175.129.2]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA06903
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 05:24:29 -0500 (EST)
(envelope-from sbirch@ironmountainsystems.com)
Received: from ironmountainsystems.com (ppp81.kross.klever.net
[209.203.65.81]) by onestone.elsinore.klever.net (8.8.7/8.8.0)
with ESMTP id CAA05781 for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 02:23:31 -0800
Sender: sbirch@onestone.elsinore.klever.net
Message-ID: <388590A6.5FD564D1@ironmountainsystems.com>
Date: Wed, 19 Jan 2000 02:23:34 -0800
From: Stephen Birch <sbirch@ironmountainsystems.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-SMP i686)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-hackers <pgsql-hackers@postgreSQL.org>
Subject: Daily regression testing via vmware - useful?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
What is the current state of regression testing on the CVS tree? Are
the regression tests performed once in a while, or routinely? If
performed once in a while, perhaps the following would idea would be of
interest:
I am kicking around the idea of using one of my old machines (a P90) to
run nightly regression tests on the CVS tree. The idea would be to use
vmware to set up multiple virtual machines, one for each OS or
distribution (Linux clib, Linux glib, FreeBSD, etc. etc.). Perhaps
even multiple versions of the same OS/dist (RH6.0, RH6.1, SuSE 6.1, SuSE
6.2) to catch subtle changes between versions if they are known to be a
problem.
That way, I could conduct a daily automatic regression test on them all.
A program (probably python) would combine the outputs into an HTML table
of OS version vs. test result. All developers would then be able to
keep an eye on the effects their changes have on other platforms.
Would this be of value , or waste of effort ????
Steve
PS
Looks like I am going to be offline for about 3 weeks so will not be
able to pick up replies to this question until I get back. If you
reply, be sure to Cc sbirch@ironmountainsystems.com so I don't lose the
reply.
From bouncefilter Wed Jan 19 05:48:36 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA12103
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 05:47:50 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id LAA258650;
Wed, 19 Jan 2000 11:46:23 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALNV2V>; Wed, 19 Jan 2000 11:46:21 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC210@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Bruce Momjian'" <pgman@candle.pha.pa.us>
Cc: "'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] [hackers]development suggestion needed (filepath as
symlink)
Date: Wed, 19 Jan 2000 11:46:19 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
Yes, that's about the sum of it. Why not the links? I think
that it's an elegant way of designing the whole thing.The only problem with symlinks is, that it does not solve the
"too many files in one directory to give optimal performance"
problem for those that have tons of tables.Andreas
Is that really a problem on modern operating systems?
Yes, in this regard most OS's (not only Unix) are quite old in their design.
(A . file, that has a sorted list of files and stats)
The problem starts to get severe at about 3000 - 10000 files,
depending on the average filename length.
Change one file --> write whole dirfile.
Depending on the system simple file create or fstat
drops to 3 files per second or worse.
Once the files are in cache, the performance is usually
good again.
But imho 300 ms for a temp file create is way too much.
Maybe we could only put the temp files in a different directory.
They are where performance matters.
If a normal table create takes a few seconds that is not a real problem.
We could actually
hash the file names into directory buckets and access them
that way, and have one directory that old symlinks to the hashed files.
You can't have the one directory. It makes no difference whether
that dir has 5000 symlinks or 5000 files performance wise.
Andreas
From bouncefilter Wed Jan 19 06:31:37 2000
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 GAA23795
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 06:31:03 -0500 (EST)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
id 12AtKI-000I93-0A; Wed, 19 Jan 2000 11:31:02 +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 MAA27457;
Wed, 19 Jan 2000 12:25:24 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <DGMMGMH0>; Wed, 19 Jan 2000 11:30:30 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70C0E9@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Bruce Momjian'" <pgman@candle.pha.pa.us>, "Thomas G. Lockhart"
<lockhart@alumni.caltech.edu>, Jan Wieck <jwieck@debis.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] Status on 7.0
Date: Wed, 19 Jan 2000 11:30:25 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Well, I'm hoping to have the 7.0 version of JDBC ready before next
Wednesday (26th). Also, I've just agreed with Assaf to add his
extensions in on Monday as both of us are around (just got to sort out
the time zones).
The only bit that will need sorting out afterwards is handling the
date/time changes, but I can wait until that's settled, but it has to be
done before 7.0.
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:pgman@candle.pha.pa.us]
Sent: Wednesday, January 19, 2000 3:42 AM
To: Thomas G. Lockhart; Jan Wieck
Cc: PostgreSQL-development
Subject: [HACKERS] Status on 7.0
Can I ask how our big open items for 7.0 are doing:
Long tuples/TOAST(Jan)
Foriegn keys/action buffer(Jan)
Unify date/time types(Thomas)
Outer Joins(Thomas)
I am only asking to know if we should continue with the planned Feb 1
beta?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania
19026************
From bouncefilter Wed Jan 19 06:42:37 2000
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 GAA25162
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 06:41:39 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <CZZ0MD95>; Wed, 19 Jan 2000 13:37:57 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C45C@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Stephen Birch'" <sbirch@ironmountainsystems.com>, PostgreSQL-hackers
<pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Daily regression testing via vmware - useful?
Date: Wed, 19 Jan 2000 13:31:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
I suspect that it would be of value, however, remember that you are
constrained to those OSes that run on Intel chips, and at the moment, I
believe, only a subset of those. I know that Linux can host winnt, win2k,
linux, Solaris, and possibly one or two others. I'm not sure how well
things like BSD would do, although they would probably do OK. However, you
won't be able to test under HP-UX 11, for instance, unless you can get for
Intel, which I don't think you can.
MikeA
-----Original Message-----
From: Stephen Birch [mailto:sbirch@ironmountainsystems.com]
Sent: Wednesday, January 19, 2000 12:24 PM
To: PostgreSQL-hackers
Subject: [HACKERS] Daily regression testing via vmware - useful?What is the current state of regression testing on the CVS tree? Are
the regression tests performed once in a while, or routinely? If
performed once in a while, perhaps the following would idea
would be of
interest:I am kicking around the idea of using one of my old machines
(a P90) to
run nightly regression tests on the CVS tree. The idea
would be to use
vmware to set up multiple virtual machines, one for each OS or
distribution (Linux clib, Linux glib, FreeBSD, etc. etc.). Perhaps
even multiple versions of the same OS/dist (RH6.0, RH6.1,
SuSE 6.1, SuSE
6.2) to catch subtle changes between versions if they are
known to be a
problem.That way, I could conduct a daily automatic regression test
on them all.A program (probably python) would combine the outputs into
an HTML table
of OS version vs. test result. All developers would then be able to
keep an eye on the effects their changes have on other platforms.Would this be of value , or waste of effort ????
Steve
PS
Looks like I am going to be offline for about 3 weeks so will not be
able to pick up replies to this question until I get back. If you
reply, be sure to Cc sbirch@ironmountainsystems.com so I
don't lose the
reply.************
From bouncefilter Wed Jan 19 06:58:37 2000
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 GAA27270
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 06:58:16 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <CZZ0M1AX>; Wed, 19 Jan 2000 13:52:56 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C45D@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Zeugswetter Andreas SB'" <ZeugswetterA@wien.spardat.at>,
"'Bruce Momjian'" <pgman@candle.pha.pa.us>
Cc: "'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] [hackers]development suggestion needed (filepath as
symlink)
Date: Wed, 19 Jan 2000 13:40:04 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Maybe we could only put the temp files in a different directory.
They are where performance matters.
If a normal table create takes a few seconds that is not a
real problem.
Once you have the ability to create tablespaces, you can modify the temp
table thingy a little to create temporary tables in the temp tablespace. If
there is no explicit temp tablespace defined, then it defaults to the system
tablespace (which is where it goes now anyway).
What this means is that tablespaces must have a flag indicating whether or
not they are the temp tablespace or not (only one per database). Also, it's
handy to have a default tablespace for each user, so that tables are created
in whichever tablespace is the default for that user, unless they explicitly
state which tablespace to use.
We could actually
hash the file names into directory buckets and access them
that way, and have one directory that old symlinks to the
hashed files.
I don't think this is necessary, because if you have a system that requires
this kind of action, then the administrator can create a temp tablespace
which is used for all the temporary tables, and spread the rest of the
tables and indices among the remaining tablespaces.
MikeA
From bouncefilter Wed Jan 19 06:53:37 2000
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 GAA26742;
Wed, 19 Jan 2000 06:53:15 -0500 (EST)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 12Atfk-000DAm-0C; Wed, 19 Jan 2000 11:53:12 +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 MAA27569;
Wed, 19 Jan 2000 12:47:34 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <DGMMGM23>; Wed, 19 Jan 2000 11:52:39 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70C0EA@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "PostgreSQL Developers List (E-mail)" <hackers@postgresql.org>,
"PostgreSQL Interfaces (E-mail)" <pgsql-hackers@postgresql.org>
Subject: Proposed change to the JDBC driver
Date: Wed, 19 Jan 2000 11:52:36 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
I'm sending this to both the hackers and interfaces lists as this
affects the 7.0 release and an interface.
Ok, up until now the driver has operated under a base package of
postgresql. This has worked fine so far but technically breaks Sun's
rules on package naming. The rule is that any organisations package
names begins with their domain name. This prevents two different package
names from clashing.
Ie: My own classes always begin with uk.org.retep as my own domain is
retep.org.uk. The classes I write here begin with uk.gov.maidstone.
Now, what I'm thinking is that as the 7.0 driver isn't going to be
compatible with earlier backends (mainly due to the core changes like
date/time handling, but there are others), I'm proposing to change our
base package name from postgresql to org.postgresql so that we comply
with this rule (which has been around since Java first came out).
All this involves in the source is to create an empty directory called
org, and move the original postgresql directory into it. Then each .java
file will need org. prefixed to the package name.
The down side, is that any existing source that uses the driver will
need amending so that either the Class.forName() line reads:
Class.forName("org.postgresql");
or if it's supplied as a parameter (which is my prefered way) the org.
added.
Now because of this downside, I want to see what everyone thinks about
making this change before I do it, as I have a lot of things to do to
the source to implement it, but it would be better to do it now,
especially as it's the first new major release since JDBC was included.
Peter
--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.
From bouncefilter Wed Jan 19 07:15:37 2000
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 HAA35344
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 07:14:53 -0500 (EST)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 12Au0i-000FRn-0C
for pgsql-hackers@postgreSQL.org; Wed, 19 Jan 2000 12:14:52 +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 NAA27639
for <pgsql-hackers@postgreSQL.org>; Wed, 19 Jan 2000 13:09:15 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <DGMMGM2X>; Wed, 19 Jan 2000 12:14:20 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70C0EB@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: PostgreSQL-hackers <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] Daily regression testing via vmware - useful?
Date: Wed, 19 Jan 2000 12:14:17 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
I'm planning on using VMWare to allow me to have different version JVM's
running when I start testing JDBC fully next week. It's easier to have
just one JVM on an installation.
As for BSD, I thought I saw some screen shots somewhere with it running?
Peter
--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.
-----Original Message-----
From: Ansley, Michael [mailto:Michael.Ansley@intec.co.za]
Sent: Wednesday, January 19, 2000 11:31 AM
To: 'Stephen Birch'; PostgreSQL-hackers
Subject: RE: [HACKERS] Daily regression testing via vmware - useful?
I suspect that it would be of value, however, remember that you are
constrained to those OSes that run on Intel chips, and at the moment, I
believe, only a subset of those. I know that Linux can host winnt,
win2k,
linux, Solaris, and possibly one or two others. I'm not sure how well
things like BSD would do, although they would probably do OK. However,
you
won't be able to test under HP-UX 11, for instance, unless you can get
for
Intel, which I don't think you can.
MikeA
-----Original Message-----
From: Stephen Birch [mailto:sbirch@ironmountainsystems.com]
Sent: Wednesday, January 19, 2000 12:24 PM
To: PostgreSQL-hackers
Subject: [HACKERS] Daily regression testing via vmware - useful?What is the current state of regression testing on the CVS tree? Are
the regression tests performed once in a while, or routinely? If
performed once in a while, perhaps the following would idea
would be of
interest:I am kicking around the idea of using one of my old machines
(a P90) to
run nightly regression tests on the CVS tree. The idea
would be to use
vmware to set up multiple virtual machines, one for each OS or
distribution (Linux clib, Linux glib, FreeBSD, etc. etc.). Perhaps
even multiple versions of the same OS/dist (RH6.0, RH6.1,
SuSE 6.1, SuSE
6.2) to catch subtle changes between versions if they are
known to be a
problem.That way, I could conduct a daily automatic regression test
on them all.A program (probably python) would combine the outputs into
an HTML table
of OS version vs. test result. All developers would then be able to
keep an eye on the effects their changes have on other platforms.Would this be of value , or waste of effort ????
Steve
PS
Looks like I am going to be offline for about 3 weeks so will not be
able to pick up replies to this question until I get back. If you
reply, be sure to Cc sbirch@ironmountainsystems.com so I
don't lose the
reply.************
************
From bouncefilter Wed Jan 19 08:38:38 2000
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA59644
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 08:37:56 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (sfcabop1.nettuno.it [193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id OAA10828
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 14:37:48 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 12AwDz-0005dK-00; Wed, 19 Jan 2000 14:36:43 +0000
Message-ID: <3885BEAF.10F40BD4@sferacarta.com>
Date: Wed, 19 Jan 2000 14:39:59 +0100
From: Jose Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] date/time problem in v6.5.3 and 7.0.0 ...
References: <Pine.BSF.4.21.0001142201470.46499-100000@thelab.hub.org>
<38847472.DC3C84AA@sferacarta.com>
<38847B5B.DA4BEE00@alumni.caltech.edu>
<20000119103518I.t-ishii@sra.co.jp>
<38851FFF.63E90AE4@alumni.caltech.edu>
Content-Type: multipart/mixed; boundary="------------FF92B6980629932135867A40"
This is a multi-part message in MIME format.
--------------FF92B6980629932135867A40
Content-Type: multipart/alternative;
boundary="------------5E16542CBEB3A3B853872ED0"
--------------5E16542CBEB3A3B853872ED0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
This table shows every legal operation between datetimes and intervals and
vice versa
allowed by SQL92:
-----------------------------------------
1st operand|operator|2nd operand|result
-----------+--------+-----------+--------
datetime | - |datetime |interval
datetime | + |interval |datetime
datetime | - |interval |datetime
interval | + |datetime |datetime
interval | + |interval |interval
interval | - |interval |interval
interval | * |number |interval
interval | / |number |interval
number | * |interval |interval
-----------+--------+-----------+--------
I wrote some pgPL/SQL functions to create operators between datetimes and
intervals.
Probably there's a better way to achieve that goal, but this works anyway.
Jos���
Thomas Lockhart wrote:
I can add days to now(), but not subtract?
The problem is that it is meaningful to subtract two absolute times,
giving a delta time as a result, *and* it is meaningful to subtract a
delta time from an absolute time, giving another absolute time as a
result.It would be nice if we could decide '30 days' is a delta time because
it is not suitable for an absolute time representation. Would it be
hard?Hmm. I'm not sure how hard it would be. The places where types need to
be matched to operators are fairly well isolated in the parser.
However, we would need a new kind of input function which does not
throw an elog(ERROR), but rather just returns failure if the input
does not get decoded. Then, we could accumulate a list of successfully
decoded types (based on our list of candidate operators), and if that
list is of length one then we have a match.One way to implement this would be to define an additional input
routine (which the existing input routine would use) which returns an
error rather than throwing an elog() error. Then, our parser could use
this additional routine to discriminate between the candidate types.
The input routine could be found in a similar way to our existing
"implicit coersion" code, which assumes a specific function name for
each type.The downside to this is that we have built up one additional
assumption about the form and contents of our system tables. But,
since it adds functionality that probably isn't a bad thing.I do know I'm not likely to find time to work on it for the next
release...- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California************
--------------5E16542CBEB3A3B853872ED0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>This table shows every legal operation between datetimes and intervals
and vice versa</tt>
<br><tt>allowed by SQL92:</tt><tt></tt>
<p><tt>-----------------------------------------</tt>
<br><tt>1st operand|operator|2nd operand|result</tt>
<br><tt>-----------+--------+-----------+--------</tt>
<br><tt>datetime | - |datetime
|interval</tt>
<br><tt>datetime | + |interval
|datetime</tt>
<br><tt>datetime | - |interval
|datetime</tt>
<br><tt>interval | + |datetime
|datetime</tt>
<br><tt>interval | + |interval
|interval</tt>
<br><tt>interval | - |interval
|interval</tt>
<br><tt>interval | * |number
|interval</tt>
<br><tt>interval | / |number
|interval</tt>
<br><tt>number | *
|interval |interval</tt>
<br><tt>-----------+--------+-----------+--------</tt>
<p>I wrote some pgPL/SQL functions to create operators between datetimes
and intervals.
<br>Probably there's a better way to achieve that goal, but this works
anyway.
<p>José
<br>
<br>
<p>Thomas Lockhart wrote:
<blockquote TYPE=CITE>> > > > I can add days to now(), but not subtract?
<br>> > The problem is that it is meaningful to subtract two absolute times,
<br>> > giving a delta time as a result, *and* it is meaningful to subtract
a
<br>> > delta time from an absolute time, giving another absolute time
as a
<br>> > result.
<br>> It would be nice if we could decide '30 days' is a delta time because
<br>> it is not suitable for an absolute time representation. Would it
be
<br>> hard?
<p>Hmm. I'm not sure how hard it would be. The places where types need
to
<br>be matched to operators are fairly well isolated in the parser.
<br>However, we would need a new kind of input function which does not
<br>throw an elog(ERROR), but rather just returns failure if the input
<br>does not get decoded. Then, we could accumulate a list of successfully
<br>decoded types (based on our list of candidate operators), and if that
<br>list is of length one then we have a match.
<p>One way to implement this would be to define an additional input
<br>routine (which the existing input routine would use) which returns
an
<br>error rather than throwing an elog() error. Then, our parser could
use
<br>this additional routine to discriminate between the candidate types.
<br>The input routine could be found in a similar way to our existing
<br>"implicit coersion" code, which assumes a specific function name for
<br>each type.
<p>The downside to this is that we have built up one additional
<br>assumption about the form and contents of our system tables. But,
<br>since it adds functionality that probably isn't a bad thing.
<p>I do know I'm not likely to find time to work on it for the next
<br>release...
<p>
- Thomas
<p>--
<br>Thomas Lockhart
lockhart@alumni.caltech.edu
<br>South Pasadena, California
<p>************</blockquote>
</html>
--------------5E16542CBEB3A3B853872ED0--
--------------FF92B6980629932135867A40
Content-Type: text/plain; charset=us-ascii;
name="interval.sql"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="interval.sql"
-- These functions create SQL92 operators between datetime and interval
-- and vice versa:
-- -----------------------------------------
-- 1st operand|operator|2nd operand|result
-- -----------+--------+-----------+--------
-- datetime | - |datetime |interval
-- datetime | + |interval |datetime
-- datetime | - |interval |datetime
-- interval | + |datetime |datetime
-- interval | + |interval |interval
-- interval | - |interval |interval
-- interval | * |number |interval
-- interval | / |number |interval
-- number | * |interval |interval
-- -----------+--------+-----------+--------
set datestyle to 'iso';
--DATE + INTERVAL = DATE----------------------------------------------------
drop function date_pl_interval(date,timespan);
create function date_pl_interval(date,timespan) returns date as
'
begin
return date(datetime_pl_span($1,$2));
end; ' language 'plpgsql';
drop operator + (date,timespan);
create operator + (
leftarg=date,
rightarg=timespan,
procedure=date_pl_interval,
commutator='+',
negator='-',
restrict=eqsel,
join=eqjoinsel
);
--DATE - INTERVAL = DATE----------------------------------------------------
drop function date_mi_interval(date,timespan);
create function date_mi_interval(date,timespan) returns date as
'
begin
return date(datetime_mi_span($1,$2));
end; ' language 'plpgsql';
drop operator - (date,timespan);
create operator - (
leftarg=date,
rightarg=timespan,
procedure=date_mi_interval,
commutator='-',
negator='+',
restrict=eqsel,
join=eqjoinsel
);
--INTERVAL + DATE = DATE----------------------------------------------------
drop function interval_pl_date(timespan,date);
create function interval_pl_date(timespan,date) returns date as
'
begin
return date(datetime_pl_span($2,$1));
end; ' language 'plpgsql';
drop operator + (timespan,date);
create operator + (
leftarg=timespan,
rightarg=date,
procedure=interval_pl_date,
commutator='+',
negator='-',
restrict=eqsel,
join=eqjoinsel
);
--INTERVAL + TIMESTAMP = TIMESTAMP-----------------------------------------------
drop function interval_pl_timestamp(timespan,timestamp);
create function interval_pl_timestamp(timespan,timestamp) returns timestamp as
'
begin
return datetime_pl_span($2,$1);
end; ' language 'plpgsql';
drop operator + (timespan,timestamp);
create operator + (
leftarg=timespan,
rightarg=timestamp,
procedure=interval_pl_timestamp,
commutator='+',
negator='-',
restrict=eqsel,
join=eqjoinsel
);
--INTERVAL / NUMBER = INTERVAL------------------------------------------------
drop function interval_div_int4(timespan,integer);
create function interval_div_int4(timespan,integer) returns timespan as
'
begin
return timespan_div($1,float8($2));
end; ' language 'plpgsql';
drop operator / (timespan,int4);
create operator / (
leftarg=timespan,
rightarg=int4,
procedure=interval_div_int4,
commutator='/',
negator='*',
restrict=eqsel,
join=eqjoinsel
);
drop operator / (timespan,float8);
create operator / (
leftarg=timespan,
rightarg=float8,
procedure=timespan_div,
commutator='/',
negator='*',
restrict=eqsel,
join=eqjoinsel
);
--NUMBER * INTERVAL = INTERVAL------------------------------------------------
drop function float8_mul_interval(float8,timespan);
create function float8_mul_interval(float8,timespan) returns timespan as
'declare
i float8;
begin
i:= date_part(''epoch'',$2);
return i * $1;
end;
' language 'plpgsql';
drop function int4_mul_interval(integer,timespan);
create function int4_mul_interval(integer,timespan) returns timespan as
'
begin
return float8_mul_interval(float8($1),$2);
end;
' language 'plpgsql';
drop operator * (float8,timespan);
create operator * (
leftarg=float8,
rightarg=timespan,
procedure=float8_mul_interval,
commutator='*',
negator='/',
restrict=eqsel,
join=eqjoinsel
);
drop operator * (int4,timespan);
create operator * (
leftarg=int4,
rightarg=timespan,
procedure=int4_mul_interval,
commutator='*',
negator='/',
restrict=eqsel,
join=eqjoinsel
);
--INTERVAL * NUMBER = INTERVAL------------------------------------------------
drop function interval_mul_float8(timespan,float8);
create function interval_mul_float8(timespan,float8) returns timespan as
'declare
i float8;
begin
i:= date_part(''epoch'',$1);
return i * $2;
end;
' language 'plpgsql';
drop function interval_mul_int4(timespan,integer);
create function interval_mul_int4(timespan,integer) returns timespan as
'
begin
return interval_mul_float8($1,float8($2));
end;
' language 'plpgsql';
drop operator * (timespan,int4);
create operator * (
leftarg=timespan,
rightarg=int4,
procedure=interval_mul_int4,
commutator='*',
negator='/',
restrict=eqsel,
join=eqjoinsel
);
drop operator * (timespan,float8);
create operator * (
leftarg=timespan,
rightarg=float8,
procedure=interval_mul_float8,
commutator='*',
negator='/',
restrict=eqsel,
join=eqjoinsel
);
--TIME + INTERVAL = TIME-----------------------------------time??
drop function time_pl_interval(time,timespan);
create function time_pl_interval(time,timespan) returns time as
'
declare
i1 timespan;
i2 timespan;
begin
i1:= $1;
i2:= $2;
i1:=i1 + i2;
return i1;
end;
' language 'plpgsql';
drop operator + (time,timespan);
create operator + (
leftarg=time,
rightarg=timespan,
procedure=time_pl_interval,
commutator='+',
negator='-',
restrict=eqsel,
join=eqjoinsel
);
--INTERVAL + TIME = TIME------------------------------------------------
drop function interval_pl_time(timespan,time);
create function interval_pl_time(timespan,time) returns time as
'
begin
return $2 + $1;
end;
' language 'plpgsql';
drop operator + (timespan,time);
create operator + (
leftarg=timespan,
rightarg=time,
procedure=interval_pl_time,
commutator='+',
negator='-',
restrict=eqsel,
join=eqjoinsel
);
--TIME - TIME = INTERVAL-------------------------------------------
drop function time_mi_time(time,time);
create function time_mi_time(time,time) returns timespan as
'
declare
i1 interval;
i2 interval;
begin
i1:= $1;
i2:= $2;
i1:=i1 - i2;
return i1;
end;
' language 'plpgsql';
drop operator - (time,time);
create operator - (
leftarg=time,
rightarg=time,
procedure=time_mi_time,
commutator='-',
negator='+',
restrict=eqsel,
join=eqjoinsel
);
--TIME - INTERVAL = TIME------------------------------------------------
drop function time_mi_interval(time,timespan);
create function time_mi_interval(time,timespan) returns time as
'
declare
i2 time;
begin
i2:= $2;
return $1 - i2;
end;
' language 'plpgsql';
drop operator - (time,timespan);
create operator - (
leftarg=time,
rightarg=timespan,
procedure=time_mi_interval,
commutator='-',
negator='+',
restrict=eqsel,
join=eqjoinsel
);
--TIMESTAMP + INTERVAL = TIMESTAMP-------------------------------------------
drop function timestamp_pl_interval(timestamp,timespan);
create function timestamp_pl_interval(timestamp,timespan) returns timestamp as
'
begin
return datetime_pl_span($1,$2);
end;
' language 'plpgsql';
drop operator + (timestamp,timespan);
create operator + (
leftarg=timestamp,
rightarg=timespan,
procedure=timestamp_pl_interval,
commutator='+',
negator='-',
restrict=eqsel,
join=eqjoinsel
);
--TIMESTAMP - INTERVAL = TIMESTAMP----------------------------------------------
drop function timestamp_mi_interval(timestamp,timespan);
create function timestamp_mi_interval(timestamp,timespan) returns timestamp as
'
begin
return datetime_mi_span($1,$2);
end; ' language 'plpgsql';
drop operator - (timestamp,timespan);
create operator - (
leftarg=timestamp,
rightarg=timespan,
procedure=timestamp_mi_interval,
commutator='-',
negator='+',
restrict=eqsel,
join=eqjoinsel
);
--TIMESTAMP - TIMESTAMP = INTERVAL-----------------------------------------------
drop function timestamp_mi_timestamp(timestamp,timestamp);
create function timestamp_mi_timestamp(timestamp,timestamp) returns timespan as
'
declare
i1 timespan;
i2 timespan;
begin
i1:= datetime_part(''epoch'',$1);
i2:= datetime_part(''epoch'',$2);
return i1 - i2;
end;
' language 'plpgsql';
drop operator - (timestamp,timestamp);
create operator - (
leftarg=timestamp,
rightarg=timestamp,
procedure=timestamp_mi_timestamp,
commutator='-',
negator='+',
restrict=eqsel,
join=eqjoinsel
);
--EXAMPLES--------------------------------------------------------------------
--datetimes + interval
SELECT DATE '1999-02-11' + INTERVAL '1 MONTH' as "date 1999-03-11";
SELECT TIME '15:00:00' + INTERVAL '1 HOUR' as "16:00:00 time";
SELECT TIMESTAMP '1999-02-11 15:00:00' + INTERVAL '1 MONTH' as "1999-03-11 15:00:00+01 timestamp";
--datetimes - datetime
SELECT DATE '1999-02-11' - DATE '1999-02-01' as "interval 10";
SELECT TIME '15:00:00'- TIME '01:30:00' as "13:30 interval";
SELECT TIMESTAMP '1999-02-11 15:00:00'- TIMESTAMP '1999-02-01 01:30:00' as "10 13:30 interval";
--datetimes - interval
SELECT DATE '1999-02-11' - INTERVAL '1 MONTH' as "date 1999-01-11";
SELECT TIME '15:00:00'- INTERVAL '1 HOUR' as "14:00:00 time";
SELECT TIMESTAMP '1999-02-11 15:00:00'- INTERVAL '1 MONTH' as "1999-01-11 15:00:00+01 timestamp";
--interval + datetime
SELECT INTERVAL '1 DAY' + DATE '1999-02-11' as "date 1999-02-12";
SELECT INTERVAL '3 hour' + TIME '15:00:00' as "18:00:00 time";
SELECT INTERVAL '3 HOUR' + TIMESTAMP '1999-02-11 15:00:00' as "1999-02-11 18:00:00+01 timestamp";
--interval + interval
SELECT INTERVAL '3 hour' + INTERVAL '1 hour' as "04:00 interval";
--interval - interval
SELECT INTERVAL '4 hour' - INTERVAL '3 hour' as "01:00 interval";
--interval / number
SELECT INTERVAL '4 hour' / 2.0 as "02:00 interval";
--interval * number
SELECT INTERVAL '4 hour' * 3 as "12:00 interval";
--number * interval
SELECT 3 * INTERVAL '4 hour' as "12:00 interval";
--------------FF92B6980629932135867A40--
From bouncefilter Wed Jan 19 09:02:38 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA66339
for <hackers@postgreSQL.org>; Wed, 19 Jan 2000 09:01:52 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
JAA05689;
Wed, 19 Jan 2000 09:01:05 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001191401.JAA05689@candle.pha.pa.us>
Subject: Re: [HACKERS] Solaris breakage - lastest CVS
In-Reply-To: <200001190842.IAA23955@mtcc.demon.co.uk> from Keith Parks at "Jan
19, 2000 08:42:59 am"
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Date: Wed, 19 Jan 2000 09:01:05 -0500 (EST)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Applied.
The latest source does not compile on Solaris 7 due to
a missing include from a modified file.Here is a patch to fix it:-
Keith.
*** src/backend/utils/init/miscinit.c.orig Sun Jan 16 12:23:42 2000 --- src/backend/utils/init/miscinit.c Sun Jan 16 12:27:01 2000 *************** *** 18,23 **** --- 18,24 ---- #include <signal.h> #include <sys/stat.h> #include <sys/file.h> + #include <fcntl.h> #include <unistd.h> #include <grp.h> #include <pwd.h>************
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Jan 19 09:56:40 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA76774;
Wed, 19 Jan 2000 09:55:46 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id JAA09747;
Wed, 19 Jan 2000 09:55:45 -0500 (EST)
To: Michael Meskes <meskes@postgreSQL.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Cannot compile psql
In-reply-to: <20000119084546.A471@fam-meskes.de>
References: <20000118135840.A1519@fam-meskes.de> <371.948210708@sss.pgh.pa.us>
<20000119084546.A471@fam-meskes.de>
Comments: In-reply-to Michael Meskes <meskes@postgreSQL.org>
message dated "Wed, 19 Jan 2000 08:45:46 +0100"
Date: Wed, 19 Jan 2000 09:55:45 -0500
Message-ID: <9744.948293745@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Meskes <meskes@postgreSQL.org> writes:
On Tue, Jan 18, 2000 at 10:51:48AM -0500, Tom Lane wrote:
I'll bet you are trying to compile with a Windoze-oriented config.h
that causes DLLIMPORT to expand to something nonempty. Try
reconfiguring.
I tried make distclean followed by a new configure to no avail.
Hmm. Look at the bottom of include/c.h --- it should be impossible
for DLLIMPORT to be nonempty unless __CYGWIN32__ is defined. So where
is that definition coming from?
regards, tom lane
From bouncefilter Wed Jan 19 10:20:40 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA83222
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 10:20:14 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA25007;
Wed, 19 Jan 2000 15:27:41 GMT
Sender: lockhart@hub.org
Message-ID: <3885D7ED.EDE3D097@alumni.caltech.edu>
Date: Wed, 19 Jan 2000 15:27:41 +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 <pgman@candle.pha.pa.us>
CC: Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: Status on 7.0
References: <200001190341.WAA15358@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Can I ask how our big open items for 7.0 are doing:
Unify date/time types(Thomas)
Will do this after getting the outer join syntax going...
Outer Joins(Thomas)
I've finally gotten back to work on this in the last couple of days.
Remember, at the moment I've only committed to getting *syntax*, but
that we were hoping to push this into the planner/optimizer/executor
soon after.
I am only asking to know if we should continue with the planned Feb 1
beta?
I'll be able to do the date/time unification once my parser is back
together and stable (no point in doing it earlier because I'll need a
stable parser to follow up on problem reports). Not sure about making
Feb 1, though I'll guess that the date/time unification is a couple of
days work once I start.
Remember that I'll need two weeks or so to package the docs before
final release, so will need some padding at the end of beta without
too much distraction from other problem reports :(
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Jan 19 10:35:47 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA89110
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 10:35:26 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA09867
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 10:35:18 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Should cast to CHAR or NUMERIC enforce default length limit?
Date: Wed, 19 Jan 2000 10:35:18 -0500
Message-ID: <9864.948296118@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Now that I've modified the code so that casting to a specific length
actually works --- ie you can do
x :: char(7)
CAST (y AS numeric(40,6))
and get the expected results --- I am starting to worry that there
may be unwanted side-effects. The reason is that the system by default
interprets "char" as "char(1)" and "numeric" as "numeric(30,6)".
So if you just write "x::char" you will now get truncation to one
character, which did not use to happen. Another distressing example
is
regression=# select '123456789012345678901234567890.12'::numeric;
ERROR: overflow on numeric ABS(value) >= 10^29 for field with precision 30 scale 6
which I think is arguably a violation of the SQL standard --- it says
pretty clearly that the precision and scale of a numeric constant are
whatever is implicit in the number of digits.
I am inclined to think that in the context of a cast, we shouldn't
enforce a coercion to default length, but should only coerce if a length
is explicitly specified. This would change the behavior of "x::char"
back to what it was.
I think this could be done by having gram.y insert -1 as the default
typmod for a "char" or "numeric" Typename. The rest of the system
already interprets such a typmod as specifying no particular length
constraint. Then, to preserve the rule that
create table foo (bar char);
creates a char(1) field, analyze.c would have to be responsible for
inserting the appropriate default length in place of -1 when processing
a column definition.
Comments? Better ideas?
regards, tom lane
From bouncefilter Wed Jan 19 10:33:39 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA88598
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 10:32:57 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA25035;
Wed, 19 Jan 2000 15:40:11 GMT
Sender: lockhart@hub.org
Message-ID: <3885DADB.F529766C@alumni.caltech.edu>
Date: Wed, 19 Jan 2000 15:40:11 +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 <pgman@candle.pha.pa.us>
CC: Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: Status on 7.0
References: <200001190341.WAA15358@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Can I ask how our big open items for 7.0 are doing:
istm that pg_dump could benefit greatly if it translated internal
Postgres type names to the SQL92-standard names. For example, int4 ->
integer, int8 -> bigint, etc. This would be analogous to the
translation we do when parsing queries in the backend, converting
(e.g.) integer -> int4.
This feature would make it a bit easier to move databases around, esp.
away from Postgres for those who have to...
Anyone interested in looking at this? If not, can you add it to the
ToDo Bruce?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Jan 19 10:51:40 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA92583
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 10:50:46 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA09921;
Wed, 19 Jan 2000 10:50:21 -0500 (EST)
To: Stephen Birch <sbirch@ironmountainsystems.com>
cc: PostgreSQL-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Daily regression testing via vmware - useful?
In-reply-to: <388590A6.5FD564D1@ironmountainsystems.com>
References: <388590A6.5FD564D1@ironmountainsystems.com>
Comments: In-reply-to Stephen Birch <sbirch@ironmountainsystems.com>
message dated "Wed, 19 Jan 2000 02:23:34 -0800"
Date: Wed, 19 Jan 2000 10:50:20 -0500
Message-ID: <9918.948297020@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Stephen Birch <sbirch@ironmountainsystems.com> writes:
What is the current state of regression testing on the CVS tree? Are
the regression tests performed once in a while, or routinely?
I make a practice of running them whenever I pull a cvs update (once or
twice a week usually), and before I commit any changes. I hope other
developers run them fairly routinely as well.
I am kicking around the idea of using one of my old machines (a P90) to
run nightly regression tests on the CVS tree.
I think this might be a good thing to do, even though as MikeA points
out, coverage of only Intel-based platforms isn't all that impressive.
(At least not to those of us who use non-Intel platforms.) If the
idea seems to work out, perhaps other people could be persuaded to
contribute cycles on non-Intel boxes.
There are other open-source projects running automated regression tests
this way; Mozilla is probably the most visible example. As far as I've
heard, it's been useful for them. If you can set it up without too much
work, I'd say give it a try, and we'll find out whether it helps us or
not. We can always drop the experiment if it seems not to help.
regards, tom lane
From bouncefilter Wed Jan 19 11:16:40 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA00700
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 11:16:15 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA25127;
Wed, 19 Jan 2000 16:24:41 GMT
Sender: lockhart@hub.org
Message-ID: <3885E548.69CE8FA1@alumni.caltech.edu>
Date: Wed, 19 Jan 2000 16:24:40 +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: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Should cast to CHAR or NUMERIC enforce default length
limit?
References: <9864.948296118@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I think this could be done by having gram.y insert -1 as the default
typmod for a "char" or "numeric" Typename. The rest of the system
already interprets such a typmod as specifying no particular length
constraint. Then, to preserve the rule that
create table foo (bar char);
creates a char(1) field, analyze.c would have to be responsible for
inserting the appropriate default length in place of -1 when processing
a column definition.
Sounds good. My first inclination was to work this out in gram.y,
which you could do pretty easily for TYPECAST rules, but perhaps it
would be better to isolate *all* of the default size settings to a
separate routine called from the appropriate place. Eventually, this
could even be a tunable parameter settable during the session (e.g.
"SET DEFAULT PRECISION NUMERIC ...").
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Jan 19 11:53:40 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA10141
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 11:53:24 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id LAA19963
for pgsql-hackers@postgresql.org; Wed, 19 Jan 2000 11:25:03 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
Message-ID: <3885E59B.155EF9D2@utcorp.com>
From: Kurt Seel <kseel@utcorp.com>
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
X-Newsgroups: comp.databases.postgresql.hackers
Subject: running two servers on one machine
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 21
X-Trace: tw11.nn.bcandid.com 948299099 146.145.135.17 (Wed,
19 Jan 2000 09:24:59 MST)
Organization: bCandid - Powering the world's discussions - http://bCandid.com
Date: Wed, 19 Jan 2000 16:24:59 GMT
To: pgsql-hackers@postgresql.org
FreeBSD 3.2
Postgtres 6.5 and 6.5.3
I have 6.5 up and running. I am trying to bring up a second server,
(6.5.3) on a different port. I have configured it into the compile process
and also tried it from the command line. As soon as I start the
second postmaster process, the main DB server starts refusing
connactions.
The second server is in a chroot'ed environment, so shared libs,
data, etc is _absolutely_ separate.
Is shared memory my problem? How could I (temporarily) hack
this until our compatability testing is complete?
--
"The opposite of a profound truth may well be another profound truth."
- Bohr
From bouncefilter Wed Jan 19 11:27:40 2000
Received: from andie.ip23.net ([212.83.32.23])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA03336
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 11:26:59 -0500 (EST) (envelope-from sevo@ip23.net)
Received: from imap1.ip23.net (imap1.ip23.net [212.83.32.35])
by andie.ip23.net (8.9.3/8.9.3) with ESMTP id RAA24768
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 17:28:09 +0100 (CET)
Received: from ip23.net (spc.ip23.net [212.83.32.122])
by imap1.ip23.net (8.9.3/8.9.3) with ESMTP id RAA62181
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 17:26:27 +0100 (CET)
Sender: sevo@imap1.ip23.net
Message-ID: <3885E6D4.A0BF3F76@ip23.net>
Date: Wed, 19 Jan 2000 17:31:16 +0100
From: Sevo Stille <sevo@ip23.net>
Organization: IP23
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
subscribe
From bouncefilter Wed Jan 19 14:17:42 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id OAA67388
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 14:17:36 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 3073 invoked from network); 19 Jan 2000 19:17:33 -0000
Received: from h-62.96.161.100.host.de.colt.net (root@62.96.161.100)
by pille.addcom.de with SMTP; 19 Jan 2000 19:17:33 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id SAA01268
for pgsql-hackers@postgreSQL.org; Wed, 19 Jan 2000 18:01:55 +0100
Date: Wed, 19 Jan 2000 18:01:54 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Cannot compile psql
Message-ID: <20000119180154.A1260@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
References: <20000118135840.A1519@fam-meskes.de> <371.948210708@sss.pgh.pa.us>
<20000119084546.A471@fam-meskes.de> <9744.948293745@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <9744.948293745@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Wed, Jan 19, 2000 at 09:55:45AM -0500
On Wed, Jan 19, 2000 at 09:55:45AM -0500, Tom Lane wrote:
Hmm. Look at the bottom of include/c.h --- it should be impossible
for DLLIMPORT to be nonempty unless __CYGWIN32__ is defined. So where
is that definition coming from?
I have no idea. But I will check. Also I think that this include file is
used elsewhere too. But the error message does come up only once.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Wed Jan 19 12:25:41 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA31858
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 12:25:30 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA10888;
Wed, 19 Jan 2000 12:24:41 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001191724.MAA10888@candle.pha.pa.us>
Subject: Re: [HACKERS] Should cast to CHAR or NUMERIC enforce default length
limit?
In-Reply-To: <9864.948296118@sss.pgh.pa.us> from Tom Lane at "Jan 19,
2000 10:35:18 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 19 Jan 2000 12:24:41 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Now that I've modified the code so that casting to a specific length
actually works --- ie you can do
x :: char(7)
CAST (y AS numeric(40,6))
and get the expected results --- I am starting to worry that there
may be unwanted side-effects. The reason is that the system by default
interprets "char" as "char(1)" and "numeric" as "numeric(30,6)".
So if you just write "x::char" you will now get truncation to one
character, which did not use to happen. Another distressing example
is
regression=# select '123456789012345678901234567890.12'::numeric;
ERROR: overflow on numeric ABS(value) >= 10^29 for field with precision 30 scale 6
which I think is arguably a violation of the SQL standard --- it says
pretty clearly that the precision and scale of a numeric constant are
whatever is implicit in the number of digits.
Yes, this is distressing.
I am inclined to think that in the context of a cast, we shouldn't
enforce a coercion to default length, but should only coerce if a length
is explicitly specified. This would change the behavior of "x::char"
back to what it was.I think this could be done by having gram.y insert -1 as the default
typmod for a "char" or "numeric" Typename. The rest of the system
already interprets such a typmod as specifying no particular length
constraint. Then, to preserve the rule that
create table foo (bar char);
creates a char(1) field, analyze.c would have to be responsible for
inserting the appropriate default length in place of -1 when processing
a column definition.
Sounds good to me.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Jan 19 12:34:41 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA36917
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 12:34:21 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA10247;
Wed, 19 Jan 2000 12:33:54 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Should cast to CHAR or NUMERIC enforce default length
limit?
In-reply-to: <3885E548.69CE8FA1@alumni.caltech.edu>
References: <9864.948296118@sss.pgh.pa.us>
<3885E548.69CE8FA1@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Wed, 19 Jan 2000 16:24:40 +0000"
Date: Wed, 19 Jan 2000 12:33:54 -0500
Message-ID: <10244.948303234@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
analyze.c would have to be responsible for
inserting the appropriate default length in place of -1 when processing
a column definition.
Sounds good. My first inclination was to work this out in gram.y,
which you could do pretty easily for TYPECAST rules,
I thought about that, but since the Typename production itself can't
do the right thing (it doesn't know its context), you'd have to patch
up after it in either TYPECAST or column definition rules. On the
whole, fixing things that the grammar can't easily get right seems like
it belongs in analyze.c.
Eventually, this
could even be a tunable parameter settable during the session (e.g.
"SET DEFAULT PRECISION NUMERIC ...").
As I'm envisioning it, the only thing the default will be used for is
substituting a default precision into a "CREATE TABLE foo (bar numeric)"
command. So adjusting the default on-the-fly doesn't seem all that
useful --- it wouldn't affect previously-created tables.
I did speculate about the idea of not enforcing a default precision at
all. If we allowed the table to be created with atttypmod = -1, then
the effect would be that numeric values would get stored with whatever
precision appeared in the source value or came out of a calculation.
Such a numeric column would have no specific precision/scale, so it'd
be more like variable-width "text" than fixed-width "char". I'm not
sure if this is useful, and I am sure that it wouldn't be very
standard...
regards, tom lane
From bouncefilter Wed Jan 19 12:44:42 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA39142
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 12:44:34 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA10282;
Wed, 19 Jan 2000 12:43:54 -0500 (EST)
To: Kurt Seel <kseel@utcorp.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] running two servers on one machine
In-reply-to: <3885E59B.155EF9D2@utcorp.com>
References: <3885E59B.155EF9D2@utcorp.com>
Comments: In-reply-to Kurt Seel <kseel@utcorp.com>
message dated "Wed, 19 Jan 2000 16:24:59 +0000"
Date: Wed, 19 Jan 2000 12:43:54 -0500
Message-ID: <10279.948303834@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Kurt Seel <kseel@utcorp.com> writes:
FreeBSD 3.2
Postgtres 6.5 and 6.5.3
I have 6.5 up and running. I am trying to bring up a second server,
(6.5.3) on a different port. I have configured it into the compile process
and also tried it from the command line. As soon as I start the
second postmaster process, the main DB server starts refusing
connactions.
I run two servers all the time, one production and one test. (Right now
I actually have three going on this machine.) AFAIK all you have to do
is make sure they are running with different data directories (-D switch
to postmaster) and port numbers (-p switch). You can configure those
items at configure time, but it's not really necessary to do so.
What exactly is the behavior --- what error messages do you see in the
main server's log? Can you connect to the alternate server? Does it
show any error messages?
The second server is in a chroot'ed environment, so shared libs,
data, etc is _absolutely_ separate.
Is shared memory my problem? How could I (temporarily) hack
this until our compatability testing is complete?
chroot is certainly not necessary, and I doubt shared memory is the
issue either, unless maybe you are exceeding your kernel's configuration
limit. (But that should mean that the second postmaster is unable to
start...)
regards, tom lane
From bouncefilter Wed Jan 19 14:17:43 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA67404
for <hackers@postgreSQL.org>; Wed, 19 Jan 2000 14:17:38 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from laptop.pacifier.com (ip103.pdx1.pacifier.com [216.65.144.103])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA28208;
Wed, 19 Jan 2000 11:15:01 -0800 (PST)
Message-Id: <3.0.1.32.20000119104735.00ee9330@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 19 Jan 2000 10:47:35 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] gperf anyone?
Cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
hackers@postgreSQL.org
In-Reply-To: <3754.948256849@sss.pgh.pa.us>
References: <3.0.1.32.20000118174928.00ef0370@mail.pacifier.com>
<Pine.LNX.4.21.0001170003210.1636-100000@localhost.localdomain>
<3.0.1.32.20000118174928.00ef0370@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:40 PM 1/18/00 -0500, Tom Lane wrote:
I agree with Don that the performance benefit is likely to be
unmeasurable. Still, there could be a win: we currently have to modify
keywords.c by hand every time we have to add/delete a keyword. Does
gperf offer any aid for maintaining the keyword list? If so, that'd
be sufficient reason to switch to it...
If so, yeah, it might make sense. Without looking at the existing
code, though, the existing "binary search on a fixed array" makes
me think of a list of keywords in alphabetical order. If true,
entering new keywords in alphabetical order doesn't seem like a terrible
burden on the implementor. The resulting list is probably more readable
if kept alphabetical anyway...
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Wed Jan 19 14:25:43 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA68951
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 14:24:53 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1) id 12B0j4-0003CK-00
for pgsql-hackers@postgresql.org; Wed, 19 Jan 2000 19:25:06 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12B0is-00031V-00
for pgsql-hackers@postgresql.org; Wed, 19 Jan 2000 19:24:54 +0000
Date: Wed, 19 Jan 2000 19:24:54 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: pgsql-hackers@postgresql.org
Subject: pg_dump disaster
Message-ID: <20000119192454.A10697@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
Trying to load a 6 January pg_dumpall file with today's postgresql gives
many
invalid command \N
probably because
PQexec: you gotta get out of a COPY state yourself.
db.out4:11621: invalid command \.
Somehow psql is out of sync and thinks the \N isn't within a COPY block.
The work around was to redump as insert statements..
It's tricky (for me) to debug as "stdin;" file not found..
How do you get of a COPY state yourself?
Cheers,
Patrick
From bouncefilter Wed Jan 19 15:05:43 2000
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 PAA96264
for <hackers@postgresql.org>; Wed, 19 Jan 2000 15:05:24 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61977 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S49171AbQASUEf>;
Wed, 19 Jan 2000 21:04:35 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12B1S3-0002mh-00; Wed, 19 Jan 2000 21:11:35 +0100
Date: Wed, 19 Jan 2000 21:11:35 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Alfred Perlstein <bright@wintelcom.net>, hackers@postgresql.org
Subject: Re: [HACKERS] gperf anyone?
In-Reply-To: <200001190152.UAA11497@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0001192044260.5544-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-18, Bruce Momjian mentioned:
Can you run our keywords.c using our method and gperf and see if there
is any speed difference?
It seems to have a speed advantage of about 2.5. But in practice that
means that 1 million words take half a second. It's not a big deal to me,
I was just wondering before I throw it out. I guess it really only makes a
difference for compilers, which operate on 1000+ lines.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Wed Jan 19 15:14:43 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA98478
for <hackers@postgreSQL.org>; Wed, 19 Jan 2000 15:14:25 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA20286;
Wed, 19 Jan 2000 15:12:25 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001192012.PAA20286@candle.pha.pa.us>
Subject: Re: [HACKERS] gperf anyone?
In-Reply-To: <Pine.LNX.4.21.0001192044260.5544-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 19, 2000 09:11:35 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Wed, 19 Jan 2000 15:12:25 -0500 (EST)
CC: Alfred Perlstein <bright@wintelcom.net>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-01-18, Bruce Momjian mentioned:
Can you run our keywords.c using our method and gperf and see if there
is any speed difference?It seems to have a speed advantage of about 2.5. But in practice that
means that 1 million words take half a second. It's not a big deal to me,
I was just wondering before I throw it out. I guess it really only makes a
difference for compilers, which operate on 1000+ lines.
The big difference may be that the compiler has variables/types that are
added dynamically while running, while our list is static. Insert time
for our types is zero because we don't add SQL keywords at runtime.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Jan 19 15:13:43 2000
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 PAA98170
for <hackers@postgresql.org>; Wed, 19 Jan 2000 15:13:21 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:65045 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S63515AbQASUMn>;
Wed, 19 Jan 2000 21:12:43 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12B1a6-0002ub-00; Wed, 19 Jan 2000 21:19:54 +0100
Date: Wed, 19 Jan 2000 21:19:54 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, Bruce Momjian <pgman@candle.pha.pa.us>,
hackers@postgresql.org
Subject: Re: [HACKERS] gperf anyone?
In-Reply-To: <3754.948256849@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001192117280.5544-200000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1824374762-948313194=:5544"
Sender: Peter Eisentraut <peter@hub.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-1824374762-948313194=:5544
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
On 2000-01-18, Tom Lane mentioned:
I agree with Don that the performance benefit is likely to be
unmeasurable. Still, there could be a win: we currently have to modify
keywords.c by hand every time we have to add/delete a keyword. Does
gperf offer any aid for maintaining the keyword list? If so, that'd
be sufficient reason to switch to it...
That's a good point. It would allow you much more ordering freedom. The
file is attached for review. Of course adding/deleting keywords would now
require gperf. :(
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
--8323328-1824374762-948313194=:5544
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="keywords.gperf"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0001192119540.5544@localhost.localdomain>
Content-Description:
Content-Disposition: attachment; filename="keywords.gperf"
JXsNCiNpbmNsdWRlICJwb3N0Z3Jlcy5oIg0KI2luY2x1ZGUgIm5vZGVzL3Bh
cnNlbm9kZXMuaCINCiNpbmNsdWRlICJub2Rlcy9wZ19saXN0LmgiDQojaW5j
bHVkZSAicGFyc2UuaCINCiNpbmNsdWRlICJwYXJzZXIva2V5d29yZHMuaCIN
Cg0KI2luY2x1ZGUgPHN0cmluZy5oPg0KI2luY2x1ZGUgPGN0eXBlLmg+DQol
fQ0Kc3RydWN0IHNjYW5fa2V5d29yZCB7IGNoYXIgKm5hbWU7IGludCB2YWx1
ZTsgfTsNCiUlDQphYm9ydCwgICAgICAgICAgQUJPUlRfVFJBTlMNCmFic29s
dXRlLCAgICAgICBBQlNPTFVURQ0KYWNjZXNzLCAgICAgICAgIEFDQ0VTUw0K
YWN0aW9uLCAgICAgICAgIEFDVElPTg0KYWRkLCAgICAgICAgICAgIEFERA0K
YWZ0ZXIsICAgICAgICAgIEFGVEVSDQphZ2dyZWdhdGUsICAgICAgQUdHUkVH
QVRFDQphbGwsICAgICAgICAgICAgQUxMDQphbHRlciwgICAgICAgICAgQUxU
RVINCmFuYWx5emUsICAgICAgICBBTkFMWVpFDQphbmQsICAgICAgICAgICAg
QU5EDQphbnksICAgICAgICAgICAgQU5ZDQphcywgICAgICAgICAgICAgQVMN
CmFzYywgICAgICAgICAgICBBU0MNCmJhY2t3YXJkLCAgICAgICBCQUNLV0FS
RA0KYmVmb3JlLCAgICAgICAgIEJFRk9SRQ0KYmVnaW4sICAgICAgICAgIEJF
R0lOX1RSQU5TDQpiZXR3ZWVuLCAgICAgICAgQkVUV0VFTg0KYmluYXJ5LCAg
ICAgICAgIEJJTkFSWQ0KYm90aCwgICAgICAgICAgIEJPVEgNCmJ5LCAgICAg
ICAgICAgICBCWQ0KY2FjaGUsICAgICAgICAgIENBQ0hFDQpjYXNjYWRlLCAg
ICAgICAgQ0FTQ0FERQ0KY2FzZSwgICAgICAgICAgIENBU0UNCmNhc3QsICAg
ICAgICAgICBDQVNUDQpjaGFyLCAgICAgICAgICAgQ0hBUg0KY2hhcmFjdGVy
LCAgICAgIENIQVJBQ1RFUg0KY2hlY2ssICAgICAgICAgIENIRUNLDQpjbG9z
ZSwgICAgICAgICAgQ0xPU0UNCmNsdXN0ZXIsICAgICAgICBDTFVTVEVSDQpj
b2FsZXNjZSwgICAgICAgQ09BTEVTQ0UNCmNvbGxhdGUsICAgICAgICBDT0xM
QVRFDQpjb2x1bW4sICAgICAgICAgQ09MVU1ODQpjb21tZW50LCAgICAgICAg
Q09NTUVOVA0KY29tbWl0LCAgICAgICAgIENPTU1JVA0KY29tbWl0dGVkLCAg
ICAgIENPTU1JVFRFRA0KY29uc3RyYWludCwgICAgIENPTlNUUkFJTlQNCmNv
bnN0cmFpbnRzLCAgICBDT05TVFJBSU5UUw0KY29weSwgICAgICAgICAgIENP
UFkNCmNyZWF0ZSwgICAgICAgICBDUkVBVEUNCmNyZWF0ZWRiLCAgICAgICBD
UkVBVEVEQg0KY3JlYXRldXNlciwgICAgIENSRUFURVVTRVINCmNyb3NzLCAg
ICAgICAgICBDUk9TUw0KY3VycmVudF9kYXRlLCAgIENVUlJFTlRfREFURQ0K
Y3VycmVudF90aW1lLCAgIENVUlJFTlRfVElNRQ0KY3VycmVudF90aW1lc3Rh
bXAsIENVUlJFTlRfVElNRVNUQU1QDQpjdXJyZW50X3VzZXIsICAgQ1VSUkVO
VF9VU0VSDQpjdXJzb3IsICAgICAgICAgQ1VSU09SDQpjeWNsZSwgICAgICAg
ICAgQ1lDTEUNCmRhdGFiYXNlLCAgICAgICBEQVRBQkFTRQ0KZGF5LCAgICAg
ICAgICAgIERBWV9QDQpkZWNpbWFsLCAgICAgICAgREVDSU1BTA0KZGVjbGFy
ZSwgICAgICAgIERFQ0xBUkUNCmRlZmF1bHQsICAgICAgICBERUZBVUxUDQpk
ZWZlcnJhYmxlLCAgICAgREVGRVJSQUJMRQ0KZGVmZXJyZWQsICAgICAgIERF
RkVSUkVEDQpkZWxldGUsICAgICAgICAgREVMRVRFDQpkZWxpbWl0ZXJzLCAg
ICAgREVMSU1JVEVSUw0KZGVzYywgICAgICAgICAgIERFU0MNCmRpc3RpbmN0
LCAgICAgICBESVNUSU5DVA0KZG8sICAgICAgICAgICAgIERPDQpkb3VibGUs
ICAgICAgICAgRE9VQkxFDQpkcm9wLCAgICAgICAgICAgRFJPUA0KZWFjaCwg
ICAgICAgICAgIEVBQ0gNCmVsc2UsICAgICAgICAgICBFTFNFDQplbmNvZGlu
ZywgICAgICAgRU5DT0RJTkcNCmVuZCwgICAgICAgICAgICBFTkRfVFJBTlMN
CmV4Y2VwdCwgICAgICAgICBFWENFUFQNCmV4Y2x1c2l2ZSwgICAgICBFWENM
VVNJVkUNCmV4ZWN1dGUsICAgICAgICBFWEVDVVRFDQpleGlzdHMsICAgICAg
ICAgRVhJU1RTDQpleHBsYWluLCAgICAgICAgRVhQTEFJTg0KZXh0ZW5kLCAg
ICAgICAgIEVYVEVORA0KZXh0cmFjdCwgICAgICAgIEVYVFJBQ1QNCmZhbHNl
LCAgICAgICAgICBGQUxTRV9QDQpmZXRjaCwgICAgICAgICAgRkVUQ0gNCmZs
b2F0LCAgICAgICAgICBGTE9BVA0KZm9yLCAgICAgICAgICAgIEZPUg0KZm9y
ZWlnbiwgICAgICAgIEZPUkVJR04NCmZvcndhcmQsICAgICAgICBGT1JXQVJE
DQpmcm9tLCAgICAgICAgICAgRlJPTQ0KZnVsbCwgICAgICAgICAgIEZVTEwN
CmZ1bmN0aW9uLCAgICAgICBGVU5DVElPTg0KZ2xvYmFsLCAgICAgICAgIEdM
T0JBTA0KZ3JhbnQsICAgICAgICAgIEdSQU5UDQpncm91cCwgICAgICAgICAg
R1JPVVANCmhhbmRsZXIsICAgICAgICBIQU5ETEVSDQpoYXZpbmcsICAgICAg
ICAgSEFWSU5HDQpob3VyLCAgICAgICAgICAgSE9VUl9QDQppbW1lZGlhdGUs
ICAgICAgSU1NRURJQVRFDQppbiwgICAgICAgICAgICAgSU4NCmluY3JlbWVu
dCwgICAgICBJTkNSRU1FTlQNCmluZGV4LCAgICAgICAgICBJTkRFWA0KaW5o
ZXJpdHMsICAgICAgIElOSEVSSVRTDQppbml0aWFsbHksICAgICAgSU5JVElB
TExZDQppbm5lciwgICAgICAgICAgSU5ORVJfUA0KaW5zZW5zaXRpdmUsICAg
IElOU0VOU0lUSVZFDQppbnNlcnQsICAgICAgICAgSU5TRVJUDQppbnN0ZWFk
LCAgICAgICAgSU5TVEVBRA0KaW50ZXJzZWN0LCAgICAgIElOVEVSU0VDVA0K
aW50ZXJ2YWwsICAgICAgIElOVEVSVkFMDQppbnRvLCAgICAgICAgICAgSU5U
Tw0KaXMsICAgICAgICAgICAgIElTDQppc251bGwsICAgICAgICAgSVNOVUxM
DQppc29sYXRpb24sICAgICAgSVNPTEFUSU9ODQpqb2luLCAgICAgICAgICAg
Sk9JTg0Ka2V5LCAgICAgICAgICAgIEtFWQ0KbGFuY29tcGlsZXIsICAgIExB
TkNPTVBJTEVSDQpsYW5ndWFnZSwgICAgICAgTEFOR1VBR0UNCmxlYWRpbmcs
ICAgICAgICBMRUFESU5HDQpsZWZ0LCAgICAgICAgICAgTEVGVA0KbGV2ZWws
ICAgICAgICAgIExFVkVMDQpsaWtlLCAgICAgICAgICAgTElLRQ0KbGltaXQs
ICAgICAgICAgIExJTUlUDQpsaXN0ZW4sICAgICAgICAgTElTVEVODQpsb2Fk
LCAgICAgICAgICAgTE9BRA0KbG9jYWwsICAgICAgICAgIExPQ0FMDQpsb2Nh
dGlvbiwgICAgICAgTE9DQVRJT04NCmxvY2ssICAgICAgICAgICBMT0NLX1AN
Cm1hdGNoLCAgICAgICAgICBNQVRDSA0KbWF4dmFsdWUsICAgICAgIE1BWFZB
TFVFDQptaW51dGUsICAgICAgICAgTUlOVVRFX1ANCm1pbnZhbHVlLCAgICAg
ICBNSU5WQUxVRQ0KbW9kZSwgICAgICAgICAgIE1PREUNCm1vbnRoLCAgICAg
ICAgICBNT05USF9QDQptb3ZlLCAgICAgICAgICAgTU9WRQ0KbmFtZXMsICAg
ICAgICAgIE5BTUVTDQpuYXRpb25hbCwgICAgICAgTkFUSU9OQUwNCm5hdHVy
YWwsICAgICAgICBOQVRVUkFMDQpuY2hhciwgICAgICAgICAgTkNIQVINCm5l
dywgICAgICAgICAgICBORVcNCm5leHQsICAgICAgICAgICBORVhUDQpubywg
ICAgICAgICAgICAgTk8NCm5vY3JlYXRlZGIsICAgICBOT0NSRUFURURCDQpu
b2NyZWF0ZXVzZXIsICAgTk9DUkVBVEVVU0VSDQpub25lLCAgICAgICAgICAg
Tk9ORQ0Kbm90LCAgICAgICAgICAgIE5PVA0Kbm90aGluZywgICAgICAgIE5P
VEhJTkcNCm5vdGlmeSwgICAgICAgICBOT1RJRlkNCm5vdG51bGwsICAgICAg
ICBOT1ROVUxMDQpudWxsLCAgICAgICAgICAgTlVMTF9QDQpudWxsaWYsICAg
ICAgICAgTlVMTElGDQpudW1lcmljLCAgICAgICAgTlVNRVJJQw0Kb2YsICAg
ICAgICAgICAgIE9GDQpvZmZzZXQsICAgICAgICAgT0ZGU0VUDQpvaWRzLCAg
ICAgICAgICAgT0lEUw0Kb2xkLCAgICAgICAgICAgIENVUlJFTlQNCm9uLCAg
ICAgICAgICAgICBPTg0Kb25seSwgICAgICAgICAgIE9OTFkNCm9wZXJhdG9y
LCAgICAgICBPUEVSQVRPUg0Kb3B0aW9uLCAgICAgICAgIE9QVElPTg0Kb3Is
ICAgICAgICAgICAgIE9SDQpvcmRlciwgICAgICAgICAgT1JERVINCm91dGVy
LCAgICAgICAgICBPVVRFUl9QDQpwYXJ0aWFsLCAgICAgICAgUEFSVElBTA0K
cGFzc3dvcmQsICAgICAgIFBBU1NXT1JEDQpwZW5kYW50LCAgICAgICAgUEVO
REFOVA0KcG9zaXRpb24sICAgICAgIFBPU0lUSU9ODQpwcmVjaXNpb24sICAg
ICAgUFJFQ0lTSU9ODQpwcmltYXJ5LCAgICAgICAgUFJJTUFSWQ0KcHJpb3Is
ICAgICAgICAgIFBSSU9SDQpwcml2aWxlZ2VzLCAgICAgUFJJVklMRUdFUw0K
cHJvY2VkdXJhbCwgICAgIFBST0NFRFVSQUwNCnByb2NlZHVyZSwgICAgICBQ
Uk9DRURVUkUNCnB1YmxpYywgICAgICAgICBQVUJMSUMNCnJlYWQsICAgICAg
ICAgICBSRUFEDQpyZWZlcmVuY2VzLCAgICAgUkVGRVJFTkNFUw0KcmVsYXRp
dmUsICAgICAgIFJFTEFUSVZFDQpyZW5hbWUsICAgICAgICAgUkVOQU1FDQpy
ZXNldCwgICAgICAgICAgUkVTRVQNCnJlc3RyaWN0LCAgICAgICBSRVNUUklD
VA0KcmV0dXJucywgICAgICAgIFJFVFVSTlMNCnJldm9rZSwgICAgICAgICBS
RVZPS0UNCnJpZ2h0LCAgICAgICAgICBSSUdIVA0Kcm9sbGJhY2ssICAgICAg
IFJPTExCQUNLDQpyb3csICAgICAgICAgICAgUk9XDQpydWxlLCAgICAgICAg
ICAgUlVMRQ0Kc2Nyb2xsLCAgICAgICAgIFNDUk9MTA0Kc2Vjb25kLCAgICAg
ICAgIFNFQ09ORF9QDQpzZWxlY3QsICAgICAgICAgU0VMRUNUDQpzZXF1ZW5j
ZSwgICAgICAgU0VRVUVOQ0UNCnNlcmlhbCwgICAgICAgICBTRVJJQUwNCnNl
cmlhbGl6YWJsZSwgICBTRVJJQUxJWkFCTEUNCnNldCwgICAgICAgICAgICBT
RVQNCnNldG9mLCAgICAgICAgICBTRVRPRg0Kc2hhcmUsICAgICAgICAgIFNI
QVJFDQpzaG93LCAgICAgICAgICAgU0hPVw0Kc3RhcnQsICAgICAgICAgIFNU
QVJUDQpzdGF0ZW1lbnQsICAgICAgU1RBVEVNRU5UDQpzdGRpbiwgICAgICAg
ICAgU1RESU4NCnN0ZG91dCwgICAgICAgICBTVERPVVQNCnN1YnN0cmluZywg
ICAgICBTVUJTVFJJTkcNCnN5c2lkLCAgICAgICAgICBTWVNJRA0KdGFibGUs
ICAgICAgICAgIFRBQkxFDQp0ZW1wLCAgICAgICAgICAgVEVNUA0KdGVtcG9y
YXJ5LCAgICAgIFRFTVBPUkFSWQ0KdGhlbiwgICAgICAgICAgIFRIRU4NCnRp
bWUsICAgICAgICAgICBUSU1FDQp0aW1lc3RhbXAsICAgICAgVElNRVNUQU1Q
DQp0aW1lem9uZV9ob3VyLCAgVElNRVpPTkVfSE9VUg0KdGltZXpvbmVfbWlu
dXRlLCBUSU1FWk9ORV9NSU5VVEUNCnRvLCAgICAgICAgICAgICBUTw0KdHJh
aWxpbmcsICAgICAgIFRSQUlMSU5HDQp0cmFuc2FjdGlvbiwgICAgVFJBTlNB
Q1RJT04NCnRyaWdnZXIsICAgICAgICBUUklHR0VSDQp0cmltLCAgICAgICAg
ICAgVFJJTQ0KdHJ1ZSwgICAgICAgICAgIFRSVUVfUA0KdHJ1bmNhdGUsICAg
ICAgIFRSVU5DQVRFDQp0cnVzdGVkLCAgICAgICAgVFJVU1RFRA0KdHlwZSwg
ICAgICAgICAgIFRZUEVfUA0KdW5pb24sICAgICAgICAgIFVOSU9ODQp1bmlx
dWUsICAgICAgICAgVU5JUVVFDQp1bmxpc3RlbiwgICAgICAgVU5MSVNURU4N
CnVudGlsLCAgICAgICAgICBVTlRJTA0KdXBkYXRlLCAgICAgICAgIFVQREFU
RQ0KdXNlciwgICAgICAgICAgIFVTRVINCnVzaW5nLCAgICAgICAgICBVU0lO
Rw0KdmFjdXVtLCAgICAgICAgIFZBQ1VVTQ0KdmFsaWQsICAgICAgICAgIFZB
TElEDQp2YWx1ZXMsICAgICAgICAgVkFMVUVTDQp2YXJjaGFyLCAgICAgICAg
VkFSQ0hBUg0KdmFyeWluZywgICAgICAgIFZBUllJTkcNCnZlcmJvc2UsICAg
ICAgICBWRVJCT1NFDQp2ZXJzaW9uLCAgICAgICAgVkVSU0lPTg0Kdmlldywg
ICAgICAgICAgIFZJRVcNCndoZW4sICAgICAgICAgICBXSEVODQp3aGVyZSwg
ICAgICAgICAgV0hFUkUNCndpdGgsICAgICAgICAgICBXSVRIDQp3b3JrLCAg
ICAgICAgICAgV09SSw0KeWVhciwgICAgICAgICAgIFlFQVJfUA0Kem9uZSwg
ICAgICAgICAgIFpPTkUNCiUlDQoNClNjYW5LZXl3b3JkICoNClNjYW5LZXl3
b3JkTG9va3VwKGNvbnN0IGNoYXIgKnRleHQsIGludCBsZW4pDQp7DQogICAg
ICAgIHJldHVybiAoU2NhbktleXdvcmQqKWluX3dvcmRfc2V0KHRleHQsIGxl
bik7DQp9DQo=
--8323328-1824374762-948313194=:5544--
From bouncefilter Wed Jan 19 15:23:43 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA00447
for <hackers@postgreSQL.org>; Wed, 19 Jan 2000 15:23:22 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA37121;
Wed, 19 Jan 2000 16:22:02 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 19 Jan 2000 16:22:02 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>,
Alfred Perlstein <bright@wintelcom.net>, hackers@postgreSQL.org
Subject: Re: [HACKERS] gperf anyone?
In-Reply-To: <200001192012.PAA20286@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001191621030.23487-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 19 Jan 2000, Bruce Momjian wrote:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-01-18, Bruce Momjian mentioned:
Can you run our keywords.c using our method and gperf and see if there
is any speed difference?It seems to have a speed advantage of about 2.5. But in practice that
means that 1 million words take half a second. It's not a big deal to me,
I was just wondering before I throw it out. I guess it really only makes a
difference for compilers, which operate on 1000+ lines.The big difference may be that the compiler has variables/types that are
added dynamically while running, while our list is static. Insert time
for our types is zero because we don't add SQL keywords at runtime.
I'm curious...does it hurt us any to do this? Like, will it slow things
down? Is the end result cleaner, for neglible speed improvements?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Jan 19 16:07:43 2000
Received: from relay.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA15228
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 16:07:25 -0500 (EST) (envelope-from dms@wplus.net)
X-Real-To: pgsql-hackers@postgreSQL.org
Received: from wplus.net (ppdms.dialup.wplus.net [195.131.52.71])
by relay.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id AAA62224;
Thu, 20 Jan 2000 00:01:33 +0300 (MSK)
Message-ID: <388626BC.8B5ACCD@wplus.net>
Date: Thu, 20 Jan 2000 00:03:56 +0300
From: Dmitry Samersoff <dms@wplus.net>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: ru,en
MIME-Version: 1.0
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
CC: "'Zeugswetter Andreas SB'" <ZeugswetterA@wien.spardat.at>,
"'Bruce Momjian'" <pgman@candle.pha.pa.us>,
"'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] [hackers]development suggestion needed (filepath
assymlink)
References: <1BF7C7482189D211B03F00805F8527F748C45D@S-NATH-EXCH2>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
"Ansley, Michael" wrote:
Maybe we could only put the temp files in a different directory.
They are where performance matters.
If a normal table create takes a few seconds that is not a
real problem.Once you have the ability to create tablespaces, you can modify the temp
table thingy a little to create temporary tables in the temp tablespace. If
there is no explicit temp tablespace defined, then it defaults to the system
tablespace (which is where it goes now anyway).
IMHO, It's good idea placing all temporary files (like pg_sort.tmp etc)
into separate subdirectory.
We could actually
hash the file names into directory buckets and access them
that way, and have one directory that old symlinks to the
hashed files.I don't think this is necessary, because if you have a system that requires
this kind of action, then the administrator can create a temp tablespace
which is used for all the temporary tables, and spread the rest of the
tables and indices among the remaining tablespaces.
According to my practice, one byte hash improve mail performance twice
for 5000 mailboxes. It doesn't significantly increase mail performance
for 1000 mailboxes.
I'm hard to belive postgres data directory with 5000 files ;-))
--
Dmitry Samersoff, DM\S
dms@wplus.net http://devnull.wplus.net
* there will come soft rains
From bouncefilter Wed Jan 19 15:50:44 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA08704
for <hackers@postgreSQL.org>; Wed, 19 Jan 2000 15:50:34 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id NAA20154;
Wed, 19 Jan 2000 13:12:28 -0800 (PST)
Date: Wed, 19 Jan 2000 13:12:28 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: The Hermit Hacker <scrappy@hub.org>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
hackers@postgreSQL.org
Subject: Re: [HACKERS] gperf anyone?
Message-ID: <20000119131228.C14058@fw.wintelcom.net>
References: <200001192012.PAA20286@candle.pha.pa.us>
<Pine.BSF.4.21.0001191621030.23487-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.BSF.4.21.0001191621030.23487-100000@thelab.hub.org>;
from scrappy@hub.org on Wed, Jan 19, 2000 at 04:22:02PM -0400
* The Hermit Hacker <scrappy@hub.org> [000119 12:51] wrote:
On Wed, 19 Jan 2000, Bruce Momjian wrote:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-01-18, Bruce Momjian mentioned:
Can you run our keywords.c using our method and gperf and see if there
is any speed difference?It seems to have a speed advantage of about 2.5. But in practice that
means that 1 million words take half a second. It's not a big deal to me,
I was just wondering before I throw it out. I guess it really only makes a
difference for compilers, which operate on 1000+ lines.The big difference may be that the compiler has variables/types that are
added dynamically while running, while our list is static. Insert time
for our types is zero because we don't add SQL keywords at runtime.I'm curious...does it hurt us any to do this? Like, will it slow things
down? Is the end result cleaner, for neglible speed improvements?
You can pick up a copy of my test at:
http://www.freebsd.org/~alfred/gperf.tgz
It should compile two programs 'gperf' and 'norm', I was able to get
almost a 100% speed improvement:
~/gperf % time ./gperf
./gperf 0.49s user 0.00s system 100% cpu 0.489 total
~/gperf % time ./norm
./norm 0.91s user 0.00s system 99% cpu 0.918 total
One thing you'll want to consider is the overall application of this,
if the potentially sparse tables that gperf creates causes us to fault
in extra cache pages it may not be so cool.
I'm also pretty sure someone more proficient with hash tables and gperf
in particular could get better results than I did, I sort of guessed
at gperf command line switches until one seemed to work.
also... to accomplish the gperf testing I do a strlen on each word,
over and over to simulate the need for it (as gperf needs that)
however if the strlen is already available in the parser at this
time, i'm pretty sure it would be even faster.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
From bouncefilter Wed Jan 19 16:31:44 2000
Received: from relay.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA21268
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 16:30:55 -0500 (EST) (envelope-from dms@wplus.net)
X-Real-To: pgsql-hackers@postgreSQL.org
Received: from wplus.net (ppdms.dialup.wplus.net [195.131.52.71])
by relay.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id AAA64218;
Thu, 20 Jan 2000 00:26:37 +0300 (MSK)
Message-ID: <38862C9D.C2151E4E@wplus.net>
Date: Thu, 20 Jan 2000 00:29:01 +0300
From: Dmitry Samersoff <dms@wplus.net>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: ru,en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Index recreation in vacuum
References: <000f01bf622a$bf423940$2801007e@tpf.co.jp>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Hiroshi Inoue wrote:
Yes,I believe so. It's necessary to keep consistency between heap
table and indexes even in case of abort/crash.
As far as I see,it has been a big charge for vacuum.OK, how about making a copy of the heap table before starting vacuum,
moving all the tuples in that copy, create new index, and then move the
new heap and indexes over the old version. We already have an exclusive
lock on the table. That would be 100% reliable, with the disadvantage
of using 2x the disk space. Seems like a big win.I heard from someone that old vacuum had been like so.
Probably 2x disk space for big tables was a big disadvantage.
Yes, It is critical.
How about sequence like this:
* Drop indices (keeping somewhere index descriptions)
* vacuuming table
* recreate indices
If something crash, user have been noticed
to re-run vacuum or recreate indices by hand
when system restarts.
I use script like described above for vacuuming
- it really increase vacuum performance for large table.
--
Dmitry Samersoff, DM\S
dms@wplus.net http://devnull.wplus.net
* there will come soft rains
From bouncefilter Wed Jan 19 16:33:44 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA24328
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 16:33:06 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA26048;
Wed, 19 Jan 2000 16:32:25 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001192132.QAA26048@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <38862C9D.C2151E4E@wplus.net> from Dmitry Samersoff at "Jan 20,
2000 00:29:01 am"
To: Dmitry Samersoff <dms@wplus.net>
Date: Wed, 19 Jan 2000 16:32:25 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I heard from someone that old vacuum had been like so.
Probably 2x disk space for big tables was a big disadvantage.Yes, It is critical.
How about sequence like this:
* Drop indices (keeping somewhere index descriptions)
* vacuuming table
* recreate indicesIf something crash, user have been noticed
to re-run vacuum or recreate indices by hand
when system restarts.I use script like described above for vacuuming
- it really increase vacuum performance for large table.
We need two things:
auto-create index on startup
allow vacuum to run only if number of tuples superceeded > X %
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Jan 19 16:43:44 2000
Received: from relay.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA26578
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 16:43:07 -0500 (EST) (envelope-from dms@wplus.net)
X-Real-To: pgsql-hackers@postgreSQL.org
Received: from wplus.net (ppdms.dialup.wplus.net [195.131.52.71])
by relay.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id AAA65264;
Thu, 20 Jan 2000 00:39:02 +0300 (MSK)
Message-ID: <38862F86.20328BD3@wplus.net>
Date: Thu, 20 Jan 2000 00:41:26 +0300
From: Dmitry Samersoff <dms@wplus.net>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: ru,en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Index recreation in vacuum
References: <200001192132.QAA26048@candle.pha.pa.us>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
We need two things:
auto-create index on startup
IMHO, It have to be controlled by user, because creating large index
can take a number of hours. Sometimes it's better to live without
indices
at all, and then build it by hand after workday end.
--
Dmitry Samersoff, DM\S
dms@wplus.net http://devnull.wplus.net
* there will come soft rains
From bouncefilter Wed Jan 19 16:52:44 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA28625
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 16:52:15 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA27235;
Wed, 19 Jan 2000 16:51:52 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001192151.QAA27235@candle.pha.pa.us>
Subject: Re: [HACKERS] Index recreation in vacuum
In-Reply-To: <38862F86.20328BD3@wplus.net> from Dmitry Samersoff at "Jan 20,
2000 00:41:26 am"
To: Dmitry Samersoff <dms@wplus.net>
Date: Wed, 19 Jan 2000 16:51:52 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset koi8-r unsupported, filtering to ASCII...]
Bruce Momjian wrote:
We need two things:
auto-create index on startup
IMHO, It have to be controlled by user, because creating large index
can take a number of hours. Sometimes it's better to live without
indices
at all, and then build it by hand after workday end.
OK, full circle time. That is why I recommended making a separate new
heap and index and using rename() to move them into place once the
vacuum is completed. In a failure during vacuum, the failed vacuum files
should be just removed on startup. No downtime, and index is in place.
Also, I thought about how to do rename() of multiple tables atomically.
My idea would be to have a pg_startup table that contains information
about what operations should be performed on startup. You could write
to the file in an atomic action, and if there was a failure, on startup,
the file could be read and the operations performed. We would basically
be using our own transaction system to guarantee file system atomicity.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Jan 19 17:29:45 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA41008;
Wed, 19 Jan 2000 17:29:20 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA11235;
Wed, 19 Jan 2000 17:29:12 -0500 (EST)
To: Michael Meskes <meskes@postgreSQL.org>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Cannot compile psql
In-reply-to: <20000119180154.A1260@fam-meskes.de>
References: <20000118135840.A1519@fam-meskes.de> <371.948210708@sss.pgh.pa.us>
<20000119084546.A471@fam-meskes.de> <9744.948293745@sss.pgh.pa.us>
<20000119180154.A1260@fam-meskes.de>
Comments: In-reply-to Michael Meskes <meskes@postgreSQL.org>
message dated "Wed, 19 Jan 2000 18:01:54 +0100"
Date: Wed, 19 Jan 2000 17:29:11 -0500
Message-ID: <11232.948320951@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Meskes <meskes@postgreSQL.org> writes:
I have no idea. But I will check. Also I think that this include file is
used elsewhere too. But the error message does come up only once.
Oh, that's interesting, because there are a dozen or so files that
reference DLLIMPORT. Maybe you should be looking at what is included
by the file with the error (and not by any other files...)
regards, tom lane
From bouncefilter Wed Jan 19 18:15:45 2000
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 SAA64282
for <pgsql-hackers@postgreSQL.org>;
Wed, 19 Jan 2000 18:15:02 -0500 (EST) (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 IAA03402; Thu, 20 Jan 2000 08:13:48 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Dmitry Samersoff" <dms@wplus.net>
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Index recreation in vacuum
Date: Thu, 20 Jan 2000 08:19:26 +0900
Message-ID: <000901bf62d3$a0bfa940$2801007e@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="koi8-r"
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: <38862C9D.C2151E4E@wplus.net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
-----Original Message-----
From: Dmitry Samersoff [mailto:dms@wplus.net]Hiroshi Inoue wrote:
Yes,I believe so. It's necessary to keep consistency between heap
table and indexes even in case of abort/crash.
As far as I see,it has been a big charge for vacuum.OK, how about making a copy of the heap table before starting vacuum,
moving all the tuples in that copy, create new index, andthen move the
new heap and indexes over the old version. We already have
an exclusive
lock on the table. That would be 100% reliable, with the disadvantage
of using 2x the disk space. Seems like a big win.I heard from someone that old vacuum had been like so.
Probably 2x disk space for big tables was a big disadvantage.Yes, It is critical.
How about sequence like this:
* Drop indices (keeping somewhere index descriptions)
* vacuuming table
* recreate indices
Yes,my idea is almost same.
I won't drop indices but make them invisible in a sense.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Wed Jan 19 18:41:46 2000
Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net
[194.217.242.92]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA73941
for <hackers@postgresql.org>; Wed, 19 Jan 2000 18:41:30 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1)
id 12B4jB-000CAF-0Y
for hackers@postgreSQL.org; Wed, 19 Jan 2000 23:41:29 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id XAA11997; Wed, 19 Jan 2000 23:41:21 GMT
Message-Id: <200001192341.XAA11997@mtcc.demon.co.uk>
Date: Wed, 19 Jan 2000 23:41:21 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: initdb problems on Solaris
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: SCfrvyZGokcZPJ+JQUiU1g==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc
Hi All,
I know that the whole "id" thing in initdb is a can of worms.
We have pg_id but we don't want to use it, every system has
a different version/variety of whoami/"who am i"/id.
We don't need/want to use the unix ID of the user, but we do
when we can. The whole thing is a mess!!
One thing we need to do is change the default, "if all else
fails" id from 0 to something else, as 0 is specifically
disallowed and causes an "Abort" in postgres when bootstrapping.
Here's a patch to set it to 1. ( failing any better suggestion)
Keith.
*** ./src/bin/initdb/initdb.sh.orig Wed Jan 19 08:58:13 2000
--- ./src/bin/initdb/initdb.sh Wed Jan 19 10:02:44 2000
***************
*** 129,135 ****
# fail, and in that case the argument _must_ be the name of the
effective
# user.
POSTGRES_SUPERUSERNAME="$EffectiveUser"
! POSTGRES_SUPERUSERID="`id -u 2>/dev/null || echo 0`" while [ "$#" -gt 0 ]
do
--- 129,135 ----
# fail, and in that case the argument _must_ be the name of the
effective
# user.
POSTGRES_SUPERUSERNAME="$EffectiveUser"
! POSTGRES_SUPERUSERID="`id -u 2>/dev/null || echo 1`" while [ "$#" -gt 0 ]
do
From bouncefilter Wed Jan 19 18:56:45 2000
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net
[194.217.242.89]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA77234
for <hackers@postgresql.org>; Wed, 19 Jan 2000 18:55:57 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1)
id 12B4x2-0005X2-0V
for hackers@postgreSQL.org; Wed, 19 Jan 2000 23:55:53 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id XAA12300; Wed, 19 Jan 2000 23:55:42 GMT
Message-Id: <200001192355.XAA12300@mtcc.demon.co.uk>
Date: Wed, 19 Jan 2000 23:55:41 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] initdb problems on Solaris
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: hFZdQL1pIoYMD8rjrmmetg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc
OOps,
Just noticed we no longer have trusty "pg_id".....
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Hi All,
I know that the whole "id" thing in initdb is a can of worms.
We have pg_id but we don't want to use it, every system has
a different version/variety of whoami/"who am i"/id.We don't need/want to use the unix ID of the user, but we do
when we can. The whole thing is a mess!!One thing we need to do is change the default, "if all else
fails" id from 0 to something else, as 0 is specifically
disallowed and causes an "Abort" in postgres when bootstrapping.Here's a patch to set it to 1. ( failing any better suggestion)
Keith.
From bouncefilter Wed Jan 19 19:11:46 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA85220
for <hackers@postgreSQL.org>; Wed, 19 Jan 2000 19:10:47 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA13329;
Wed, 19 Jan 2000 19:05:27 -0500 (EST)
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] initdb problems on Solaris
In-reply-to: <200001192341.XAA11997@mtcc.demon.co.uk>
References: <200001192341.XAA11997@mtcc.demon.co.uk>
Comments: In-reply-to Keith Parks <emkxp01@mtcc.demon.co.uk>
message dated "Wed, 19 Jan 2000 23:41:21 +0000"
Date: Wed, 19 Jan 2000 19:05:27 -0500
Message-ID: <13326.948326727@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
One thing we need to do is change the default, "if all else
fails" id from 0 to something else, as 0 is specifically
disallowed and causes an "Abort" in postgres when bootstrapping.
Actually, I see no reason why the superuser's Postgres ID number
shouldn't default to 0. If there's code in there to reject that,
isn't it doing the wrong thing?
The postmaster and backend can and should refuse to run with an
effective Unix userid of 0 (root), but that doesn't mean that
a Postgres ID of 0 is insecure, does it?
regards, tom lane
From bouncefilter Wed Jan 19 22:48:48 2000
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 WAA90337
for <pgsql-hackers@postgresql.org>;
Wed, 19 Jan 2000 22:48:05 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id MAA25126
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 12:48:03 +0900 (JST)
Received: from localhost (IDENT:t-ishii@srapc968-yotsuya [133.137.36.133])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id MAA26427
for <pgsql-hackers@postgresql.org>; Thu, 20 Jan 2000 12:48:02 +0900
To: pgsql-hackers@postgresql.org
Subject: timezone problem?
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000120124950U.t-ishii@sra.co.jp>
Date: Thu, 20 Jan 2000 12:49:50 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 21
Why do I get different date/time after explicitly setting timezone?
This is RH Linux 5.2.
test=> select '1998-09-23 12:05:10 HST'::datetime;
?column?
------------------------------
Thu Sep 24 07:05:10 1998 JST
(1 row)
test=> show timezone;
NOTICE: Time zone is unknown
SHOW VARIABLE
test=> set timezone to 'JST';
SET VARIABLE
test=> select '1998-09-23 12:05:10 HST'::datetime;
?column?
------------------------------
Wed Sep 23 22:05:10 1998 JST
(1 row)
--
Tatsuo Ishii
From bouncefilter Wed Jan 19 23:38:20 2000
Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net
[207.69.128.51]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA05644;
Wed, 19 Jan 2000 23:38:08 -0500 (EST)
(envelope-from mhh@mindspring.com)
Received: from mars (user-2inilsn.dialup.mindspring.com [165.121.87.151])
by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id XAA29571;
Wed, 19 Jan 2000 23:37:55 -0500 (EST)
Received: from mhh by mars with local (Exim 3.12 #1 (Debian))
id 12B8fT-0002Ww-00; Wed, 19 Jan 2000 22:53:55 -0500
Date: Wed, 19 Jan 2000 22:53:54 -0500
From: Mark Hollomon <mhh@mindspring.com>
To: pgsql-hackers@postgresql.org, pgsql-patches@postgresql.org
Subject: PL/Perl -- At LAST!!
Message-ID: <20000119225354.A9698@mindspring.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
Well, I finally solved the linking problem
that kept me from making perl secure.
Attached is uuencoded tarball to add PL/perl
to postgresql.
Things I know don't work.
-- triggers
-- SPI
The README file has a _VERY_ short tutorial.
I would appreciate it if someone would test this on
a non-ELF system.
begin 644 plperl.tar.gz
M'XL(`&V#AC@``^P\_7/B1K+Y5?P5$]]=%AQLX\WNI=[ZLE4LR+9N,7`(.TGM
MVZ*$-("R0M+J`X?D]G]_W3TS0@+ACV<Y55<7U]8:1O/1W=/?W7+HA3SR3KYZ
MSI]6ZU7K^]>OX7?K]/O7K?QO]?-5Z_O6J]/7K=/7W\&\T]:K[U]^Q5X_*U3R
M)XT3*V+LJ^5B<>>\^Y[_A_Z$XO[%KV/[6<Z`^VS]_=6K\OM_V0+>.-W<_TN8
M=_KR]+M77['6LT"S]?-??O\GAY7\U-@A4SS$CAA^8%;,+!9&@<V=-+(\YEG^
M/+7FG,V"B`V#.)E'W/Q7#Y;B:J.K]\?&N=%ICXU!7PQJC(T7;LSB8);<6A%G
M\-D.PG7DSA<)=]ATS:ZLZ!.[##PO6`8^[L/8-$UP8KRPEMSC,2R)W.D4IL^B
M8`E0)C8""6O_:?GL1^[:GXYSQW%FI<D"(%SPB,.D>63Y28P8+=TX=@.?L21@
M+(UYDQ$P36T9..YLW10[.&Z<P'EI@L\MW]$\U^9^S%E2P`2>,!?V=0([77(_
ML1*7X(<=D#R6OV9A&H4!'@,T7+D.()`LK(3Q7^$$UY]O*,'\((%#@-P1%UM$
M/+%<GSN:ZVN6YQ&@+DR@8VD;C<`1"Y%:KF][*9PAUJ]X-`6(EC!,H&1(`9#Q
M,>L'[#9RDX3#4[A$C@@TF414T@&08%&PMKQD#2AQKL$A$?^<NA'>A$0QF`$P
MBN+N;_`$Z!H?BQVND*RN392)D>A%"BZM-9MR5F`(O%7<T8W$%O(J!=H^QQF`
M,I(8&.:6IDJPD:`)W#'<"(^1810ID`VVKP"7^?Q6+D!@F.UQ*_+@=-=W$&8\
M2ETH3I^Y49RP$-D?D.:6O8`AC[-;W!]GK)D5AMYZPXI&G_4'3+\!L6#F9;O7
M8^-+G;6OQY>#$8-_7<,<CXQWU^/!R&3O=-8SVN]Z.AL/6+O_L]ABV!Z-?V;L
M'&;#])'>&3<UHZ\^F4.]8[1[P*9P5H?D#[YIL+=8W1GT3?U?URB6[1Y,ZK:O
MVA>ZR5A[9)A&_T(;7(\9&YPS`HQ=F[KZ9IAB!W-P/OZQ/=*;S!B;K#OH7%_A
M(2C@340!`&5=?63<P-`-[`S[C/3!>9.PEE10VTO$V67[1@=T]3YK=V\,4^_B
MF3AC.#!-XYW1,P!E&#*O.Y=B"P%W3L;SV[7[7:U`249D03W4Z_VL(94[O;9Q
MI65$!81&;:");C:)<+WK+A`#/L,&6G\`).D95\88`(.[:-)QFG$U[!EZ=WL#
M0:\K?=2YA(&V`+ZIG1OCOFZ:\N+:XAZ-SG6O+6]F>#T";/4F`-4%)ND?&?WS
M$0"A(WF/Q0UDQ&?P>3@:W,`%`ZTD6=M]=M`VX=$!>]<V#4`%M]HP&.U<9#%!
M>3A.[#!XUS,NZ"H9(JK)(^#+5=OHC_5^N]\!".$>AL/!:`R$N!YVVV.@FEBO
M]R]Q!D)L$C-<#;J9^C?E;57R<U*KU4X.6;R.$[YD<9+.9@P&_R)5'OM'G#AN
M<+QX6QSRW.G.F!7-BV.I#YK1*8[-;#_QMI=&H&"VQGCRRS+$,80NS.QA"80'
M_%=NITD0G<2A>[PXR#VQ@^42M%M\`B?,YSPJ/@6%[<4GW`OF9>/3U/7`DL3%
M9[/E?&L7RP;C$I\LN!5:2WR4>Y:`^CW!_T!#)F6'`-EMT'9\"VPKL0"JDW`^
M00]A[\-D'=)*(A$Z%1EQ3LAKT%>NQSH!K&I[/$JD+S$-D@525!(4M3\M3J(U
MVA$G8"]0)POC"5;%G[_`931/*'H&%PNF/N;+U&>NL%*A9R5@N):PGL?^BP0L
MQ0R,+*YT$[*4BL>`4@Y<!3E%\6>/C!J)S^2Z#]P],?6KZSX]1:CD4W/[81+,
M.9P;-85YL"V8"-9N&:+=X%$41&0IF3%CMUQ8-S=I"E#Q5`$%V*=IL`)#XX(?
MH+!S$UII!K@RX?B$Z(/ǦUDK-02Z<^8#I#H1_$>COCG.P@+,<H^L_C?51
MO\C\Y"DBZ]<J=$#1>7-]O"+R&1`38CVD`/B$7F"A!5<>*8^K4S#(ID@CD//4
M3J0G3)P]07>B]GM-LQ=6!&J/'<*H#Y[I64T[!TDS`%X-8$F]9.+ZDUGJV_!D
MX#J:EAL&/W8)PZZ?%(8][F>C/NBF.+\I?)\`VK3EA_/K?F=RU?YITAY=F!^S
M$]0<W']WCMA8S8'#[IKBQI.(>[LSS)M#@GD&?HYO`]I?X.LV@<[^4$8((QY:
MZ(:BP,?`ZP[*MO_L_/`YY=&ZR!#:9^2%#R];2*I5`)="+`+0[%PLW1@^A>^X
M?_ZRY3#@#)==-AGN%X>[5I(NU?C*\E+:A<Z1@\12N2O:P%SQ'5UXP12"0@=T
M?75TCS&.LADB).$GO]O&&.@'=GI6,@&?`6^O.,YHE<T`>4NLB`0.&!9L"H24
M^:E#F&3X$`L`7\'_>'VT+K9F'!;A`YC?O^[ULB67-]DLDH&%%2^R.:!PV4A'
M]Q--AC$>],$O>P??U>JQ[4TN8<78FH(E."S<5'$GH8JKO+;S((+HRP';9WM6
M)&*SRN\/!4$)C>N[R03NJ(Z#C;.]4W+45E-KQ.XL?]$+$'EP%.J9X*`Z1E71
MK>P_#)#4D&/4/A:X)#$7CLT(W[J>?AQA*(POXH>O?M#T+VF/U!=ZK=T5=S
M)DD:>GP":RAG4+\$CVR,0XP>-!E]Z8*PX@`*[5T$6Z`.G(";&V<$`]9#M74G
M]VT.E;M)SW,_[CF,X(+4,O1*ZQW/!42`CA:S414TB;F%-`%!Z#>2CC%:"IC;
M38::4VBP#Q\;9R5;?TZ#A#]X;VWOSB5;FT-C@M[XPW=_'.BXO[1/#S]">_01
MB$+XB`/N)5&>O2"RD9PJ3$R]9-=LG\A:HPF4\B>)!:O]H,D>Q-]*R56IY;9U
M3T/3CI@!WUS+<W\#/\+SGD7IU4J5'G@+->U)V-4T0*H;,%>A(/RBP/?6\)_-
M\?F3<-#`9M6_WK:YC1IZ?DD:^>@\5($"F.(H6%.,D^5!4?,S=V.`JT&FQ(A_
M+>PJ8`7NFT:/'2Y<O)+IP)IRTBSB?.^$_;Z"]J42FIW#Z2(H!$^#D7^0H.-0
M*9DV7DR12(O5),7H<6<>(6^N1OIYIS\&,MKU.EB[!BN=M]=5JIY$,C(@9ZI2
M8IT<%@B6\]8*%/M2TS!A50%2_>"61=R.N)6`PJ)\=?62LL\#0\M0YH*#UYQI
MA"_/I[,+H+`CUA%4P"LF&J#+7B#$LROS'?>4E+HP@GPYY8X#JNS#1R#1[^S@
MH,D.CCC^_TZ_,/HPA*F?+AC*'N8PHC-526$F;'OV!6>V#MB7'-&+"H6&X`8"
M&V^FH*SS"@E$C;PR?30:C&#/O21]P^P@]1PJIM"V2-UPBZ@'@@G(]X8HX2X]
M*<3;BN(R/=G<Y[8VV7=-EA&O*:1([1:E?OEA-:T2\<IY`YERQ7S"MN:([Q*R
MA[`=2-F.5H0K!7F^O!%R5@4RP+>>1YBHC#(5Z<!79'$:AD%$&<Y,@+:4"#.#
M)7>L]?&3-0HJA6?0"OG@#WTY*BO#/T2(O*"5&[L836,4ITJQY(_*$N6PE\?Y
MF%),A1JVF*V6,R"A!4$1L80,D-18-MD6)`<PLF5(<Y'L)_]LELTEX=JD+H\K
M+(Z<'+)/G(<@S/Z15%\P3+%MK81\CXQMU;-"B(OY+Y&+0FL`44)5;)S)9.ZR
M8H:$I?HKXE&IWU-P=7>BAFJPZ@2^S^T$*Q<HCHJ+*D$#8T%;[`^&$CP1'!B\
MGW0&_;[>&>^Q"*#^+1]UOUT*&BK^"O!^CTR91);]2>9M1=E=./T@EA!5'L&I
M1_C[^/B8+O=.;?LPLNSD!;_]MII[["(S+K%D`I3'[3$#G9-]$'VE*4#2:`EI
M"`MK:V'DHHV-TZD4PVKNOY-&$?>3L3B7,@$_9.ZHE$WT'TI27$KX69;%RO)7
MP#/@K_Q^!_.\2,BED2Z#PCMF:YX<$_N0O[P!H$[:HK$OY;1)-&GH/N-J8,9/
M7!DT+)E%8)3#<,WH^<[&+1E,[-S^T1'>OO!9F5)6S^.Z"E]]`G<L$@[$T,*[
MV'*M0.!PG:;9&\?6`OV]7@9IC$P2@;P@I]TN`FP]XK\FHLF'9IHWQV+UB+"*
MY2!*,[8-42L,C(QN1-,-4-`+8K`Z%1H=86=J<.AA;1=['(X;R$"..43R8R(4
ML>*S+/2K:7I_K(^PPM2^T<=70Q,^#J_-RZOVZ#WHM<P1Y'!CDWA5!P:]F)B=
M=J\]8O^&C_I-NT<?WNOZ$%@4%YC#]D7;Z./NI!U7X]&U7K]8F3=U'D7S5:-!
M4&G#P1`+)W#>^%V[\QX_GH]T!876TP&DLVWV)P2%6<\9?,M%/?"&_2T&+]Y<
M#6_RQS69;S4:69Q+.H$*O7`QQ-\6<U!+8@^4\E0$JY(GAG5IX'XPQ\%,/`2Z
MHSK%SKR$+\&MLR+AM(%09`0&U]*\`8HAE@U%BZ\A6!^\KXM)B@SWH$\RS+*K
M`PX,T@@`C$.(!]RIZ[D)]G")RK9++(I690G>IN71TI/M+($\?X>X.TSTACFN
M@WIFSB%&`3(X2)K9@:+F!O8<Z`IR*>[B,!+WYPI4<TEXDGG9P?`C5R8VC85X
M;Z(_0`SB^L2C7@;"3IC&08A(XNIEX*3@R]9A+35)8I1X'"X;Q^"G-[$:ZKG^
M)SD?U4J`]Q)S;T4U<?)9'2'Y6PG#*5^XLIGB1<RFEFB=!`>O0G<4=!4'VE-"
M&9S&9)+#?%*O=T`5V"L4BIV)$J'"I/RLVC[*JX!<QN/4F/<#FTS.C9X^F0`_
M@$3\9-8/-I"\>8,G0DQKA0?-;3";U-K7V*P3@)6L$0^R^<_"9V3*,O.=MRR6
ML"N9+DH68#;F"ZG\Q<7&28#Y,&DYP,YBUEW6M=$D@!J*8W#Z8LDN(=;7+6R+
M1*<%ME\_@]$XK)7B5LQ&$J"'U,[9+$8FZ*W0=>>LB[+L5.EPY6\[2/V$4M>[
MMB9G;&+*86#H5G<IQ\5<]@\Z^.BMJ-XS]]MOA<I$52J>Y)HFW(_BH5"8&KNS
MZ@="F*`+('64)5<(I4FV79-.$"&&Z0*AUN\L)8HPK5ZG"@L5EDT/M,]A`XB*
M*!R]Q0(10MHX>@N4:CYJ09+8XL`N-=>&P%2DPK6?D(AQ70))8U]8YCU*>4R6
MF,.J'V)GVF1F.4Y4_R9'Q*S)!<]JR#JNM@6%JN]JK+B0.E_V/\:F%Y?J7!M@
MX]7DI:!VG2QEN*H#A$W6:C0$4B$E_&%,X$-)W8VY(:92.3EB8#"UXM2L2^9^
M5V7'5Q';?OW#:<$TL[QM9OM]$\$:;,MH2A9SL:>-FN>5JLBLZ&.\I$?#0CUN
MQ8,?Y"AESOVV(U/+@Y*'A`!A)8Y^[7ET<B&0(HU\*;Y0`BCB\]0#QL^0%I%M
MU3GJ0H;G"=T+>S,\HG\)E:GH=:(`QK=(/U/;T^O3EUD3F1R3/6U9MQS6^USG
MK+;3,D;GB[XDT6.&C^':5)<3+-XH]=B=_[(,0?/--.SW4BT]U<3U[U"?DF>K
M$!398$1'<"^]`"`O,V8#UWEZ\"[H`CP._X.B4A'PT=N9/Q'-'#C%#M?U;:J#
MA$TFP]Z&F@=JLI643!8'431%:BWW?7-C``>,PX>=#2K*@?6"X%,:2A]CA\C2
M.T$K4F%I\VNV6$VHRASOE"^;;)=2.7HT9/GSB8AK67<O=N2B7IZ!EG=DNW$!
M97+K+8!G_1L7"XM,IPQ]3-Z]T'+8&"AZ(-')VZQR_:,3X*FCS>HM]V_J!1A%
MPDH1;XFEHL:80<3@M&A-"@U;B7&*F#=><&K)Q'[<K'9":6T1BY05&<3ZI]VI
MEK63(.O:\.FL,(CDD(/G0;2<R-YT`L\DAS?_B(B'_VT>8=J"9D\RYG`P?-2D
M_BL^0MWYX57K?_[^,9LAVX/M20S:!'MEJV&AMJK0B1O:D-N1WAB%=GBG55!9
M,<D/9>YX`^(%*D/&[F\\F.W,$!Z4W.+HK10IV$LMVZ-EV+?LE)9*I;>]PZZ\
M-JJB;DXU*8XA5Q<#;U+UE9`4V17(8'(KLA?F.NY@/S/Q;7TX&G0&1C=S8=$8
M#Z:_<#LQG`N>D#7<L0^%V:TF_2,"DN;+A,*(P=J[3EU"0.XU>>:BIV6+RL+]
MS3\2(WNRP-B1[0GJB5<S)?E$3NQ`><_:1@"1J?*RV6`7^M@$][,SSD"LZEZ!
M=#*?)E]:S'>4DU:C8-<._!6/8IG7@P5BM?0CJ0&N$N4EM=,>'AC_/-0+/%#&
M`)*(=%T`'^[X6#Z04#P?'P198$L*=IL5-@HWSPJ$28X5%)3$"HC(9AG$HFLP
M*8`+5KL,?X5H#3#]4QE".?ACX@DDH,ALRE(Z,-.:)PHK^(\B6^2O;4B)QYKL
MFPU$Q7=%MO1E\8T1)!&BMH,_/MRW4'AS6PO(*?^#Q`H\CZ)<B75`2,O+E<`W
M'DV%1DOF:S`ZS^E+]09&F0%O8<O.B_]MO<#GVRF@W4TH$:18[7$B?9]$J]="
M,%^1D^HML7Z`7`O@[A*$$DEXH&QG2:P=Z2;Q_O_(]R,$/'?/A>R;>#>$D(CY
MW?-:XLR]`BNXMR"Q.SDJD23:?BPS4?<+[>Y2D:7:+[9?*I+=7+612HKJ]?V2
MRJ.P>>CF.P%3=0R+PC4G7Z",@^RM0]L2F8ZLOJ$BDDU6.DN0Y>*)ITN^\K>1
M@(`6AM/?;$M7'$E=JVI:HIJ&K_5BR,.F'/1F''IN(FV8Y8CZEB0$W(45(S$P
MBA/Z;;FD=<DM+H7MEL?L,@"IX*#WUH%/?Y:AW3>-K!"V$UJH%%>XFE$"]^"O
M;][\*@9%9^`!RX8!"^P^2";8[E1_\0:66Z#R7S3.#F@.W@_B`Z&,&)!F3*R-
ML(I:9Y\_X-VQW]G?8O:%?82U398CH!#(4&F'XG`%_)=KX\S'C)NT@.I(J]`@
M9"RW:8/(5:IWKF3C.^WN4*G3)/IO!$$**1%!%<R2BL1<2>!3G49H.YL0?C><
M5/T#N<3,TV\&LS*4L'AL4J9)PD`"XZ[J=>.FH>@LC>.7FC0`%:5NSBE9<P=Y
M=O-6SQY^FROCIGX())SQQ%[LDE`X#O?0L:52[35MR9<8;W^33ZN"]?O1BOS-
M5QGLY^<TLL:"V)V+/X50+RXZI7ZTELRDJ7.*<[:.E>?DYS3R+Q"4O\EYJD3V
MZ*CDG5`!PCU;M"CUX,Z]P)^78:*H54$SH&K3'>9+MQ5TO8GL>4[)%<O&DJVR
M;J^*\KI=-U8]A)0"R'41BM99S!7FW`YAE&BI>+<,7R!.E^!USW(%Z*QP@G^I
M`<O<E#R2J<B:L-Y@7)=I3'\["?^,D.IBSTK=!`E?!M&:^J+`+Z"%JEL%^R1G
MKN_&"W9+K?"HN&'WQM-;H+/&3+%_H2_SW.@;YN7>MLS"JHUW7=OM=RM64_=&
ME\CY=2JV20:A0IMXKW%/U"E?URQ[C)EQ*EWF.WKDQO3@25*>:\LMD=)-^7V?
MF+,GRKD2\[)FP3M?K*V^OKC=']G8JC"J/M/G*2QFT65M#SB[;PACN3#?A'J(
M2[!T?V_Q<+=2J%Z/UZG^<(AFC6,;AZQ'XG=P`NXI*69OFFKR35,8VY0*,'M&
ME0(\JVN*,""!S_;2*1E%9,KG`R#B@8`-AR([^^J2C51_G6$9`$&2J/AW'&`P
M^SL.&2E@T$_A9K/E"/#$3Y<P-3?Q\!"'U?)GKI*:^#=EJ)E4M!QG/(BWS%#Y
M5M"9K[@&1'6WLQD0+VMWSOI)_ULKP<B33RD$_R?6=Z52`*HA]N>N[V0:XP%A
MA;(VV2Z%=U[_P*)OEF3YPVNI>4566O+</V$:..MBY357CKVC\OIGB317(@5/
M":*FC5O>RORB/TNJ#[R"/TNJ?W1)-9>_`T]'O6E*?Y)/_"VYO/Z7>5,EB14K
M+7Q5D.*>DO3=/=-0?VW/:X<A]QW=HS^%6[(O7A*,'3Q^76GZ[C$[9%S)#L87
M$Y)]^"TJ).(#>)4Q?KS%8!M^BY`(/@0A4PX"L,&DK_]8^#[H=;&@$Q]4QB!@
MH&;NKSGUB[1F_]?>DW8W<62;K]:OJ`B#+;"\!9)W[``1MB!Z&-DCRTSF`<='
MEMIV@Z06:LG&A^&_O[M5=?6BS6JQ)-TG,UC=M=>M6W>_U^[@DK\/>U>-OKJS
MJ7ZWEZ6)DWJB7NQS(00IK!)VG`.*7?P&81IK"L:^%A0G+49@(>4KH)6=O@LT
MJ8(.7?+C3OO:Y(U+`BX`%C/1_)HJ;B7O>7+5..$V6_T\K./;KNYVZGHYC?CR
M%-('UQL76BU'`"AH>IZ6$?*6(Z`XUZ"Q45=M0AOA=U>1=\`\4^SF*[5,BN+/
MH:\8O*@)Q'_D)3:T[*KEJ]#[+Z%?PRX/`<J$)C*K>FK*7;::-=N1I+>Y+:JQ
M:I&Y<"(.C;:/85A&(-O%ZX_B80U2L-DA=EZ8#`YX6$8]6D*,"[-TDU8.+ZEI
M%L[61<DX?H:![!V<'K[\NHHH51RCC3+!/:S%T"+#'UU3%68R&?C&L)DV^1@G
MMN^)W,KL_;$SP,882*2K-67%="LH:_O^";HM.F4)JZ+ELB+)0SPJ<J+BD\$%
M4T`P<`"[UBG00BE%;1A)ZS:U"B>@=(70'1=B9;ZEBY&T(JPL[([X)B++D=]9
M<)F2](>\76%1V%>ST;9$9&<.)FI`C\4^)PX)L%!A_F691WOYU927,41O[5WR
M1VOSD@N8W?M>5*,8L*$>NI:)48F`;H0`D748(8B0%K68F66PM@F:YH:F["2$
M,Z15_#O:(0ICQ3!*]ZTQ3*Q_YL*2I+BC,90;/;2C!CQ68*M*JNWZ9,*%2@5*
M6$-KY"<-DCC$R>LD<`?D03[)(U;P+QI90GO&%G+*-DUM4H*\<=_17SCD=5RH
M*1<E3E[9!R;22.*)FH`N#1P0-]T#*-?0`(>FR]9AFM?6RMYZK?+B1;EV^KQ2
M*^^?/BL_/ZR5PQ!`=0N35XOFF.<6:`_(ES;>1^EYO5R;IPMJP/0P9:63ZLOJ
MX;^K>7N9&)>,7"?^G+Q0,,G3VN&_YYD&5!^W3-C#<;U4IS0E\_1C&IEWR5C%
MA,O$>C,\PZ31%73#<E(KCE&BMW<,EW%\W9RA/_5I@ULJ#MXFO*05+F[T#GH]
M#BB!P\57*!70\8V`;9?@(PG'X#^GE>IQN39JW3]/N8+<2'Z$7.`V&&*J;J5#
MUA1'24ZSY`%EG@!]L`+[Y8-R?10NF'8%N)'I5R`_24PY_5K-OP*<-6C.%>!&
M9`6F/AA,)5GG(GXP+#+X]NLEC2Q^T?6$HOS@S(CHZYVCM"!L3MNB&8B"!"H[
ME1C%+A"X;<H2Y\0DUJ3KV:N5`<B5G*#YF:,8^3:2`+8]6^:@I,FA1J)MI&@I
M"2-*T5!R!IG>".!%UFTDS#!?E\K\+QV4:QFC20Z!19""*X)W,MMC46DT6O%[
M3M,%[EL`7W6<)I1P_8X.--5G>Q7MBX6Q&)T6L^Y$IU&DS4&_T?4;9K4Q=F-_
MD))5I%Y\%F22%$#]][]JC-4?(S@[X'%R*9:'3F:&)W/#4[##R:)4"FPR41KZ
ME?AQ_]H=-"_UBLLR-M&%A47(.]C16=]I?"`4+-XD.R,G-^P&OH_00@@F[[9@
MXM+1;EHQW>L!X).%6V!_%<@8.I0`[@Q#`&-:SISVZ^DT+MRF>/?XZO`EAN8\
M?EDYPG\US8VML4(*3L9W:?-+\JE!OPF;/!JJH*'#E_F"`9[`=E7L$J=L!)<G
M:.9ST%*0I*;`EG:I[?`>>8AJ;U(<1W2G$T-54\`+!PD&$\7,Q+H^Y52^1#90
MI/0TMI6$]>@9=@"`,RZ^>=+*YH3NO&=9<*[Q+S;<+(34.I\UE%0/ZY6]<EQ1
MPRYJ"0>#KV&F_&^+GG1$*&NLZJ[:MD6AS0\DB[+&/[)#EWTW]6"#8Z?%:D6V
MX*=LA<@2J#N46Y?I#=_$J-)VLZ@VP*ANF&6"39_"`BD,5,GDG]MEJL\8UQK#
M^2DJLX']]/(O$A#+$-F+TT73JUU^S?V+7ZC8[ENY+[2E+_IM)`Y+C+C$7$P7
M7U,KW96UR(!DQE3@3?A3X.2<#F4FLOR>YW/4=4NHOR(R_W3.WM>0SR>#]'<B
M5W>EZ/4E!K5<13"T3J<FCSB+XV``K\.6F59,',X8J6,2A-Y(>LH@]^0Y&L:E
MI;6O7'2]/N8T=88MSQQO,?%1+4!J*`1.0[^(.W+?VD@*S`C;L;*^8DA$.)R/
MU391<>@7Y':'3IIJ:AT>P1+*#SMGZ9@C\`8K)BS.N=U5(\^PI_W@P3MC/*!K
M<34ZI*?5PU*=,T.7"R-)/HV_@ZFLW/57\J&>BD4=73%=L]&@3PHTH/6JDHN8
MBVNQ:=AG+!6[C^D#.R38E484';+^1;7%&@\\@3,;F\;BMB3NV%XL7$-HZW@M
M[Z*S&Y.9,H7(?LK;V\W+<#D:T03Q$%8GQH,H!#%3J!U!3;,W(;$6T@'+X]B1
M!G8:$\7C/<Y1U"Q*EIP-4XIJ8FYS:ZWQ)E<<K<2.8:$#S9R;./H!\1&NG>Q!
MR/787S""2=A;4%:5?ZS^_+I4.RA72\#<_%7>/SVN_%]Y#'QPN^II5`<8!:&V
MTZ6".Y,*PF!@>EC6N.8:(6*4#4C4Q*X)AQ2EH0(5BB;IUI192/J3-H1@B[6R
MNER@IS7E0Z^">D)ATVB#7`TC><,02Z/CS1=5;0_F>K=%QH98S%#QN62"9AX:
M*1=E*Q>3/X&6H(#15/DOD[D(41G9BBXBTW#.[GW^?*9!X%2B!G<7[98'2T04
M9<>1.-ZM85]G@-""0)*8^"GD5IG@HAM(#8QX+RV.`X59]I2$;";T>^9<`('0
M(-3;]S`O2\X*X3:XI/`S*.2T,W"(P!-FY`XHLXC336&!?@B#I,FL37P7C6P`
M01Z'\HNEOH,;LD;H9U5+1/+^37?0^"0AH(MJ!4^7V`IT_(N5O!&,8!^O#P]*
M]<I!N3"A;Q%DT4G;>@>]L)3$$G_I1.#\P38,B-7]=ZE63:BI^QQ=D4K<JN;S
M4KUTD%"3WH^MN5]^=O(BH2:]'UNS>EBI[B>N$+S?C6H16>43W<R3[H>N=]U5
MUB8B'Z`[R6G_%'RID_C-":,CH"`EM1+?+VN$39`WI31R0">@CLZ@&"2,!&M:
M07=-3AU,`-6GP!5D0(T8RFFE8--(8Z-%EA7>?C?O_6VOYN'+15W?G+4;0Q70
M7ZKM`OC`>FHY/,4)0]$1)3^BPW_F*,IQ`NA;9[66!(Q2:9$7?CI9QG7:$?)L
M'710U&)^-GM;X9_;::H&26_'>#:=FUVC]NW94#OO-F\88H!I,?K\ZV"\?OU>
MH^D8@4"G\<GM##MVB+=F@Y69%WTT>_+H/+M!ML&>1[-+@0#@7!>]D&NNX,D"
M]+^M!;H`&E!.OM#O;32`0/A)Q2*[T?Y@(N_)&G!:H"'):S%$G1Q3HJ`:S0]^
MN^%?SK\`(JA$V+>4M_=IOBB$7B%1W!(>A@</%+]A%0+9U'W6.MJ@QENN85=Y
MNZ+%#.8EEL=,?VFI'RG5GTDZ'*P@N7D-T,>0.:[Y5^P^[[T$(4T^=)2@)'JP
M0GE*O@J*UTB:N314T:(5UL!&WV)/&&14E4,9T^4M$+.;84Z-W*?AY_R>R\%=
M.*`-\'-O?GUH\E^8O#";-LHG#;/XZXO:ATMS_G"W]<F\<<U?;<_KV6%DNAR!
M>->*8(-WC7X9"W43]#6&]31#'"+;"%5B>-UL:3ZWE']:Y/EUG\I/UIWCU)[*
ME?T4QTT>OT_S*447HVB;+437-X-+/($N!=9`(J+1QAB=-T@Z&'L73)_VX_*X
MQM['NM@)Y5PX6K2(.^#UTC&$,C?^[Q,N?`*0Z:]U5YA(2V.%W5B7@<VCN,BC
M,#!93(JY!1X\<-63Q[H!'=IXMG$FCE3B%=OGD\?SX,&[9.50\LAI3[[%R+5E
MP@MG`/C,-&4F`;P!C2UL7S"JR=ALQ32(?AA<A;IMD5,$[X))I@9"\Q^FH[[3
M8U9#"3-G28<"R5!?BX8XVV9</!2VAV-;N$Q*)%*B$?Q!/;I@7Y4G*%/V=2;;
M^%X*+"5MJ[44:'TF"$3E0/0&G3YS-.`,\A&<6_RNK?FX1]N:3VS,3F!A*_7_
MD/W>B&W93-J&*-D8:?:X?%"IU@]W(J_9)2/ZEMT4HF_9=)\&YO>`BAZ<KP(Y
M`N,AJT$L)-)IAQTB1PR?ZMQB^.6]>L34T11@57BI]N($'7M&+YT6;X75,DP&
M!_J8>(OYH.;8@1L:(CJTDZJD<2_O3QK=U(.SVIQ[?'N'1V,@;M9EP];F']))
M[?BPEN*@J+VYAU6OE:K'I;UZY;":VDY:;<X]OL,C<0^9N')3#LXT./O0;%/D
M!(PA*-"@BF2)];A1Y@,E;WXHDNW:'D;JH6Z,`'MQ=]1AMWVC&#G1'>6B!2N[
M.TBN!$]=.D"^%.'&@IOCS.ES9B*T;^9L-,`%77CSDR(YS5S*+69PL1`:^NL3
M0U2$BL,/"@Y!*64IQ4K`@H:_!U%84Q+]732`\^L)F9=Z8(&,R!J[^A7R$^T[
MG/%=&<9?7;A7&&#^/=KU^L*VF@A<5#4(H^KVH1#[NZ(6!7C\0DC/<JEMYXQI
M/X.>[[2=YL!)(?2J88&!>PL8&I30!LQJ^`28'8/)B>\AFUA8#)APE&33Q97?
M;+XSAB:T,0EX3?HIC-[S9!(H-34;TD_I^6XP;#0LT"AJ,P12Q<NJXGYC:I(A
M9:$4]PTJ#G"-D;KFWV2SL20=CMIT:]F:9<P]PPZ[9H?=T`[GC!!/',W(Q2S$
MHP=<0L&D.3-U0AR[S9LGE`)ZKEZIGI2G*5LKUT]J52.GF`]V;.#AAK50/J'G
M9[5RB:>C)0O?JX)8.VHFH2'9[?0D`+>:^WCL,0/R^&HZ`[FG66WP3%0&MG67
M%&A!);C7C/*@+NZ?.DB!U98I`YMUW;B!:P'6SF<',6A##7VW>V$*844L0)^"
M2P8QU`>'DMP&[3412:T'2`PN./2C;)(T*=8[M$5^.3H\.O4@,=+;-^N+5G/H
ME9U:T[$TA:9#)\PS<>;EMU&<(^KBJ%T?A:J[\MP6!W>&^8=T&DG."#BVJ4+\
M+]1V+E,OI&LW,*-)F`6^6E(G*1!O81Z6@B4E>=;9?OEL+X]^:XMP)`Q1`]LH
MKZ=C!_]2?IZPV'XQ,&'L)^B2<ZYY&^A@&]_*%`BP2,P_&WV,")8>%`E=>!_9
M4ONC)#^XV_X$5]\JFH(6U$=-7'\,)P+5N.RC2;G(B5W9I\`:`5<P;H"'XLP0
MU'.[Z&-"-8,$**.JZQ*1-L2*_C;=)W@R)E<-'!B#RIP55KM/)M<3K\E,_?*#
MJ%_(^B,"UH6$#P*W29\T."9]LWPA(U\X#93]VO:CE.QB"\34MI^8C:I]S"]@
M)QSQ;_R!TU'B,V;,.`.)VO3)P=,/QQ(*NT*2M4E>9]72JW+(;^R(S=:,AY8.
MP#*'<]D4CF7(!I$CF6_\R%00^F4IBFF#S+;01_')X%2<<4XYVY/EQC23@Y@F
M9N_%(=TDZ8T#NCABS^!&%FYGC#MW&-M*$<2IT[NMR<%*606NF1+R5",JD,2E
M2(:EP,E2TX]MSBPP/A>")HZC-!F,54.Y=P+3JJWM_R%##&.G!/2X[W$^Y/F4
MJ4:;:KE-:8G(..7@$H\`3:42E'ULKQ&H&2<I\Q);L[5SDQHTVK?$EDB;-K&)
M0%N6W`AKOR8U$]5N);9EJZLF-1A61R4V%RB88HW9"J2(K,12]QCULQ6=Q^H*
MRD<;)KN8D6YZ1L01*)HHX@:WF-ZQ/K8%#2D1Y\4GUBG68A(ZGIKB"17+3NR4
M)_;;0*+9P$6#8J7K.T3;FR#QRB&!CK;YC4C;C(`?16XA-YIO+%"=*M`_\Z2<
M4"[,B-JA_47V,2FR_T>C*$@6EH0[^&9R6U2=]UAJJ^VJ&F%9[=<PX^[-(-V<
MUXK;Y6;>FQ>DQY"4=R/%EF,$HP8;ZC@_0BY.-A&W#<KE#1P6+<^0Y>)9WL<O
M(O`(M3&+*7E0=]$6Y3VQ(><E8>>*IVH:$W.<X],%6)K7W=:-TDG7&JAZ[`/(
M]=.2..`5:K;HY_#]R5RS_LJ<=&PWTT'8_RB!MX[$P_;ROL7^I";[_CM:NH\:
M.)W5;S%PC3=O,^A_@G5^6JJACMLEKTE2#YG0Q.F<?_?[]!+0*")$T9A<2'!G
MG0$^'*SX2+!^E9S%-HUI8$7S8,G9BD?;0.KX7=0H_&M<]BG(4\1;/W&-)ZAN
M!,"3\C6E9&364#:)@,IX,3`+Y%A-K]]WF@/5=KH7@Q3,A<CFBSH-W]."8-"?
MET/YX'=;UV3PRVCS62".\CQ.%**&IM;R'!\OYPY%.J%`F.8,SFA#2R@H93N_
MZP::2H@$3S+/:/-+":ATC2I$";V";)^6S'.04JK232LL9$C'%]BF1E'-F/U0
M^8[K^^34JP>*0YSD(V$M<2Z=X&)QK3/+F',IQ4,<HW36%Y'F*N3O!/5SLJ5V
M&AD=Q2JAP6L0AGL^#.DMA9GH[$<W'X(2039C#RTA)\*78X_O",Y`4R1)W$$2
M?R!DQR(A=7:=[@Q*72MJ%=>#KGQ'YZ.QJ)$4@NK-H_V=4OV;BGDE*0S?L\+P
M/?`6`?>OWI/24`.)A1%%^?3^'93?5/?N,>3%]%?P_>>P`HNI3VY/`@NLLFRA
MH&)*8:@O8TQN.ZX;$_BD_TN$Z220GB*:_SS6\8O%ZQ2AG,W?\?YC6886C%JR
M-3%47-*R4;I@*9/#.4G#[-BFJ<#_9+`B*!B_K^'@D7$-['N)^;ADMAE>"1&4
MH)5-^,9@7$AS3S!+!]L%X'V(F0P2B)0T4<Q<\:@G2H1TR)3@6B-981IT7\VV
MD0!&Q?FD47&[X9MX@I([A"D^O9+%D-$_Q>5G1R=.UG`.UT4:5*`1R[)/>F:T
M]%T8+4V)6\9<6&K:NXJOJAENJBDOJB\B4/I!/;-L]_=T-,0Q+_>>K0U>BVW8
MFI(4!2GYOJ?@T0%0>=5`UKW!:0S)#&5-G>O[(,9ZI6+K->X<:&YUSE-`AV#Z
M,S#=$4A->C`F@Y5%`*4`H5ETA"PZ0A8=(8N.D$5'R*(C9-$1%LS*B*C.&'-Y
MP["EO*]9139GRX*J?]?\PM\HDD,@$@@KFQ<6Q6$^@$DQ!L0_((K#=Q.WP4!9
M%K<AB]OP=X[;$#M'!:1AG4%P"W"*,;06TIFQ@L@-J`KE.X37/G4[80PXD!LU
MU`3K8&,/K)&`9B@H'`+4[GIK*C"*I>9@Y;4EK$$2@26Q:UOQ>L,!D$'^H+\;
MMRPF^0JE[\.O9Y[7ALH^2LE"9K.8Y`H&MIL<,L$D:^2>[#?LIA8*U]#O!2/!
M-]APZ!7;(X?,CM,D/'5`?0(1@>S7C?XV`!%E!Y4`_(R3J28:FQI"8YWV0^>*
M3"M*@3&`#!GV\&+!*MP+-F!)U@O?ZG6R=2Z1>KKE2$VKO82C3U.TKWI:GX3+
M*L^KH3FP3>W`,7UZVL7DM4PI::>L$OJ(AI.^N9SK#3^NH]@V+9N3V%1\EONF
M-!G<^DLXP*<7S@!_K@HJH:S`AMB`2X-10.$;9\]D=/*MTF<2`IZ4:=+]7A-G
M"G2NS3:#0*=ML/GL&2ZY'C7U?63)M!G)!A^HM1CC:(IV/:"3AEU.ID%O^=.?
MG0ZF>:P.0U2%NG;A=[,Q])W`%@+3"&$=A(-FO^%?HC,#=':C6N3FX'SJH5TH
MO,$6T311^5['(;\'4]'O`'$&)"*.?#T-V"<HY).->AS8$`L29=,,+";D6PYG
M]>0*5EI/+&%(#=SQ44D\ES#O;W\ME+9S:02&9;=S2[89NHF$FH`_Y&I;4V8$
M^NR)#LJ\+VB.0DP4J.$3W.Y)3<OMAB3M':?;<L\70-EBSI*6$(Q:]4?4+48F
M:P'TBDTN(0+@)\XI8Q!Y.09I3<A1*`RE"Z=YCU_?SXV;P\SD*S2H\#$TY<RD
M*KZRVV`*^)8$K$&&_M7I=L?K#X#Y[CK7QZ][5ZOYSWF$#@+4C/)):2H9Y9-1
M/AGE,R?X)5(^E%"VE8`XB/,U9LYL=RB^\&A^R$3(4H72TJ),'@D)^),HH#/A
MD#T@G5K.>4:P+,%%T6P,>E?GJ[KG/('MXR<$OFOH\J1!-4R=)),LBA*I?I[0
M-*V^U;8F=^`_72NH]"6/GPVT<ZYIV/=3*'1\=?3:E.PV"G!CUTYL$9^^*[_D
M?DI^^!QOU,JE_5?E$67F?3:W-C=_??CPI\W-S:W?'FW:_V[2WP\?_;3YV^;#
MK4>;6X^VMZ#\UB^/MGY2FPL:3^@9HGQ5J9\ZEY=CRTWZ_H,^3W#[U:O&!^<<
M\/-ZKYU[TH$?N5S3Z]U8:EBD9]ON6;^!N56!#;HFC(6.-SDR%?3\`2HK/[8I
M%R2BKF:C"]@&L-I@735\'RC,'/GI]!J#2\1,&T._OX'Q(]L;O0NHN-'Q6L.V
MXV\P2*[[7BZW!W!9+ZOG)U6RQ-`$.)K#G7)*GCX0WJR$.%9>K_$1B)'2L5J9
MW/B*.BA57YR47I35RM[*KND+#M!QO;ROCFJ'>^7]DUKIP"K(M5=R?Y:J^P?E
M6M)X<E!Z[_#5406_KQP=;!QA#6B_6%0:R_MN!XELYU,#_XW-$G`;D-BD>'JX
MAN+EA\$<\9?"&>;DA"^?OME\!P02_+OU+K<2'RQT+<80NMU?UAX6>$#`<32]
M8=\'[';C#6G+>K!72D=YT&M2>G905H-K%,KZ:A5N*>3`+AQ`MV?ZS\)NTCRD
MSJK\&YH'UN*I+`^(YO$OW7/`57IB`PSW]CG?R'_!Z<FOL_R7W8FSC/7*JF;^
M%=X*K\M0S!<D$BGKB@*XB#=10-Y!)2IS[?4_H"AUP)X7YG*ENK$U.&NTL(75
MI!WTX(I?K9=?'0&6?[(QZ/0VL#0<0\3X)/!5^%7E7W@#X)-^?MO-F]79FK`*
MIE]X-0KWXR/XWT(`Z>.8"?C_E^U??V7\__"W[<U?MZ'\]J-'VQG^_QH/BL3V
M;[J-`Z_1<H#UQM][7O?<O>"_RY\&)P.W[>_LE#MG:+B4NY.[HSJ`)#!&"U&=
M+1TB`SYU;M1RNP6_T6J%_T`0;%YZG=ZJ?"E((SHM)<401NL5L?LY[)&=+V-L
M:=/C=X\5)OO]#*3;,GP6YG>%*R#P+V'9EHLB!.!%T')`K?Y1J>X5E#;D*+94
M?OETHS$<>!NZC3Q_7L*:&'8F]IWH/?1<L<R;L3&@XMRNTZ(NN8U@H,&B[NRT
MVJ=0D([V:KYX@,6!^-/-BSX&_B.$\*KTLOP<;@]$"OI8(D(0C*`_J]]_/SVN
ME^J5O=/=W)UB6@_MC.X6_H1'_[+"<A'1X%]2S`./.#BJ5SJI'[XH5\NU$MZ@
M-E%QA[>\[@"B1/I":?HA1#KX<!<U'1\(C2O<^./:WGZE]EBMKV_P?WZ_F7.[
MS?805OCM\BI_+P3(ZZ+MG37:*/K#M/"2-KB#B4\[/?C>QZS+-/26V\KM[3U6
MRPSJGYO-+SD+(DUY'?N%"1>L>=V`*P30_/.#THOC!X_5'Y_?-)L,YN^^0!,\
M/'UYP.W"*LP6ZN+<)L!Z`S\&]8,1-%OM\W;CPJ>1P"4FOE,T6VY$5NKX7P=!
M_6(%%N*@\NSH7[@4_%.OBU3&]M"%`1FG]<M(55U6J+:<W7G0GY!^KN/G#O9+
M^_M8^R#<<;OW,0<?H_-JM_2TU-NW<&P%.>#?10(C!HS]@\-G_WN,%S)V+*N%
MYAA%7#$#98JV&6IP^<<"BC"2_8/CD^?/*W\5<KE*%<\'?*376*Z@X%[\$P9[
M6OZK7BN=PE\T1CZL/()>>^BCS-_KH^^UB]8>=W+N.1QQ5?[K"!O7#3^P6MY9
M]Q[##RD!G"C+G'-W@<+<47?7O=P2?-X#!%3TH-8?\+_?L;8L5('`.#*R`A>`
M92[D>&PL5R9PYC,'VP$?Y!SNR"JLMZ$W^#+PO+8*>C44;U!L0J_V`'$J4`'G
MTHRWWJ2_S%1^E_'NM1V@).'/)OZQ`]QH1Q7/L:PL84'=7_?@?SAB_-8_5^O0
MMJ]+&@24:SD]!?^#9=W)Y33"&T?09$_V9$_V9$_V9$_V9$_V9$_V9$_V9$_V
M9$_V9$_V9$_V9$_V9$_V9$_V9$_V9$_V9$_V9$_V9$_V9$_V9$_V_(V?_P>F
':7>L`$`!````
`
end
--
Mark Hollomon
mhh@mindspring.com
From bouncefilter Thu Jan 20 00:09:22 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA13589;
Thu, 20 Jan 2000 00:09:00 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA07748;
Thu, 20 Jan 2000 00:08:48 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001200508.AAA07748@candle.pha.pa.us>
Subject: Re: [HACKERS] PL/Perl -- At LAST!!
In-Reply-To: <20000119225354.A9698@mindspring.com> from Mark Hollomon at "Jan
19, 2000 10:53:54 pm"
To: Mark Hollomon <mhh@mindspring.com>
Date: Thu, 20 Jan 2000 00:08:48 -0500 (EST)
CC: pgsql-hackers@postgresql.org, pgsql-patches@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Applied.
Well, I finally solved the linking problem
that kept me from making perl secure.Attached is uuencoded tarball to add PL/perl
to postgresql.Things I know don't work.
-- triggers
-- SPIThe README file has a _VERY_ short tutorial.
I would appreciate it if someone would test this on
a non-ELF system.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 20 03:39:23 2000
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA78805
for <hackers@postgresql.org>; Thu, 20 Jan 2000 03:39:16 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 12BD7X-000DJk-0K; Thu, 20 Jan 2000 08:39:11 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id IAA17493; Thu, 20 Jan 2000 08:39:03 GMT
Message-Id: <200001200839.IAA17493@mtcc.demon.co.uk>
Date: Thu, 20 Jan 2000 08:39:03 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] initdb problems on Solaris
To: emkxp01@mtcc.demon.co.uk, tgl@sss.pgh.pa.us
Cc: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: LcSOx6KtVbMpHIE0L63kew==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc
Agreed,
Either way, it's broken now and needs fixing.
Keith.
Actually, I see no reason why the superuser's Postgres ID number
shouldn't default to 0. If there's code in there to reject that,
isn't it doing the wrong thing?The postmaster and backend can and should refuse to run with an
effective Unix userid of 0 (root), but that doesn't mean that
a Postgres ID of 0 is insecure, does it?regards, tom lane
From bouncefilter Thu Jan 20 05:05:24 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA05193
for <hackers@postgreSQL.org>; Thu, 20 Jan 2000 05:04:37 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id LAA145356;
Thu, 20 Jan 2000 11:04:13 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALN6RM>; Thu, 20 Jan 2000 11:04:13 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC212@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>, "'Keith Parks'"
<emkxp01@mtcc.demon.co.uk>
Cc: "'hackers@postgreSQL.org'" <hackers@postgreSQL.org>
Subject: AW: [HACKERS] initdb problems on Solaris
Date: Thu, 20 Jan 2000 11:04:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
The postmaster and backend can and should refuse to run with an
effective Unix userid of 0 (root), but that doesn't mean that
a Postgres ID of 0 is insecure, does it?
The usual setup has the Postgres ID same as the unix id, thus
0 would be reserved for root.
I think this setup has the advatage, that we could someday issue
setuid() calls for "dba and untrusted stored procedures", which would
imho be a very handy feature.
Andreas
From bouncefilter Thu Jan 20 06:15:25 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA22222
for <hackers@postgreSQL.org>; Thu, 20 Jan 2000 06:15:06 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Puma.DoCS.UU.SE (e99re41@Puma.DoCS.UU.SE [130.238.9.112])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA12586;
Thu, 20 Jan 2000 12:14:50 +0100 (MET)
Received: from localhost (e99re41@localhost) by Puma.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA15504;
Thu, 20 Jan 2000 12:14:45 +0100
X-Authentication-Warning: Puma.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 20 Jan 2000 12:14:45 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
cc: "'Tom Lane'" <tgl@sss.pgh.pa.us>,
"'Keith Parks'" <emkxp01@mtcc.demon.co.uk>,
"'hackers@postgreSQL.org'" <hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] initdb problems on Solaris
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC212@sdexcsrv1.f000.d0188.sd.spardat.at>
Message-ID: <Pine.GSO.4.02A.10001201213580.15489-100000@Puma.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 20 Jan 2000, Zeugswetter Andreas SB wrote:
The postmaster and backend can and should refuse to run with an
effective Unix userid of 0 (root), but that doesn't mean that
a Postgres ID of 0 is insecure, does it?The usual setup has the Postgres ID same as the unix id, thus
0 would be reserved for root.I think this setup has the advatage, that we could someday issue
setuid() calls for "dba and untrusted stored procedures", which would
imho be a very handy feature.
That would require you to set up a Unix user for every Postgres user,
which is certainly not necassary in the general case.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 06:18:25 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA22656
for <hackers@postgreSQL.org>; Thu, 20 Jan 2000 06:18:21 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Puma.DoCS.UU.SE (e99re41@Puma.DoCS.UU.SE [130.238.9.112])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA12976;
Thu, 20 Jan 2000 12:18:16 +0100 (MET)
Received: from localhost (e99re41@localhost) by Puma.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA15535;
Thu, 20 Jan 2000 12:18:12 +0100
X-Authentication-Warning: Puma.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 20 Jan 2000 12:18:11 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] initdb problems on Solaris
In-Reply-To: <200001192341.XAA11997@mtcc.demon.co.uk>
Message-ID: <Pine.GSO.4.02A.10001201215470.15489-100000@Puma.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 19 Jan 2000, Keith Parks wrote:
Hi All,
I know that the whole "id" thing in initdb is a can of worms.
We have pg_id but we don't want to use it, every system has
a different version/variety of whoami/"who am i"/id.We don't need/want to use the unix ID of the user, but we do
when we can. The whole thing is a mess!!
Can you be more specific in regards to what doesn't work, what needs
fixing, etc.?
One thing we need to do is change the default, "if all else
fails" id from 0 to something else, as 0 is specifically
disallowed and causes an "Abort" in postgres when bootstrapping.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 06:25:25 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA23823
for <hackers@postgreSQL.org>; Thu, 20 Jan 2000 06:24:29 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Puma.DoCS.UU.SE (e99re41@Puma.DoCS.UU.SE [130.238.9.112])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA13349;
Thu, 20 Jan 2000 12:24:23 +0100 (MET)
Received: from localhost (e99re41@localhost) by Puma.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA15547;
Thu, 20 Jan 2000 12:24:19 +0100
X-Authentication-Warning: Puma.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 20 Jan 2000 12:24:19 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] initdb problems on Solaris
In-Reply-To: <200001192355.XAA12300@mtcc.demon.co.uk>
Message-ID: <Pine.GSO.4.02A.10001201218150.15489-100000@Puma.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 19 Jan 2000, Keith Parks wrote:
Just noticed we no longer have trusty "pg_id".....
Wasn't needed any longer. However, with the persisting problems on
Solaris, I am tempted to take the 'id' command from FreeBSD (which seems
to be POSIX compliant) and reinstitute it as new pg_id. That would also
solve the whoami problem (the reverse if what pg_id did).
Any protests? Otherwise I'll get this fixed.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 06:32:25 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA25672
for <hackers@postgreSQL.org>; Thu, 20 Jan 2000 06:31:36 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Puma.DoCS.UU.SE (e99re41@Puma.DoCS.UU.SE [130.238.9.112])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA14067;
Thu, 20 Jan 2000 12:31:31 +0100 (MET)
Received: from localhost (e99re41@localhost) by Puma.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA15551;
Thu, 20 Jan 2000 12:31:27 +0100
X-Authentication-Warning: Puma.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 20 Jan 2000 12:31:26 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Alfred Perlstein <bright@wintelcom.net>
cc: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>, hackers@postgreSQL.org
Subject: Re: [HACKERS] gperf anyone?
In-Reply-To: <20000119131228.C14058@fw.wintelcom.net>
Message-ID: <Pine.GSO.4.02A.10001201231021.15489-100000@Puma.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 19 Jan 2000, Alfred Perlstein wrote:
also... to accomplish the gperf testing I do a strlen on each word,
over and over to simulate the need for it (as gperf needs that)
however if the strlen is already available in the parser at this
time, i'm pretty sure it would be even faster.
Precisely, that was the idea.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 06:34:25 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA28001
for <hackers@postgreSQL.org>; Thu, 20 Jan 2000 06:34:16 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Puma.DoCS.UU.SE (e99re41@Puma.DoCS.UU.SE [130.238.9.112])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id MAA14448;
Thu, 20 Jan 2000 12:34:12 +0100 (MET)
Received: from localhost (e99re41@localhost) by Puma.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA15555;
Thu, 20 Jan 2000 12:34:08 +0100
X-Authentication-Warning: Puma.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 20 Jan 2000 12:34:07 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Alfred Perlstein <bright@wintelcom.net>, hackers@postgreSQL.org
Subject: Re: [HACKERS] gperf anyone?
In-Reply-To: <200001192012.PAA20286@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.10001201227020.15489-100000@Puma.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 19 Jan 2000, Bruce Momjian wrote:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-01-18, Bruce Momjian mentioned:
Can you run our keywords.c using our method and gperf and see if there
is any speed difference?It seems to have a speed advantage of about 2.5. But in practice that
means that 1 million words take half a second. It's not a big deal to me,
I was just wondering before I throw it out. I guess it really only makes a
difference for compilers, which operate on 1000+ lines.The big difference may be that the compiler has variables/types that are
added dynamically while running, while our list is static. Insert time
for our types is zero because we don't add SQL keywords at runtime.
No, compiler don't do this either. This is specifically for keyword
lookup. The whole idea is that you have one set of keywords that hardly
ever changes (such as for programming languages), then you take one
afternoon off, play around with the different options until you have a
lookup function which processes your particular keyword set fastest.
Again, this is not a big deal to me, I just did it to play around. In any
case it seems to run faster, but I wasn't sure if people wanted to bother.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 07:37:26 2000
Received: from tango.SoftHome.net (tango.SoftHome.net [204.144.231.49])
by hub.org (8.9.3/8.9.3) with SMTP id HAA48312
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 07:37:25 -0500 (EST)
(envelope-from j.roeleveld@softhome.net)
Received: (qmail 20387 invoked by uid 417); 20 Jan 2000 12:39:31 -0000
Received: from sentec.demon.nl (HELO joost) (212.238.106.25)
by smtpb.softhome.net with SMTP; 20 Jan 2000 12:39:31 -0000
Message-ID: <001d01bf6342$f915a580$8402a8c0@sentec.demon.nl>
From: "J. Roeleveld" <j.roeleveld@softhome.net>
To: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Subject: Permissions, update acts same as delete, feature or bug?
Date: Thu, 20 Jan 2000 13:36:27 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Hi,
I just found that when giving permissions on tables to different users,
that Update-permission is the same as Delete-permission, is this
intended behaviour, or is it a bug?
hoping for an answer,
Joost Roeleveld
From bouncefilter Thu Jan 20 08:27:26 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA59999
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 08:26:56 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Puma.DoCS.UU.SE (e99re41@Puma.DoCS.UU.SE [130.238.9.112])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id OAA23547
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 14:26:51 +0100 (MET)
Received: from localhost (e99re41@localhost) by Puma.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id OAA15662 for
<pgsql-hackers@postgresql.org>; Thu, 20 Jan 2000 14:26:45 +0100
X-Authentication-Warning: Puma.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 20 Jan 2000 14:26:44 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgresql.org
Subject: A notice for too long names
Message-ID: <Pine.GSO.4.02A.10001201418540.15489-100000@Puma.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Wouldn't it be fair if a notice was generated if you attempt to create
and/or reference a name that's longer than NAMEDATALEN. Like
=> create table some_really_much_too_long_name_here ( ... );
NOTICE: "some_really_much_too_long_name_here" will be truncated to
"some_really_much_too_long_name_" [ <possible reference to documentation
and/or source code to change this> ]
Better than finding out after the fact, ISTM. I could (try to) take care
of this.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 08:40:27 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA65812
for <hackers@postgreSQL.org>; Thu, 20 Jan 2000 08:40:10 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id OAA41454;
Thu, 20 Jan 2000 14:40:02 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCALN810>; Thu, 20 Jan 2000 14:40:02 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC213@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Peter Eisentraut'" <peter_e@gmx.net>
Cc: "'hackers@postgreSQL.org'" <hackers@postgreSQL.org>
Subject: AW: AW: [HACKERS] initdb problems on Solaris
Date: Thu, 20 Jan 2000 14:39:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
I think this setup has the advatage, that we could someday issue
setuid() calls for "dba and untrusted stored procedures",which would
imho be a very handy feature.
That would require you to set up a Unix user for every Postgres user,
which is certainly not necassary in the general case.
Yes, we would somehow need to distinguish between
OS users and DB only users.
Andreas
From bouncefilter Thu Jan 20 10:13:27 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA90900
for <pgsql-general@postgresql.org>;
Thu, 20 Jan 2000 10:12:57 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1) id 12BJGl-0003yh-00
for pgsql-general@postgresql.org; Thu, 20 Jan 2000 15:13:07 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12BJGb-0004I8-00
for pgsql-general@postgresql.org; Thu, 20 Jan 2000 15:12:57 +0000
Date: Thu, 20 Jan 2000 15:12:57 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: pgsql-general@postgresql.org
Subject: Variable case database names
Message-ID: <20000120151257.F12966@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
List of databases
Database | Owner
------------+----------
Newnham | prlw1
% psql Newnham
psql: connection to database "newnham" failed - FATAL 1: Database "newnham" does not exist in the system catalog.
template1=> \c 'Newnham'
FATAL 1: Database "newnham" does not exist in the system catalog.
Previous connection kept
How can I connect to a database with a variable case name?
Cheers,
Patrick
From bouncefilter Thu Jan 20 10:17:27 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA91593
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 10:17:17 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA27105;
Thu, 20 Jan 2000 10:17:04 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001201517.KAA27105@candle.pha.pa.us>
Subject: Re: Postgres improvement
In-Reply-To: <8025686C.003DE079.00@birmingham.gov.uk> from Jonathan Homer at
"Jan 20, 2000 11:17:57 am"
To: Jonathan Homer <Jonathan_Homer@birmingham.gov.uk>
Date: Thu, 20 Jan 2000 10:17:04 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hi There,
I am not sure if you are the right person to contact to suggest an improvement.
But he goes....
Can I suggest an improvement to Psql by adding to '/z' which produces the
security attributes to the tables etc....If it can be possible could it also take a parameter of an object ie table? So
rather then hunting and using the scrolling functions of the telnet session to
view the list it would be nice to do '/z table1' .Keep up the good work.
OK, sent to hackers. Look what I get in the current sources:
test=> \z lkasdf
ERROR: attribute 'rename' not found
This makes no sense to me.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 20 10:22:33 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA92398
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 10:22:09 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max06-013.enterprise.net
[194.72.197.73])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id PAA15249
for <pgsql-hackers@postgreSQL.org>; Thu, 20 Jan 2000 15:22:06 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id PAA04675
for <pgsql-hackers@postgreSQL.org>; Thu, 20 Jan 2000 15:21:25 GMT
Message-Id: <200001201521.PAA04675@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: COPY problems with psql / libpq
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 20 Jan 2000 15:21:24 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
[Using current cvs] I have a problem with COPY when called like this:
psql -e bray </tmp/ol
with one particular file, containing commands and data like this:
========================================
copy address from stdin;
1 Some place, Regal Way Somewhere Oxon AB1 3CF [ Tel: 01367 888888 ] No
Deliveries Pm Fridays GB \N \N \N \N \N \N \N \N \N \N \N \N
...
1000 73 Some Road London SW1 1ZZ GB 44 81 999 9999 \N
\N \N \N \N \N \N \N
\.
-- 1000 records written
select count(*) from address;
copy address from stdin;
1001...
... and so on up to 3916 records in total, divided into 1000 record chunks
========================================
psql or libpq seems to choke on the data, so that some spurious error
arises, such as null input into a non-null field. Thereafter, libpq
seems to get stuck in a COPY state:
copy address from stdin;
-- 1000 records written
select count(*) from address;
PQexec: you gotta get out of a COPY state yourself.
(The comment in PQexec says it does this to preserve backwards
compatibility, but getting stuck in COPY state is not backwards
compatible!)
If I remove the SQL commands from the input file, go into psql and do:
copy address from '/tmp/ol';
all 3916 records are added correctly. This seems to indicate that
the problem is not in the backend.
I found that if I broke the first 1000 records into 2 equal parts, all
of them were added correctly without error; so I conclude that data
is being buffered and lost somewhere in psql or libpq, and the problem is
dependent on the amount of data being copied.
This began to happen within the last week, but I don't know which
recent change is responsible.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Neither is there salvation in any other; for there is
none other name under heaven given among men, whereby
we must be saved." Acts 4:12
From bouncefilter Thu Jan 20 10:21:27 2000
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 KAA92150
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 10:20:32 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA26937;
Thu, 20 Jan 2000 15:28:57 GMT
Sender: lockhart@hub.org
Message-ID: <388729B9.E71B7684@alumni.caltech.edu>
Date: Thu, 20 Jan 2000 15:28:57 +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: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] A notice for too long names
References: <Pine.GSO.4.02A.10001201418540.15489-100000@Puma.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Wouldn't it be fair if a notice was generated if you attempt to create
and/or reference a name that's longer than NAMEDATALEN. Like=> create table some_really_much_too_long_name_here ( ... );
NOTICE: "some_really_much_too_long_name_here" will be truncated to
"some_really_much_too_long_name_" [ <possible reference to documentation
and/or source code to change this> ]
Better than finding out after the fact, ISTM. I could (try to) take care
of this.
Would it be better to throw an elog(ERROR)? The only place I know of
where names are silently truncated is in generating primary and unique
indices, where the names are based on the underlying table name plus
some automatically generated discriminator.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Jan 20 10:30:27 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA94040
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 10:29:35 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA02547;
Thu, 20 Jan 2000 10:29:22 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001201529.KAA02547@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Postgres improvement
In-Reply-To: <200001201517.KAA27105@candle.pha.pa.us> from Bruce Momjian at
"Jan 20, 2000 10:17:04 am"
To: Bruce Momjian <pgman@candle.pha.pa.us>
Date: Thu, 20 Jan 2000 10:29:22 -0500 (EST)
CC: Jonathan Homer <Jonathan_Homer@birmingham.gov.uk>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hi There,
I am not sure if you are the right person to contact to suggest an improvement.
But he goes....
Can I suggest an improvement to Psql by adding to '/z' which produces the
security attributes to the tables etc....If it can be possible could it also take a parameter of an object ie table? So
rather then hunting and using the scrolling functions of the telnet session to
view the list it would be nice to do '/z table1' .Keep up the good work.
OK, sent to hackers. Look what I get in the current sources:
test=> \z lkasdf
ERROR: attribute 'rename' not foundThis makes no sense to me.
OK, fixed and sources updated:
test=> \z test
Access permissions for database "test"
Relation | Access permissions
----------+--------------------
test | {"=arwR"}
(1 row)
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 20 10:48:28 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA01674
for <hackers@postgreSQL.org>; Thu, 20 Jan 2000 10:48:20 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA09958;
Thu, 20 Jan 2000 07:47:48 -0800 (PST)
Message-Id: <3.0.1.32.20000120073838.01034ec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 20 Jan 2000 07:38:38 -0800
To: Peter Eisentraut <peter_e@gmx.net>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] gperf anyone?
Cc: Alfred Perlstein <bright@wintelcom.net>, hackers@postgreSQL.org
In-Reply-To: <Pine.GSO.4.02A.10001201227020.15489-100000@Puma.DoCS.UU.SE
References: <200001192012.PAA20286@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:34 PM 1/20/00 +0100, Peter Eisentraut wrote:
No, compiler don't do this either. This is specifically for keyword
lookup. The whole idea is that you have one set of keywords that hardly
ever changes (such as for programming languages), then you take one
afternoon off, play around with the different options until you have a
lookup function which processes your particular keyword set fastest.
Again, this is not a big deal to me, I just did it to play around. In any
case it seems to run faster, but I wasn't sure if people wanted to bother.
The binary search could very easily be sped up, actually (I just peeked).
If you'd care to e-mail me your two test cases, the one using the
output of gperf and the one using the current binary search, I'd
be more than willing to demonstrate.
I have nothing against speeding things up, though again identifying
keywords takes a vanishingly small part of the time required to
execute a query (or compile a program, for that matter). I more
or less dislike adding dependencies to external tools when it
can be avoided, though.
I just built a new PC to do linux-based development on and it
would be fun to have your benchmark program to compare my
new and old linux boxes anyway :) (P 200 classic vs. P500E, guess
which will win?)
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 20 10:56:31 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA02920
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 10:55:31 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA21098;
Thu, 20 Jan 2000 10:55:05 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] A notice for too long names
In-reply-to: <388729B9.E71B7684@alumni.caltech.edu>
References: <Pine.GSO.4.02A.10001201418540.15489-100000@Puma.DoCS.UU.SE>
<388729B9.E71B7684@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Thu, 20 Jan 2000 15:28:57 +0000"
Date: Thu, 20 Jan 2000 10:55:05 -0500
Message-ID: <21095.948383705@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Wouldn't it be fair if a notice was generated if you attempt to create
and/or reference a name that's longer than NAMEDATALEN.
Would it be better to throw an elog(ERROR)?
Definitely NOT. Rejecting long identifiers went out with Dartmouth Basic.
The only reason to worry at all is if someone uses two identifiers that
are the same for the first NAMEDATALEN characters --- but if so, he'll
get an error about duplicate column or duplicate table name. I see no
real reason to change the current behavior...
regards, tom lane
From bouncefilter Thu Jan 20 10:53:28 2000
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 KAA02328
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 10:52:37 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA27098;
Thu, 20 Jan 2000 16:01:03 GMT
Sender: lockhart@hub.org
Message-ID: <3887313F.8D8DF166@alumni.caltech.edu>
Date: Thu, 20 Jan 2000 16:01: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: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] timezone problem?
References: <20000120124950U.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Why do I get different date/time after explicitly setting timezone?
This is RH Linux 5.2.
Because...
test=> select '1998-09-23 12:05:10 HST'::datetime;
------------------------------
Thu Sep 24 07:05:10 1998 JST
test=> show timezone;
NOTICE: Time zone is unknown
SHOW VARIABLE
test=> set timezone to 'JST';
SET VARIABLE
test=> select '1998-09-23 12:05:10 HST'::datetime;
------------------------------
Wed Sep 23 22:05:10 1998 JST
On my RH-5.2 box, "JST" is not in /usr/share/zoneinfo. A non-existant
TZ evaluates to be GMT, but the system reports the string you gave
it!! I don't recall ever running across this before. But the moral of
the story is: don't do that! ;)
I'm not sure how one would check to verify that the timezone you set
is actually a valid timezone. I'd hate to restrict it to the list of
timezones Postgres knows about when parsing input (since that is a
subset of the possibilities), though that is one solution...
- Thomas
[root@golem zoneinfo]# setenv TZ HST
[root@golem zoneinfo]# date
Thu Jan 20 05:55:02 HST 2000
[root@golem zoneinfo]# setenv TZ JST
[root@golem zoneinfo]# date
Thu Jan 20 15:54:37 JST 2000
[root@golem zoneinfo]# setenv TZ GMT
[root@golem zoneinfo]# date
Thu Jan 20 15:54:45 GMT 2000
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Jan 20 11:03:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA06304
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 11:02:35 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA21148;
Thu, 20 Jan 2000 11:02:31 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] COPY problems with psql / libpq
In-reply-to: <200001201521.PAA04675@linda.lfix.co.uk>
References: <200001201521.PAA04675@linda.lfix.co.uk>
Comments: In-reply-to "Oliver Elphick" <olly@lfix.co.uk>
message dated "Thu, 20 Jan 2000 15:21:24 +0000"
Date: Thu, 20 Jan 2000 11:02:31 -0500
Message-ID: <21145.948384151@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Oliver Elphick" <olly@lfix.co.uk> writes:
I found that if I broke the first 1000 records into 2 equal parts, all
of them were added correctly without error; so I conclude that data
is being buffered and lost somewhere in psql or libpq, and the problem is
dependent on the amount of data being copied.
I have the following note in my (much too long) to-do list:
: psql.c doesn't appear to cope correctly with quoted newlines in COPY data;
: if one falls just after a buffer boundary, trouble!
: Does fe-exec.c work either??
(This note is some months old, and may or may not still apply since
Peter's rework of psql.) It could be that your dataset is hitting this
problem or a similar one. A buffer-boundary problem would explain why
the error seems to be so dataset-specific.
copy address from stdin;
-- 1000 records written
select count(*) from address;
PQexec: you gotta get out of a COPY state yourself.
It sure sounds like psql is failing to recognize the trailing \.
of the COPY data.
regards, tom lane
From bouncefilter Thu Jan 20 11:23:30 2000
Received: from [12.6.225.3] ([12.6.225.3])
by hub.org (8.9.3/8.9.3) with SMTP id LAA11301
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 11:22:49 -0500 (EST)
(envelope-from rdavis@lillysoftware.com)
Received: from lillysoftware.com by [12.6.225.3]
via smtpd (for postgresql.org [216.126.84.28]) with SMTP;
20 Jan 2000 16:21:21 UT
Received: from lillysoftware.com (BOBIBM333 [173.100.2.237]) by
ponyexpress.LillySoftware.com with SMTP (Microsoft Exchange
Internet Mail Service Version 5.5.2448.0)
id D1RCYFL7; Thu, 20 Jan 2000 11:20:25 -0500
Message-ID: <38873652.41ADBCC3@lillysoftware.com>
Date: Thu, 20 Jan 2000 11:22:43 -0500
From: Robert Davis <rdavis@lillysoftware.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: off topic
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I know this is off topic but...
How do the programmers here get paid?
1. You do this in your spare time and dont get paid.
2. Your day job encourages you to spend some of your time developing the db that your company uses.
3. There is an organization that accepts money and distributes it to the hackers.
4. You are all independently wealthy and do this for the fun of it.
5. You are still living at home with mom and expect one day to get a real job from this.
Seriously
My friend and I were talking about the open software movement and how great it is and he keeps on asking how people like us get paid.
Basically my friend and me are the type that like to stay home and not visit customers and just solve problems and write code. Probably a lot like all of you.
thanks
bob
--
rdavis@lillysoftware.com
rsdavis@mediaone.net
http://people.ne.mediaone.net/rsdavis
From bouncefilter Thu Jan 20 11:30:28 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA12521
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 11:29:52 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA21251;
Thu, 20 Jan 2000 11:29:23 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] timezone problem?
In-reply-to: <3887313F.8D8DF166@alumni.caltech.edu>
References: <20000120124950U.t-ishii@sra.co.jp>
<3887313F.8D8DF166@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Thu, 20 Jan 2000 16:01:03 +0000"
Date: Thu, 20 Jan 2000 11:29:23 -0500
Message-ID: <21248.948385763@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
On my RH-5.2 box, "JST" is not in /usr/share/zoneinfo. A non-existant
TZ evaluates to be GMT, but the system reports the string you gave
it!! I don't recall ever running across this before.
Ugh. RedHat's not the only one: on my HPUX 10 box,
$ date
Thu Jan 20 11:13:26 EST 2000
$ TZ=GMT date
Thu Jan 20 16:13:30 GMT 2000
$ TZ=ZZZ date
Thu Jan 20 16:13:35 ZZZ 2000
$ TZ=foo date
Thu Jan 20 16:13:53 foo 2000
This may be a fairly widespread bug^H^H^Hbizarre behavior.
I'm not sure how one would check to verify that the timezone you set
is actually a valid timezone. I'd hate to restrict it to the list of
timezones Postgres knows about when parsing input (since that is a
subset of the possibilities), though that is one solution...
Well, we could solve a smaller problem: keep a list of the timezone
names we think are equivalent to GMT. Then, if we see a zero TZ offset
for any name not in the list, emit some sort of warning notice. Bit of
a kluge though.
I am not sure that this relates to Tatsuo's complaint, though.
His issue was:
test=> select '1998-09-23 12:05:10 HST'::datetime;
------------------------------
Thu Sep 24 07:05:10 1998 JST
test=> show timezone;
NOTICE: Time zone is unknown
If Postgres doesn't know the timezone, why is it displaying "JST" in
decoded datetimes?
Another odd thing is that I'd have expected the displayed time to be
GMT if the system doesn't know the timezone --- but the time being
shown here is 9 hours ahead of JST, not 9 hours behind... perhaps
something somewhere *does* know the local zone, but is applying the
correction backwards?
regards, tom lane
From bouncefilter Thu Jan 20 11:40:28 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA18287
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 11:40:27 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12BKdQ-00042J-00; Thu, 20 Jan 2000 16:40:36 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12BKdF-0004MU-00; Thu, 20 Jan 2000 16:40:25 +0000
Date: Thu, 20 Jan 2000 16:40:25 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] COPY problems with psql / libpq
Message-ID: <20000120164025.K12966@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <200001201521.PAA04675@linda.lfix.co.uk>
<21145.948384151@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <21145.948384151@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Thu, Jan 20, 2000 at 11:02:31AM -0500
On Thu, Jan 20, 2000 at 11:02:31AM -0500, Tom Lane wrote:
It sure sounds like psql is failing to recognize the trailing \.
of the COPY data.
Precisely what I saw yesterday (cf Subject: pg_dump disaster) - but what
does one do about it?
Cheers,
Patrick
From bouncefilter Thu Jan 20 11:52:29 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id LAA20722
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 11:51:28 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 9131 invoked by uid 1001); 20 Jan 2000 16:51:29 -0000
Date: Thu, 20 Jan 2000 11:51:29 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] timezone problem?
In-Reply-To: <21248.948385763@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.05.10001201148230.8515-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 20 Jan 2000, Tom Lane wrote:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
On my RH-5.2 box, "JST" is not in /usr/share/zoneinfo. A non-existant
TZ evaluates to be GMT, but the system reports the string you gave
it!! I don't recall ever running across this before.Ugh. RedHat's not the only one: on my HPUX 10 box,
$ date
Thu Jan 20 11:13:26 EST 2000
$ TZ=GMT date
Thu Jan 20 16:13:30 GMT 2000
$ TZ=ZZZ date
Thu Jan 20 16:13:35 ZZZ 2000
$ TZ=foo date
Thu Jan 20 16:13:53 foo 2000This may be a fairly widespread bug^H^H^Hbizarre behavior.
Odd. Here's how FreeBSD acts:
$ TZ=GMT date
Thu Jan 20 16:47:29 GMT 2000
$ TZ=foo date
Thu Jan 20 16:47:36 GMT 2000
$ TZ=EDT date
Thu Jan 20 16:47:47 GMT 2000
$ TZ=EST date
Thu Jan 20 11:47:54 EST 2000
$ TZ=PST date
Thu Jan 20 16:48:03 GMT 2000
$ TZ=ZZZ date
Thu Jan 20 16:48:09 GMT 2000
$ TZ=JST date
Thu Jan 20 16:49:00 GMT 2000
$ TZ=MST date
Thu Jan 20 09:50:05 MST 2000
$ TZ=CST date
Thu Jan 20 16:49:32 GMT 2000
Strange, it does MST and EST but not CST and PST.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Thu Jan 20 11:48:29 2000
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 LAA19939
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 11:48:05 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA27193;
Thu, 20 Jan 2000 16:52:47 GMT
Sender: lockhart@hub.org
Message-ID: <38873D5F.1E7F83A5@alumni.caltech.edu>
Date: Thu, 20 Jan 2000 16:52: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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] timezone problem?
References: <20000120124950U.t-ishii@sra.co.jp>
<3887313F.8D8DF166@alumni.caltech.edu>
<21248.948385763@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Well, we could solve a smaller problem: keep a list of the timezone
names we think are equivalent to GMT. Then, if we see a zero TZ offset
for any name not in the list, emit some sort of warning notice. Bit of
a kluge though.
Uh, yes it is :)
I am not sure that this relates to Tatsuo's complaint, though.
His issue was:test=> select '1998-09-23 12:05:10 HST'::datetime;
------------------------------
Thu Sep 24 07:05:10 1998 JST
test=> show timezone;
NOTICE: Time zone is unknownIf Postgres doesn't know the timezone, why is it displaying "JST" in
decoded datetimes?
"Time zone is unknown" is the usual state if there is not an explicit
SET TIME ZONE by a client. Doesn't mean anything more, and doesn't
imply that the backend can't do timezone stuff. Postgres relies on
system-supplied routines if the year is between 1903 and 2038 (mas o
menos; I didn't look it up).
Another odd thing is that I'd have expected the displayed time to be
GMT if the system doesn't know the timezone --- but the time being
shown here is 9 hours ahead of JST, not 9 hours behind... perhaps
something somewhere *does* know the local zone, but is applying the
correction backwards?
HST is interpreted by Postgres as Hawaii Standard Time, which is on
the other side of the date line from Japan. Planning a vacation
Tatsuo?? :))
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Jan 20 11:49:28 2000
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 LAA20147
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 11:49:05 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA27210;
Thu, 20 Jan 2000 16:57:32 GMT
Sender: lockhart@hub.org
Message-ID: <38873E7C.D0DC20D9@alumni.caltech.edu>
Date: Thu, 20 Jan 2000 16:57:32 +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: Robert Davis <rdavis@lillysoftware.com>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] off topic
References: <38873652.41ADBCC3@lillysoftware.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
How do the programmers here get paid?
1. You do this in your spare time and dont get paid.
Bingo!
2. Your day job encourages you to spend some of your time
developing the db that your company uses.
I know a few developers are in this category.
4. You are all independently wealthy and do this for the fun of it.
I could see this as something to do in retirement; a bunch of cranky
70 year olds debating the next development for Postgres isn't a pretty
thought however...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Jan 20 12:31:31 2000
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 MAA36107
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 12:31:21 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA06736;
Thu, 20 Jan 2000 12:21:07 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001201721.MAA06736@candle.pha.pa.us>
Subject: Re: [HACKERS] off topic
In-Reply-To: <38873E7C.D0DC20D9@alumni.caltech.edu> from Thomas Lockhart at
"Jan 20, 2000 04:57:32 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 20 Jan 2000 12:21:07 -0500 (EST)
CC: Robert Davis <rdavis@lillysoftware.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
How do the programmers here get paid?
1. You do this in your spare time and dont get paid.Bingo!
I will give him a double-bingo!
2. Your day job encourages you to spend some of your time
developing the db that your company uses.I know a few developers are in this category.
4. You are all independently wealthy and do this for the fun of it.
I could see this as something to do in retirement; a bunch of cranky
70 year olds debating the next development for Postgres isn't a pretty
thought however...
We are cranky enough. "You want to add feature X. We don't think that
is a good idea." :-)
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 20 12:00:29 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA22214
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 12:00:07 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id JAA04488;
Thu, 20 Jan 2000 09:22:16 -0800 (PST)
Date: Thu, 20 Jan 2000 09:22:16 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: prlw1@cam.ac.uk
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] COPY problems with psql / libpq
Message-ID: <20000120092216.J20751@fw.wintelcom.net>
References: <200001201521.PAA04675@linda.lfix.co.uk>
<21145.948384151@sss.pgh.pa.us>
<20000120164025.K12966@quartz.newn.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000120164025.K12966@quartz.newn.cam.ac.uk>;
from prlw1@newn.cam.ac.uk on Thu, Jan 20, 2000 at 04:40:25PM +0000
* Patrick Welche <prlw1@newn.cam.ac.uk> [000120 09:10] wrote:
On Thu, Jan 20, 2000 at 11:02:31AM -0500, Tom Lane wrote:
It sure sounds like psql is failing to recognize the trailing \.
of the COPY data.Precisely what I saw yesterday (cf Subject: pg_dump disaster) - but what
does one do about it?
Is this with a recent snapshot or 6.5.3 using libpq?
Either way, you should check the contents of the send buffer, please let
me know if there is data queued in it. You can include the 'internal'
header for libpq (libpq-int.h?) to get at the send buffer.
-Alfred
From bouncefilter Thu Jan 20 21:42:35 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA41210
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 21:42:00 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id RAA27297;
Thu, 20 Jan 2000 17:24:40 GMT
Sender: lockhart@hub.org
Message-ID: <388744D8.C2CC963D@alumni.caltech.edu>
Date: Thu, 20 Jan 2000 17:24:40 +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: Vince Vielhaber <vev@michvhf.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Tatsuo Ishii <t-ishii@sra.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] timezone problem?
References: <Pine.BSF.4.05.10001201148230.8515-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Odd. Here's how FreeBSD acts:
Strange, it does MST and EST but not CST and PST.
Try PST8PDT for the Pacific TZ and CST6CDT for Central time. Not sure
why the zinc databases have entries for EST and MST as well as for
EST5EDT and MST7MDT (at least on my RH-5.2 linux box).
I like the behavior that it prints GMT when given an invalid time
zone; that is actually the behavior I recall when testing this a year
or two ago. Something changed/improved/broke in the meantime with some
of these boxes...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Jan 20 12:28:30 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA34656
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 12:28:22 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12BLMU-00043u-00; Thu, 20 Jan 2000 17:27:10 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12BLMJ-0004NL-00; Thu, 20 Jan 2000 17:26:59 +0000
Date: Thu, 20 Jan 2000 17:26:59 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Oliver.Elphick@lfix.co.uk, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] COPY problems with psql / libpq
Message-ID: <20000120172659.L12966@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <200001201521.PAA04675@linda.lfix.co.uk>
<21145.948384151@sss.pgh.pa.us>
<20000120164025.K12966@quartz.newn.cam.ac.uk>
<20000120092216.J20751@fw.wintelcom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <20000120092216.J20751@fw.wintelcom.net>;
from bright@wintelcom.net on Thu, Jan 20, 2000 at 09:22:16AM -0800
On Thu, Jan 20, 2000 at 09:22:16AM -0800, Alfred Perlstein wrote:
* Patrick Welche <prlw1@newn.cam.ac.uk> [000120 09:10] wrote:
On Thu, Jan 20, 2000 at 11:02:31AM -0500, Tom Lane wrote:
It sure sounds like psql is failing to recognize the trailing \.
of the COPY data.Precisely what I saw yesterday (cf Subject: pg_dump disaster) - but what
does one do about it?Is this with a recent snapshot or 6.5.3 using libpq?
For me, it's using yesterday's cvs'd source - but I obviously can't speak
for Oliver.
Either way, you should check the contents of the send buffer, please let
me know if there is data queued in it. You can include the 'internal'
header for libpq (libpq-int.h?) to get at the send buffer.
That will take a while. In the meantime, just pg_dumpall something and try
to read the output back in. I do have ^M's in some of the text columns if
that matters.
Cheers,
Patrick
From bouncefilter Thu Jan 20 12:48:30 2000
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 MAA41562
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 12:48:26 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62865 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S135175AbQATRrr>;
Thu, 20 Jan 2000 18:47:47 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12BLnU-0001hh-00; Thu, 20 Jan 2000 18:55:04 +0100
Date: Thu, 20 Jan 2000 18:55:04 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>,
Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Status on 7.0
In-Reply-To: <200001190341.WAA15358@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0001192156200.5544-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-18, Bruce Momjian mentioned:
Can I ask how our big open items for 7.0 are doing:
Long tuples/TOAST(Jan)
Foriegn keys/action buffer(Jan)
Unify date/time types(Thomas)
Outer Joins(Thomas)I am only asking to know if we should continue with the planned Feb 1
beta?
Are we going to yank DISTINCT ON?
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 12:48:31 2000
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 MAA41565
for <hackers@postgresql.org>; Thu, 20 Jan 2000 12:48:27 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63094 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S86043AbQATRr5>;
Thu, 20 Jan 2000 18:47:57 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12BLni-0001iT-00; Thu, 20 Jan 2000 18:55:18 +0100
Date: Thu, 20 Jan 2000 18:55:18 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: Date/time type
In-Reply-To: <38852FE3.1698BDA9@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0001201535470.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-19, Thomas Lockhart mentioned:
Hmm. I *think* I state a clear preference in the User's Guide. Is
Yeah, they say datetime is the "best general date and time" type.
there another place to mention this? Should we be more explicit?? If
we're going to fix it up, we need some suggestions ;)
The users still look at 8 different types and which gets mapped to what in
"some future release". I was thinking along the lines of
DATE/TIME TYPES
We have these (SQL compat.) types: timestamp, date, time, interval
[ these four types have clearly distinct functionality, so there is no
need for "preferences" ]
<body of description here>
Appendix/Note:
To ensure compatibility to earlier versions of PostgreSQL we also continue
to provide datetime (equivalent to timestamp), timespan (equivalent to
interval). The types abstime and reltime are lower precision types which
are used internally. You are discouraged from using any of these types in
new applications and move your old ones over where appropriate. Any or all
of these type might disappear in a future release. [ 7.1 or 7.2 I guess ]
If you want me to help writing something like this up, tell me.
I'd also envision a similar change to the documentation of the numerical
types. The way it currently looks is "Okay, this is what those standard
guys say and this is what _we_ say. You can use the standard stuff but our
stuff gets is implemented natively, so it's your pick."
This is by no means to bash the documentation writers, I just like the
idea of supporting standard SQL over Postgres'isms where both are
equivalent. See also CAST vs ::, etc.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 12:49:29 2000
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 MAA41688
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 12:48:46 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63363 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S108573AbQATRsL>;
Thu, 20 Jan 2000 18:48:11 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12BLns-0001iu-00; Thu, 20 Jan 2000 18:55:28 +0100
Date: Thu, 20 Jan 2000 18:55:28 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Status on 7.0
In-Reply-To: <3885DADB.F529766C@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0001201506290.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-19, Thomas Lockhart mentioned:
istm that pg_dump could benefit greatly if it translated internal
Postgres type names to the SQL92-standard names. For example, int4 ->
integer, int8 -> bigint, etc. This would be analogous to the
translation we do when parsing queries in the backend, converting
(e.g.) integer -> int4.
I certainly think this is a good idea, but I don't consider the proposed
approach too good. The reason is that the next thing you'd have to do is
fix up psql as well, creating one more source of inconsistency. Not to
mention other similar applications which we don't have any control over,
such as pgbash.
What I'd suggest -- and the 7.0 release is certainly one of the better
times to do this -- is to change the catalog entries to "integer",
"bigint", etc. and instead do the translation of the "deprecated" (or
"traditional", if you like) types "int4", "int8", etc. into the standard
ones. As far as I can see this would require only two changes for each
datatype (gram.y:xlateSqlType(), and pg_type.h), so this could be done
transparently to the rest of the code. And client applications don't need
to know this at all.
Is there a problem with this I'm not seeing (other than perhaps affective
attachment to Postgres'isms)? This almost seems too trivial to not have
been done already.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 13:07:30 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id NAA49796
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 13:07:10 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 7269 invoked from network); 20 Jan 2000 18:07:04 -0000
Received: from h-62.96.159.27.host.de.colt.net (root@62.96.159.27)
by pille.addcom.de with SMTP; 20 Jan 2000 18:07:04 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id TAA00879
for pgsql-hackers@postgresql.org; Thu, 20 Jan 2000 19:00:14 +0100
Date: Thu, 20 Jan 2000 19:00:14 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] off topic
Message-ID: <20000120190014.A868@fam-meskes.de>
Mail-Followup-To: PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <38873E7C.D0DC20D9@alumni.caltech.edu>
<200001201721.MAA06736@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <200001201721.MAA06736@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Thu, Jan 20, 2000 at 12:21:07PM
-0500
On Thu, Jan 20, 2000 at 12:21:07PM -0500, Bruce Momjian wrote:
How do the programmers here get paid?
1. You do this in your spare time and dont get paid.Bingo!
I will give him a double-bingo!
Make this a triple.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Thu Jan 20 13:07:29 2000
Received: from marvin.muc.de (marvin.muc.de [193.149.48.2])
by hub.org (8.9.3/8.9.3) with SMTP id NAA49811
for <hackers@postgresql.org>; Thu, 20 Jan 2000 13:07:19 -0500 (EST)
(envelope-from
moderators-muc-lists-postgres-hackers-owner@moderators.muc.de)
Received: (qmail 3589 invoked by alias); 20 Jan 2000 18:06:47 -0000
Delivered-To: moderators-muc-lists-postgres-hackers@moderators.muc.de
Received: (qmail 3584 invoked from network); 20 Jan 2000 18:06:46 -0000
Received: from mailout06.sul.t-online.de (194.25.134.19)
by marvin.muc.de with SMTP; 20 Jan 2000 18:06:46 -0000
Received: from imh00.btx.dtag.de by mailout06.sul.t-online.de with smtp
id 12BLzJ-0001xd-00; Thu, 20 Jan 2000 19:07:17 +0100
Received: from news03.btx.dtag.de by imh00.btx.dtag.de
with esmtp id 12BLzJ-0008Lg-00; Thu, 20 Jan 2000 19:07:17 +0100
Received: from news by news03.btx.dtag.de
with local id 12BLzI-0003zF-00; Thu, 20 Jan 2000 19:07:16 +0100
To: muc-lists-postgres-hackers@moderators.muc.de
Path: news.btx.dtag.de!not-for-mail
From: "Hopf" <markus.hopf@t-online.de>
Newsgroups: muc.lists.postgres.hackers
Subject: Code von WINZIP
Date: Thu, 20 Jan 2000 19:03:58 +0100
Organization: Hopf
Lines: 3
Message-ID: <867isk$ev0$2@news03.btx.dtag.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news03.btx.dtag.de 948391636 15328 081531034-0001 000120 18:07:16
X-Complaints-To: abuse@t-online.de
X-Sender: 081531034-0001@t-dialin.net
X-Newsreader: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Wer Hast den Key von WinZip?
From bouncefilter Thu Jan 20 13:32:35 2000
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 NAA56270
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 13:31:39 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA09507;
Thu, 20 Jan 2000 13:11:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001201811.NAA09507@candle.pha.pa.us>
Subject: Re: [HACKERS] Status on 7.0
In-Reply-To: <Pine.LNX.4.21.0001192156200.5544-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 20, 2000 06:55:04 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 20 Jan 2000 13:11:17 -0500 (EST)
CC: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>,
Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-01-18, Bruce Momjian mentioned:
Can I ask how our big open items for 7.0 are doing:
Long tuples/TOAST(Jan)
Foriegn keys/action buffer(Jan)
Unify date/time types(Thomas)
Outer Joins(Thomas)I am only asking to know if we should continue with the planned Feb 1
beta?Are we going to yank DISTINCT ON?
I don't show DISTINCT ON as being worked on by anyone.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 20 13:32:37 2000
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 NAA56910
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 13:32:16 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA09592;
Thu, 20 Jan 2000 13:12:55 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001201812.NAA09592@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Status on 7.0
In-Reply-To: <Pine.LNX.4.21.0001201506290.349-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 20, 2000 06:55:28 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 20 Jan 2000 13:12:55 -0500 (EST)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-01-19, Thomas Lockhart mentioned:
istm that pg_dump could benefit greatly if it translated internal
Postgres type names to the SQL92-standard names. For example, int4 ->
integer, int8 -> bigint, etc. This would be analogous to the
translation we do when parsing queries in the backend, converting
(e.g.) integer -> int4.I certainly think this is a good idea, but I don't consider the proposed
approach too good. The reason is that the next thing you'd have to do is
fix up psql as well, creating one more source of inconsistency. Not to
mention other similar applications which we don't have any control over,
such as pgbash.What I'd suggest -- and the 7.0 release is certainly one of the better
times to do this -- is to change the catalog entries to "integer",
"bigint", etc. and instead do the translation of the "deprecated" (or
"traditional", if you like) types "int4", "int8", etc. into the standard
ones. As far as I can see this would require only two changes for each
datatype (gram.y:xlateSqlType(), and pg_type.h), so this could be done
transparently to the rest of the code. And client applications don't need
to know this at all.Is there a problem with this I'm not seeing (other than perhaps affective
attachment to Postgres'isms)? This almost seems too trivial to not have
been done already.
[The big incomatibility alarm goes off.]
We have to discuss if this is a good idea. I am not sure.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 20 13:15:29 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA51196
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 13:14:43 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id OAA46106;
Thu, 20 Jan 2000 14:14:10 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 20 Jan 2000 14:14:09 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Robert Davis <rdavis@lillysoftware.com>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] off topic
In-Reply-To: <38873652.41ADBCC3@lillysoftware.com>
Message-ID: <Pine.BSF.4.21.0001201412230.23487-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 20 Jan 2000, Robert Davis wrote:
I know this is off topic but...
How do the programmers here get paid?
1. You do this in your spare time and dont get paid.
2. Your day job encourages you to spend some of your time developing the db that your company uses.
3. There is an organization that accepts money and distributes it to the hackers.
this one does exist (http://www.pgsql.com) ... part of all the revenues
that are made by "PostgreSQL, Inc" is allocated to be fed back into the
project... the kitty isn't very big ye, but it is there, and its
growing...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Jan 20 13:46:30 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA65174
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 13:45:52 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max01-041.enterprise.net
[194.72.195.41])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id SAA16392
for <pgsql-hackers@postgreSQL.org>; Thu, 20 Jan 2000 18:45:50 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id SAA10272
for <pgsql-hackers@postgreSQL.org>; Thu, 20 Jan 2000 18:44:51 GMT
Message-Id: <200001201844.SAA10272@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] COPY problems with psql / libpq
In-reply-to: Message from Patrick Welche <prlw1@newn.cam.ac.uk> of Thu,
20 Jan 2000 17:26:59 GMT. <20000120172659.L12966@quartz.newn.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 20 Jan 2000 18:44:51 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Patrick Welche wrote:
On Thu, Jan 20, 2000 at 09:22:16AM -0800, Alfred Perlstein wrote:
* Patrick Welche <prlw1@newn.cam.ac.uk> [000120 09:10] wrote:
On Thu, Jan 20, 2000 at 11:02:31AM -0500, Tom Lane wrote:
It sure sounds like psql is failing to recognize the trailing \.
of the COPY data.Precisely what I saw yesterday (cf Subject: pg_dump disaster) - but what
does one do about it?Is this with a recent snapshot or 6.5.3 using libpq?
For me, it's using yesterday's cvs'd source - but I obviously can't speak
for Oliver.
This morning's.
Either way, you should check the contents of the send buffer, please let
me know if there is data queued in it. You can include the 'internal'
header for libpq (libpq-int.h?) to get at the send buffer.That will take a while. In the meantime, just pg_dumpall something and try
to read the output back in. I do have ^M's in some of the text columns if
that matters.
I can't do that, because pg_dump seems to be broken if there are tables
with foreign key constraints. (See a separate message.)
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Neither is there salvation in any other; for there is
none other name under heaven given among men, whereby
we must be saved." Acts 4:12
From bouncefilter Thu Jan 20 13:46:30 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA65182
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 13:45:55 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max01-041.enterprise.net
[194.72.195.41])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id SAA16416
for <pgsql-hackers@postgreSQL.org>; Thu, 20 Jan 2000 18:45:52 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id SAA10286
for <pgsql-hackers@postgreSQL.org>; Thu, 20 Jan 2000 18:44:53 GMT
Message-Id: <200001201844.SAA10286@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: pg_dump and foreign keys
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 20 Jan 2000 18:44:53 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
I don't seem to be ableto use pg_dump where a table uses foreign key
constraints. I seem to remember there being a message about pg_dump
problems but I can't remember whether it was relevant to this.
$ pg_dump bray
getTables(): relation 'area': cannot find function with oid 1655 for trigger
RI_ConstraintTrigger_20235
[area is a table with RI constaints]
This seems to be because pg_dump.c getFuncs() excludes system functions
and thus causes getTables() to fail when it finds the RI triggers.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Neither is there salvation in any other; for there is
none other name under heaven given among men, whereby
we must be saved." Acts 4:12
From bouncefilter Thu Jan 20 13:56:30 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA68285
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 13:55:50 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max04-068.enterprise.net
[194.72.196.188])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id SAA19452;
Thu, 20 Jan 2000 18:55:47 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id SAA10596;
Thu, 20 Jan 2000 18:55:40 GMT
Message-Id: <200001201855.SAA10596@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] COPY problems with psql / libpq
In-Reply-To: Message from Tom Lane <tgl@sss.pgh.pa.us>
of "Thu, 20 Jan 2000 11:02:31 EST." <21145.948384151@sss.pgh.pa.us>
References: <200001201521.PAA04675@linda.lfix.co.uk>
<21145.948384151@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 20 Jan 2000 18:55:40 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Tom Lane wrote:
"Oliver Elphick" <olly@lfix.co.uk> writes:
I found that if I broke the first 1000 records into 2 equal parts, all
of them were added correctly without error; so I conclude that data
is being buffered and lost somewhere in psql or libpq, and the problem is
dependent on the amount of data being copied.I have the following note in my (much too long) to-do list:
: psql.c doesn't appear to cope correctly with quoted newlines in COPY data;
: if one falls just after a buffer boundary, trouble!
: Does fe-exec.c work either??
New-lines are not the problem in this particular case, since the data
does not contain any.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Neither is there salvation in any other; for there is
none other name under heaven given among men, whereby
we must be saved." Acts 4:12
From bouncefilter Thu Jan 20 14:01:31 2000
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 OAA69999;
Thu, 20 Jan 2000 14:00:42 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA10879;
Thu, 20 Jan 2000 13:56:49 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001201856.NAA10879@candle.pha.pa.us>
Subject: Re: [HACKERS] off topic
In-Reply-To: <20000120190014.A868@fam-meskes.de> from Michael Meskes at "Jan
20, 2000 07:00:14 pm"
To: Michael Meskes <meskes@postgreSQL.org>
Date: Thu, 20 Jan 2000 13:56:49 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Thu, Jan 20, 2000 at 12:21:07PM -0500, Bruce Momjian wrote:
How do the programmers here get paid?
1. You do this in your spare time and dont get paid.Bingo!
I will give him a double-bingo!
Make this a triple.
I think we are all insane, or very sane. Not sure which.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 20 15:28:31 2000
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA02901
for <hackers@postgresql.org>; Thu, 20 Jan 2000 15:28:01 -0500 (EST)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m12BOBU-000LELC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for hackers@postgresql.org; Thu, 20 Jan 2000 14:28:00 -0600 (CST)
Date: Thu, 20 Jan 2000 14:28:00 -0600
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: hackers@postgresql.org
Subject: Re: [HACKERS] initdb problems on Solaris
Message-ID: <20000120142800.C32049@rice.edu>
References: <200001192341.XAA11997@mtcc.demon.co.uk>
<Pine.GSO.4.02A.10001201215470.15489-100000@Puma.DoCS.UU.SE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <Pine.GSO.4.02A.10001201215470.15489-100000@Puma.DoCS.UU.SE>;
from e99re41@DoCS.UU.SE on Thu, Jan 20, 2000 at 12:18:11PM +0100
Peter -
If you're going to look at the id for initdb, please consider the
NT port as well. This may be more of a problem with cygwin than pgsql,
but pg_id didn't work correctly, and I had to hack on the initdb script
to get it to to run, with a 6.5.3 install, recently.
Ross
On Thu, Jan 20, 2000 at 12:18:11PM +0100, Peter Eisentraut wrote:
On Wed, 19 Jan 2000, Keith Parks wrote:
Hi All,
I know that the whole "id" thing in initdb is a can of worms.
We have pg_id but we don't want to use it, every system has
a different version/variety of whoami/"who am i"/id.We don't need/want to use the unix ID of the user, but we do
when we can. The whole thing is a mess!!Can you be more specific in regards to what doesn't work, what needs
fixing, etc.?
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
From bouncefilter Thu Jan 20 16:53:32 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA39685;
Thu, 20 Jan 2000 16:53:29 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id QAA37573;
Thu, 20 Jan 2000 16:29:36 -0500 (EST) (envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: clyde jones <pylqrp@trbpvgvrf.pbz.tht.net>
X-Newsgroups: comp.databases.postgresql.questions,
comp.databases.postgresql.docs, comp.databases.postgresql.hackers
Subject: how to for postgres as website backend
Organization: Luna Consulting
User-Agent: MT-NewsWatcher/3.0 (PPC)
Message-ID: <pylqrp-7F0F31.16293620012000@news>
Lines: 15
Date: Thu, 20 Jan 2000 21:29:31 GMT
X-Trace: typhoon1.gnilink.net 948403771 151.196.11.187 (Thu,
20 Jan 2000 16:29:31 EST)
To:
pgsql-hackers@postgresql.org.pgsql-docs@postgresql.org.pgsql-questions@postgresql.org
Can anyone recommend a good web-based frontend for a postgres database?
I want to port some databases to postgres, and I would love to make all
my forms html. I am primarily looking for a html UI for the database,
and a creation/management tool second.
thanks
--
Pray to God, But Hammer Away
- Spanish Proverb
Clyde Jones
jjj.trbpvgvrf.pbz/pylqr-wbarf
pylqrp@trbpvgvrf.pbz
From bouncefilter Thu Jan 20 16:48:32 2000
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 QAA38398
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 16:47:56 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63818 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S270369AbQATVrV>;
Thu, 20 Jan 2000 22:47:21 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12BPXO-00031w-00; Thu, 20 Jan 2000 22:54:42 +0100
Date: Thu, 20 Jan 2000 22:54:42 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] A notice for too long names
In-Reply-To: <21095.948383705@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001201907190.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-20, Tom Lane mentioned:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Wouldn't it be fair if a notice was generated if you attempt to create
and/or reference a name that's longer than NAMEDATALEN.Would it be better to throw an elog(ERROR)?
Definitely NOT. Rejecting long identifiers went out with Dartmouth Basic.
But it came back with compilers issuing warnings (hence notice) about
them. Silently truncating input went out with GNU, so I guess it's more of
a current trend ... :)
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 16:48:40 2000
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 QAA38414
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 16:48:04 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64186 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S264225AbQATVrg>;
Thu, 20 Jan 2000 22:47:36 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12BPXc-00031y-00; Thu, 20 Jan 2000 22:54:56 +0100
Date: Thu, 20 Jan 2000 22:54:56 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] COPY problems with psql / libpq
In-Reply-To: <21145.948384151@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001201916180.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-20, Tom Lane mentioned:
"Oliver Elphick" <olly@lfix.co.uk> writes:
I found that if I broke the first 1000 records into 2 equal parts, all
of them were added correctly without error; so I conclude that data
is being buffered and lost somewhere in psql or libpq, and the problem is
dependent on the amount of data being copied.
The buffering is line-based though and the default buffer is 8192. If
your line is longer than that you're in all sorts of other troubles.
I have the following note in my (much too long) to-do list:
: psql.c doesn't appear to cope correctly with quoted newlines in COPY data;
What's a quoted newline?
a) "<newline>"
b) "\n"
c) \<newline>
Earlier you also mentioned to me something in general about control
characters messing up COPY. Could you give me some details on that so I
can look into it?
: if one falls just after a buffer boundary, trouble!
: Does fe-exec.c work either??(This note is some months old, and may or may not still apply since
Peter's rework of psql.) It could be that your dataset is hitting this
I haven't touched that code.
problem or a similar one. A buffer-boundary problem would explain why
the error seems to be so dataset-specific.
At first I thunk a PQExpBuffer based solution would be the answer, but
as I said above, if you overflow the buffer, you're in trouble anyway.
copy address from stdin;
-- 1000 records written
select count(*) from address;
PQexec: you gotta get out of a COPY state yourself.It sure sounds like psql is failing to recognize the trailing \.
of the COPY data.
The last call in the function psql/copy.c:handleCopyIn is
return !PQendcopy(conn);
and there is no way it can exit earlier. Also the connection seems to be
good, since that's checked right after it returns. The calls to PQputvalue
are not checked for return values, so problems might get missed there, but
that would in any case still point to a problem elsewhere. Gotta pass the
buck to libpq ...
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 16:48:39 2000
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 QAA38474
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 16:48:25 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64466 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S268321AbQATVrx>;
Thu, 20 Jan 2000 22:47:53 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12BPXr-000322-00; Thu, 20 Jan 2000 22:55:11 +0100
Date: Thu, 20 Jan 2000 22:55:11 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: prlw1@cam.ac.uk
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [GENERAL] Variable case database names
In-Reply-To: <20000120151257.F12966@quartz.newn.cam.ac.uk>
Message-ID: <Pine.LNX.4.21.0001202242260.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
There is some code in libpq which converts all database names to
lower-case, unless it's double quoted. That seems a little ill-conceived
to me, since you'd actually have to pass it something like
PGconnectdb("dbname=\"Newnham\"");
If anything, this would make it inconvenient it psql, because you'd have
to write
\c '"Newnham"'
since
\c "Newnham"
is interpreted differently.
Does anyone have an explanation for this? Why not leave the name as is?
On 2000-01-20, Patrick Welche mentioned:
List of databases
Database | Owner
------------+----------
Newnham | prlw1% psql Newnham
psql: connection to database "newnham" failed - FATAL 1: Database "newnham" does not exist in the system catalog.template1=> \c 'Newnham'
FATAL 1: Database "newnham" does not exist in the system catalog.
Previous connection keptHow can I connect to a database with a variable case name?
Cheers,
Patrick
************
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 16:51:58 2000
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 QAA39098;
Thu, 20 Jan 2000 16:51:16 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63934 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S268321AbQATVuc>;
Thu, 20 Jan 2000 22:50:32 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12BPaX-00032K-00; Thu, 20 Jan 2000 22:57:57 +0100
Date: Thu, 20 Jan 2000 22:57:57 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
cc: pgsql-docs@postgresql.org
Subject: Install file
Message-ID: <Pine.LNX.4.21.0001201818450.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
I took a stab at a new install file. It's shrunk to a fifth of its
former size and only has 10 steps. Please review it, if you care.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Thu Jan 20 17:12:32 2000
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 RAA48114
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 17:12:15 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA20758;
Thu, 20 Jan 2000 17:04:45 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001202204.RAA20758@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Variable case database names
In-Reply-To: <Pine.LNX.4.21.0001202242260.349-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 20, 2000 10:55:11 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 20 Jan 2000 17:04:45 -0500 (EST)
CC: prlw1@cam.ac.uk, PostgreSQL Development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
There is some code in libpq which converts all database names to
lower-case, unless it's double quoted. That seems a little ill-conceived
to me, since you'd actually have to pass it something like
PGconnectdb("dbname=\"Newnham\"");If anything, this would make it inconvenient it psql, because you'd have
to write
\c '"Newnham"'
since
\c "Newnham"
is interpreted differently.Does anyone have an explanation for this? Why not leave the name as is?
We do the same thing with queries, right? We force identifiers to lower
case unless quoted.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 20 17:20:33 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA49672
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 17:19:58 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id RAA23141
for pgsql-hackers@postgreSQL.org; Thu, 20 Jan 2000 17:19:53 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001202219.RAA23141@candle.pha.pa.us>
Subject: New INSTALL text file
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Thu, 20 Jan 2000 17:19:53 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM948406793-22954-0_
Content-Transfer-Encoding: 7bit
--ELM948406793-22954-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have taken Peter's new install.sgml and generated a new INSTALL text
file to match it. I used sgmltools to convert to HTML and netscape to
dump the html as text.
File attached.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026--ELM948406793-22954-0_
Content-Type: text/plain
Content-Disposition: inline; filename="/pgtop/INSTALL"
Content-Transfer-Encoding: 7bit
Chapter 0. Installation
Table of Contents
Before you start
Installation Procedure
Installation instructions for PostgreSQL 7.0.0.
Commands were tested on RedHat Linux version 5.2 using the bash shell.
Except where noted, they will probably work on most systems. Commands like
ps and tar may vary wildly between platforms on what options you should use.
Use common sense before typing in these commands.
If you haven't gotten the PostgreSQL distribution, get it from
ftp.postgresql.org, then unpack it:
$ gunzip postgresql-7.0.0.tar.gz
$ tar -xf postgresql-7.0.0.tar
$ mv postgresql-7.0.0 /usr/src
Again, these commands might differ on your system.
Before you start
Building PostgreSQL requires GNU make. It will not work with other make
programs. On GNU/Linux systems GNU make is the default tool, on other
systems you may find that GNU make is installed under the name "gmake". We
will use that name from now on to indicate GNU make, no matter what name it
has on your system. To test for GNU make enter
$ gmake --version
If you need to get GNU make, you can find it at ftp://ftp.gnu.org.
Up to date information on supported platforms is at
http://www.postgresql.org/docs/admin/ports.htm. In general, most
Unix-compatible platforms with modern libraries should be able to run
PostgreSQL. In the doc subdirectory of the distribution are several
platform-specific FAQ and README documents you might wish to consult if you
are having trouble.
Although the minimum required memory for running PostgreSQL can be as little
as 8MB, there are noticable speed improvements when expanding memory up to
96MB or beyond. The rule is you can never have too much memory.
Check that you have sufficient disk space. You will need about 30 Mbytes for
the source tree during compilation and about 5 Mbytes for the installation
directory. An empty database takes about 1 Mbyte, otherwise they take about
five times the amount of space that a flat text file with the same data
would take. If you run the regression tests you will temporarily need an
extra 20MB.
To check for disk space, use
$ df -k
Considering today's prices for hard disks, getting a large and fast hard
disk should probably be in your plans before putting a database into
production use.
---------------------------------------------------------------------------
Installation Procedure
PostgreSQL Installation
For a fresh install or upgrading from previous releases of PostgreSQL:
1. Create the PostgreSQL superuser account. This is the user the server
will run as. For production use you should create a separate,
unprivileged account (postgres is commonly used). If you do not have
root access or just want to play around, your own user account is
enough.
Running PostgreSQL as root, bin, or any other account with special
access rights is a security risk and therefore won't be allowed.
You need not do the building and installation itself under this account
(although you can). You will be told when you need to login as the
database superuser.
2. If you are not upgrading an existing system then skip to .
You now need to back up your existing database. To dump your fairly
recent post-6.0 database installation, type
$ pg_dumpall > db.out
If you wish to preserve object id's (oids), then use the -o option when
running pg_dumpall. However, unless you have a special reason for doing
this (such as using OIDs as keys in tables), don't do it.
Make sure to use the pg_dumpall command from the version you are
currently running. However, do not use the pg_dumpall script from 6.0
or everything will be owned by the PostgreSQL super user. In that case
you should grab pg_dumpall from a later 6.x.x release. 7.0's pg_dumpall
will not work on older databases. If you are upgrading from a version
prior to Postgres95 v1.09 then you must back up your database, install
Postgres95 v1.09, restore your database, then back it up again.
Caution
You must make sure that your database is not updated in the middle of your
backup. If necessary, bring down postmaster, edit the permissions in file
/usr/local/pgsql/data/pg_hba.conf to allow only you on, then bring
postmaster back up.
3. If you are upgrading an existing system then kill the database server
now. Type
$ ps ax | grep postmaster
This should list the process numbers for a number of processes, similar
to this:
263 ? SW 0:00 (postmaster)
777 p1 S 0:00 grep postmaster
Type the following line, with pid replaced by the process id for
process postmaster (263 in the above case). (Do not use the id for the
process "grep postmaster".)
$ kill pid
Tip: On systems which have PostgreSQL started at boot time,
there is probably a startup file which will accomplish the
same thing. For example, on a Redhat Linux system one might
find that
$ /etc/rc.d/init.d/postgres.init stop
works.
Also move the old directories out of the way. Type the following:
$ mv /usr/local/pgsql /usr/local/pgsql.old
or replace your particular paths.
4. Configure the source code for your system. It is this step at which you
can specify your actual installation path for the build process and
make choices about what gets installed. Change into the src
subdirectory and type:
$ ./configure [ options ]
For a complete list of options, type:
./configure --help
Some of the more commonly used ones are:
--prefix=BASEDIR
Selects a different base directory for the installation of
PostgreSQL. The default is /usr/local/pgsql.
--enable-locale
If you want to use locales.
--enable-multibyte
Allows the use of multibyte character encodings. This is primarily
for languages like Japanese, Korean, or Chinese.
--with-perl
Builds the Perl interface. Please note that the Perl interface
will be installed into the usual place for Perl modules (typically
under /usr/lib/perl), so you must have root access to use this
option successfully.
--with-odbc
Builds the ODBC driver package.
--with-tcl
Builds interface libraries and programs requiring Tcl/Tk,
including libpgtcl, pgtclsh, and pgtksh.
5. Compile the program. Type
$ gmake
The compilation process can take anywhere from 10 minutes to an hour.
Your milage will most certainly vary.
The last line displayed will hopefully be
All of PostgreSQL is successfully made. Ready to install.
Remember, "gmake" may be called "make" on your system.
6. Install the program. Type
$ gmake install
7. Tell your system how to find the new shared libraries. How to do this
varies between platforms. What tends to work everywhere is to set the
environment variable LD_LIBRARY_PATH:
$ LD_LIBRARY_PATH=/usr/local/pgsql/lib
$ export LD_LIBRARY_PATH
You might want to put this into a shell startup file such as
~/.bash_profile.
On some systems the following is the preferred method, but you must
have root access. Edit file /etc/ld.so.conf to add a line
/usr/local/pgsql/lib
Then run command /sbin/ldconfig.
If in doubt, refer to the manual pages of your system. If you later on
get a message like
./psql: error in loading shared libraries
libpq.so.2.1: cannot open shared object file: No such file or directory
then the above was necessary. Simply do this step then.
8. Create the database installation. To do this you must log in to your
PostgreSQL superuser account. It will not work as root.
$ mkdir /usr/local/pgsql/data
$ chown postgres /usr/local/pgsql/data
$ su - postgres
$ /usr/local/pgsql/initdb -D /usr/local/pgsql/data
The -D option specifies the location where the data will be stored. You
can use any path you want, it does not have to be under the
installation directory. Just make sure that the superuser account can
write to it (or create it) before starting initdb.
9. The previous step should have told you how to start up the database
server. Do so now.
$ /usr/local/pgsql/initdb/postmaster -D /usr/local/pgsql/data
This will start the server in the foreground. To make it detach to the
background, use the -S.
10. If you are upgrading from an existing installation, dump your data back
in:
$ /usr/local/pgsql/bin/psql < db.out
You also might want to copy over the old pg_hba.conf file and any other
files you might have had set up for authentication, such as password
files.
This concludes the installation proper. To make your life more productive
and enjoyable you should look at the following optional steps and
suggestions.
* Life will be more convenient if you set up some enviroment variables.
First of all you probably want to include /usr/local/pgsql/bin (or
equivalent) into your PATH. To do this, add the following to your shell
startup file, such as ~/.bash_profile (or /etc/profile, if you want it
to affect every user):
PATH=$PATH:/usr/local/pgsql/bin
Furthermore, if you set PGDATA in the environment of the PostgreSQL
superuser, you can omit the -D for postmaster and initdb.
* You probably want to install the man and HTML documentation. Type
$ cd /usr/src/pgsql/postgresql-7.0.0/doc
$ gmake install
This will install files under /usr/local/pgsql/doc.
The documentation is also available in Postscript format. If you have a
Postscript printer, or have your machine already set up to accept
Postscript files using a print filter, then to print the User's Guide
simply type
$ cd /usr/local/pgsql/doc
$ gunzip -c user.ps.tz | lpr
Here is how you might do it if you have Ghostscript on your system and
are writing to a laserjet printer.
$ alias gshp='gs -sDEVICE=laserjet -r300 -dNOPAUSE'
$ export GS_LIB=/usr/share/ghostscript:/usr/share/ghostscript/fonts
$ gunzip user.ps.gz
$ gshp -sOUTPUTFILE=user.hp user.ps
$ gzip user.ps
$ lpr -l -s -r manpage.hp
If in doubt, confer your manuals or your local expert.
The Adminstrator's Guide should probably be your first reading if you
are completely new to PostgreSQL, as it contains information about how
to set up database users and authentication.
* Usually, you will want to modify your computer so that it will
automatically start the database server whenever it boots. This is not
required; the PostgreSQL server can be run successfully from
non-privileged accounts without root intervention.
Different systems have different conventions for starting up daemons at
boot time, so you are advised to familiarize yourself with them. Most
systems have a file /etc/rc.local or /etc/rc.d/rc.local which is almost
certainly no bad place to put such a command. Whatever you do,
postmaster must be run by the PostgreSQL superuser (postgres) and not
by root or any other user. Therefore you probably always want to form
your command lines along the lines of su -c '...' postgres.
It might be advisable to keep a log of the server output. To start the
server that way try:
nohup su -c 'postmaster -D /usr/local/pgsql/data > server.log 2>&1' postgres &
Here are a few more operating system specific suggestions.
o Edit file rc.local on NetBSD or file rc2.d on SPARC Solaris 2.5.1
to contain the following single line:
su postgres -c "/usr/local/pgsql/bin/postmaster -S -D /usr/local/pgsql/data"
o In FreeBSD 2.2-RELEASE edit /usr/local/etc/rc.d/pgsql.sh to
contain the following lines and make it chmod 755 and chown
root:bin.
#!/bin/sh
[ -x /usr/local/pgsql/bin/postmaster ] && {
su -l pgsql -c 'exec /usr/local/pgsql/bin/postmaster
-D/usr/local/pgsql/data
-S -o -F > /usr/local/pgsql/errlog' &
echo -n ' pgsql'
}
You may put the line breaks as shown above. The shell is smart
enough to keep parsing beyond end-of-line if there is an
expression unfinished. The exec saves one layer of shell under the
postmaster process so the parent is init.
o In RedHat Linux add a file /etc/rc.d/init.d/postgres.init which is
based on the example in contrib/linux/. Then make a softlink to
this file from /etc/rc.d/rc5.d/S98postgres.init.
* Run the regression tests. The regression tests are a test suite to
verify that PostgreSQL runs on your machine in the way the developers
expected it to. You should definitely do this before putting a server
into production use. The file
/usr/src/pgsql/postgresql-7.0.0/src/test/regress/README has detailed
instructions for running and interpreting the regression tests.
--ELM948406793-22954-0_
--ELM948406793-22954-0_--
From bouncefilter Thu Jan 20 17:36:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA60583
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 17:36:07 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA25106;
Thu, 20 Jan 2000 17:35:46 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] COPY problems with psql / libpq
In-reply-to: <Pine.LNX.4.21.0001201916180.349-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001201916180.349-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Thu, 20 Jan 2000 22:54:56 +0100"
Date: Thu, 20 Jan 2000 17:35:45 -0500
Message-ID: <25103.948407745@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
: psql.c doesn't appear to cope correctly with quoted newlines in COPY data;
What's a quoted newline?
a) "<newline>"
b) "\n"
c) \<newline>
(c). That's how a newline appearing in the data is supposed to be
represented. IIRC, I was worried that if the \ falls at the end of
a bufferload and the newline at the start of the next, psql and/or
libpq would fail to recognize the pattern; if so, they'd probably
think the newline is a record boundary.
Patrick could be falling victim to this, but Oliver sez he has no
newlines in his data, so there's at least one other problem.
that would in any case still point to a problem elsewhere. Gotta pass the
buck to libpq ...
Could be. I think Alfred is on the hook here...
regards, tom lane
From bouncefilter Thu Jan 20 17:43:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA62013
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 17:43:08 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA25133;
Thu, 20 Jan 2000 17:42:39 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] timezone problem?
In-reply-to: <38873D5F.1E7F83A5@alumni.caltech.edu>
References: <20000120124950U.t-ishii@sra.co.jp>
<3887313F.8D8DF166@alumni.caltech.edu>
<21248.948385763@sss.pgh.pa.us>
<38873D5F.1E7F83A5@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Thu, 20 Jan 2000 16:52:47 +0000"
Date: Thu, 20 Jan 2000 17:42:39 -0500
Message-ID: <25130.948408159@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
HST is interpreted by Postgres as Hawaii Standard Time, which is on
the other side of the date line from Japan. Planning a vacation
Tatsuo?? :))
Then there's still something wrong:
test=> select '1998-09-23 12:05:10 HST'::datetime;
------------------------------
Wed Sep 23 22:05:10 1998 JST
10 hours behind JST (= GMT+9, IIRC) is in the wrong ocean to be
Hawaii...
regards, tom lane
From bouncefilter Thu Jan 20 17:47:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA62884
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 17:47:03 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA25167
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 17:46:37 -0500 (EST)
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] off topic
In-reply-to: <20000120190014.A868@fam-meskes.de>
References: <38873E7C.D0DC20D9@alumni.caltech.edu>
<200001201721.MAA06736@candle.pha.pa.us>
<20000120190014.A868@fam-meskes.de>
Comments: In-reply-to Michael Meskes <meskes@postgreSQL.org>
message dated "Thu, 20 Jan 2000 19:00:14 +0100"
Date: Thu, 20 Jan 2000 17:46:37 -0500
Message-ID: <25164.948408397@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Meskes <meskes@postgreSQL.org> writes:
On Thu, Jan 20, 2000 at 12:21:07PM -0500, Bruce Momjian wrote:
How do the programmers here get paid?
1. You do this in your spare time and dont get paid.Bingo!
I will give him a double-bingo!
Make this a triple.
Quadruple-bingo.
Actually I could be put into category (2) --- my company uses Postgres,
so I have some excuse for working on Postgres during working hours ---
but I spend way more personal than business time on it. It's just an
interesting project, that's all.
regards, tom lane
From bouncefilter Thu Jan 20 17:52:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA64033
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 17:52:09 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA25189;
Thu, 20 Jan 2000 17:51:43 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: prlw1@cam.ac.uk, PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [GENERAL] Variable case database names
In-reply-to: <Pine.LNX.4.21.0001202242260.349-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001202242260.349-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Thu, 20 Jan 2000 22:55:11 +0100"
Date: Thu, 20 Jan 2000 17:51:43 -0500
Message-ID: <25186.948408703@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
There is some code in libpq which converts all database names to
lower-case, unless it's double quoted. That seems a little ill-conceived
to me,
I think you are probably right. The backend might try to lowercase the
name when it gets it, but it seems like libpq shouldn't be doing so
(any more than it's responsible for downcasing identifiers used in
SQL commands).
If the backend *does* lowercase the DB name used in a connect command,
is there any way to use a mixed-case DB name? I'm not sure there is...
regards, tom lane
From bouncefilter Thu Jan 20 17:54:33 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA64579
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 17:54:30 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA25213;
Thu, 20 Jan 2000 17:54:20 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Status on 7.0
In-reply-to: <200001201811.NAA09507@candle.pha.pa.us>
References: <200001201811.NAA09507@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Thu, 20 Jan 2000 13:11:17 -0500"
Date: Thu, 20 Jan 2000 17:54:20 -0500
Message-ID: <25210.948408860@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Are we going to yank DISTINCT ON?
I don't show DISTINCT ON as being worked on by anyone.
I proposed removing it, but hadn't gotten around to doing anything
about it. Partly, I've been waiting to see if anyone would complain
that it should stay...
regards, tom lane
From bouncefilter Thu Jan 20 18:01:33 2000
Received: from corvette.mascari.com (dhcp26142035.columbus.rr.com
[24.26.142.35]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA67075
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 18:01:18 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id NAA00873;
Thu, 20 Jan 2000 13:59:38 -0500
Message-ID: <388792EF.A714B1DF@mascari.com>
Date: Thu, 20 Jan 2000 17:57:51 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] New INSTALL text file
References: <200001202219.RAA23141@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
I have taken Peter's new install.sgml and generated a new INSTALL text
file to match it. I used sgmltools to convert to HTML and netscape to
dump the html as text.File attached.
There are only two things I would want to see different. The
first is the example of running configure. Even though it is
beyond silly to think that people will interpret step 4
literally, I guarantee you some will, and will try to enter:
"./configure [ options ]"
You see it occasionally when users complain that they can't
create 'C' functions per the documentation:
CREATE FUNCTION add_one(int4) RETURNS int4
AS 'PGROOT/tutorial/funcs.so' LANGUAGE 'c';
People actually enter "PGROOT". On the vpnd list just yesterday
someone was complaining that the IP address of 324.240.123.122
(or something like that) was illegal and they couldn't get their
vpnd software working - despite the fact the documentation
explicitly notes that the IP address is an example and is
intentionally incorrect to prevent people for messing with
others' networks. People "key what they see" I'm afraid. So an
example configure command would be nice.
The only other thing is if somewhere there is a mention of the -o
-F options for the backend, suggesting its possible use. Since
fsync() is on by default, many people who don't dig into the docs
and are just trying PostgreSQL to see if its a plausible solution
may dismiss it out-of-hand for performance reasons. Even though I
know robustness is the #1 criteria for a RDBMS, I personally
believe fsync() should be *off* by default, but I know I'm in the
minority.
Just some thoughts,
Mike Mascari
From bouncefilter Thu Jan 20 18:05:33 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA73896
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 18:05:06 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id PAA20496;
Thu, 20 Jan 2000 15:04:09 -0800 (PST)
Message-Id: <3.0.1.32.20000120150103.00e49ec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 20 Jan 2000 15:01:03 -0800
To: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] A notice for too long names
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgresql.org
In-Reply-To: <Pine.LNX.4.21.0001201907190.349-100000@localhost.localdoma
in>
References: <21095.948383705@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:54 PM 1/20/00 +0100, Peter Eisentraut wrote:
On 2000-01-20, Tom Lane mentioned:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Wouldn't it be fair if a notice was generated if you attempt to create
and/or reference a name that's longer than NAMEDATALEN.Would it be better to throw an elog(ERROR)?
Definitely NOT. Rejecting long identifiers went out with Dartmouth Basic.
But it came back with compilers issuing warnings (hence notice) about
them. Silently truncating input went out with GNU,
GNU C was hardly the first compiler to correctly handle identifiers
of virtually any length. I doubt if it even makes the list of the first
100...
(I get tired of GNU-worship)
How deeply embedded is the limitation on identifier length? Ideal
would be to remove any artificial limitation whatsoever.
The current situation isn't bad, since name clashes are rare - it's
not as though PostgreSQL is only keeping the first six characters
like Fortran 66! Still, all such limitations are fundamentally
irksome.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Thu Jan 20 18:17:33 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id SAA76718
for <hackers@postgresql.org>; Thu, 20 Jan 2000 18:16:36 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 10590 invoked by uid 1001); 20 Jan 2000 23:16:41 -0000
Message-ID: <XFMail.000120181641.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Thu, 20 Jan 2000 18:16:41 -0500 (EST)
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: hackers@postgresql.org
Subject: New install doc
2. If you are not upgrading an existing system then skip to .
skip to 4.
6. Install the program. Type
$ gmake install
The installer needs to have write access to the install directory.
8. Create the database installation. To do this you must log in to your
PostgreSQL superuser account. It will not work as root.
$ mkdir /usr/local/pgsql/data
$ chown postgres /usr/local/pgsql/data
I thought the data directory was created either in the gmake install step
or initdb. Either way the chown might be better as:
# chown -R postgres:postgres /usr/local/pgsql
that should be the same on most systems with perhaps the exception of the
colon. Anyway it'll make sure that all the files have the correct owners.
9. The previous step should have told you how to start up the database
server. Do so now.
$ /usr/local/pgsql/initdb/postmaster -D /usr/local/pgsql/data
Shouldn't that be /usr/local/pgsql/bin/postmaster ??
^^^
Outside of that, it looks great!!
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Thu Jan 20 19:32:34 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA98940
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 19:31:49 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA25390
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 19:31:32 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Some notes on optimizer cost estimates
Date: Thu, 20 Jan 2000 19:31:32 -0500
Message-ID: <25387.948414692@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I have been spending some time measuring actual runtimes for various
sequential-scan and index-scan query plans, and have learned that the
current Postgres optimizer's cost estimation equations are not very
close to reality at all.
Presently we estimate the cost of a sequential scan as
Nblocks + CPU_PAGE_WEIGHT * Ntuples
--- that is, the unit of cost is the time to read one disk page,
and we have a "fudge factor" that relates CPU time per tuple to
disk time per page. (The default CPU_PAGE_WEIGHT is 0.033, which
is probably too high for modern hardware --- 0.01 seems like it
might be a better default, at least for simple queries.) OK,
it's a simplistic model, but not too unreasonable so far.The cost of an index scan is measured in these same terms as
Nblocks + CPU_PAGE_WEIGHT * Ntuples +
CPU_INDEX_PAGE_WEIGHT * Nindextuples
Here Ntuples is the number of tuples selected by the index qual
condition (typically, it's less than the total table size used in
sequential-scan estimation). CPU_INDEX_PAGE_WEIGHT essentially
estimates the cost of scanning an index tuple; by default it's 0.017 or
half CPU_PAGE_WEIGHT. Nblocks is estimated as the index size plus an
appropriate fraction of the main table size.
There are two big problems with this:
1. Since main-table tuples are visited in index order, we'll be hopping
around from page to page in the table. The current cost estimation
method essentially assumes that the buffer cache plus OS disk cache will
be 100% efficient --- we will never have to read the same page of the
main table twice in a scan, due to having discarded it between
references. This of course is unreasonably optimistic. Worst case
is that we'd fetch a main-table page for each selected tuple, but in
most cases that'd be unreasonably pessimistic.
2. The cost of a disk page fetch is estimated at 1.0 unit for both
sequential and index scans. In reality, sequential access is *much*
cheaper than the quasi-random accesses performed by an index scan.
This is partly a matter of physical disk seeks, and partly a matter
of benefitting (or not) from any read-ahead logic the OS may employ.
As best I can measure on my hardware, the cost of a nonsequential
disk read should be estimated at 4 to 5 times the cost of a sequential
one --- I'm getting numbers like 2.2 msec per disk page for sequential
scans, and as much as 11 msec per page for index scans. I don't
know, however, if this ratio is similar enough on other platforms
to be useful for cost estimating. We could make it a parameter like
we do for CPU_PAGE_WEIGHT ... but you know and I know that no one
ever bothers to adjust those numbers in the field ...
The other effect that needs to be modeled, and currently is not, is the
"hit rate" of buffer cache. Presumably, this is 100% for tables smaller
than the cache and drops off as the table size increases --- but I have
no particular thoughts on the form of the dependency. Does anyone have
ideas here? The problem is complicated by the fact that we don't really
know how big the cache is; we know the number of buffers Postgres has,
but we have no idea how big a disk cache the kernel is keeping. As near
as I can tell, finding a hit in the kernel disk cache is not a lot more
expensive than having the page sitting in Postgres' own buffers ---
certainly it's much much cheaper than a disk read.
BTW, if you want to do some measurements of your own, try turning on
PGOPTIONS="-d 2 -te". This will dump a lot of interesting numbers
into the postmaster log, if your platform supports getrusage().
regards, tom lane
From bouncefilter Thu Jan 20 19:53:34 2000
Received: from corvette.mascari.com (dhcp26142035.columbus.rr.com
[24.26.142.35]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA03339
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 19:53:28 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id PAA00995;
Thu, 20 Jan 2000 15:51:43 -0500
Message-ID: <3887AD33.8A153F58@mascari.com>
Date: Thu, 20 Jan 2000 19:49:55 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
References: <25387.948414692@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
As best I can measure on my hardware, the cost of a nonsequential
disk read should be estimated at 4 to 5 times the cost of a sequential
one --- I'm getting numbers like 2.2 msec per disk page for sequential
scans, and as much as 11 msec per page for index scans. I don't
know, however, if this ratio is similar enough on other platforms
to be useful for cost estimating. We could make it a parameter like
we do for CPU_PAGE_WEIGHT ... but you know and I know that no one
ever bothers to adjust those numbers in the field ...
Would it be possible to place those parameters as run-time
settings and then write a utility that can ship with the
distribution to determine those values? Kind of a self-tuning
utility?
Mike Mascari
From bouncefilter Thu Jan 20 20:12:34 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA12765
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 20:11:40 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA25654;
Thu, 20 Jan 2000 20:11:20 -0500 (EST)
To: Mike Mascari <mascarm@mascari.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
In-reply-to: <3887AD33.8A153F58@mascari.com>
References: <25387.948414692@sss.pgh.pa.us> <3887AD33.8A153F58@mascari.com>
Comments: In-reply-to Mike Mascari <mascarm@mascari.com>
message dated "Thu, 20 Jan 2000 19:49:55 -0500"
Date: Thu, 20 Jan 2000 20:11:19 -0500
Message-ID: <25651.948417079@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Mike Mascari <mascarm@mascari.com> writes:
to be useful for cost estimating. We could make it a parameter like
we do for CPU_PAGE_WEIGHT ... but you know and I know that no one
ever bothers to adjust those numbers in the field ...
Would it be possible to place those parameters as run-time
settings and then write a utility that can ship with the
distribution to determine those values? Kind of a self-tuning
utility?
Maybe. I'm not sure the average user would want to run it ---
to get believable numbers, you have to be using a table considerably
bigger than the kernel's disk cache, which means it takes a while.
(I've been testing with a gigabyte-sized table ... one of the index
scan runs took thirty hours :-( ... fortunately I have this machine
to myself, or there would have been some howls about the load.)
But it'd be nice to have comparable numbers for different platforms.
What I was really hoping was that someone on the list would be aware
of existing research I could borrow from.
regards, tom lane
From bouncefilter Thu Jan 20 20:39:35 2000
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 UAA24170
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 20:38:53 -0500 (EST) (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 KAA04082; Fri, 21 Jan 2000 10:38:40 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Some notes on optimizer cost estimates
Date: Fri, 21 Jan 2000 10:44:20 +0900
Message-ID: <000b01bf63b1$093cbd40$2801007e@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 V5.00.2314.1300
In-Reply-To: <25387.948414692@sss.pgh.pa.us>
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom LaneI have been spending some time measuring actual runtimes for various
sequential-scan and index-scan query plans, and have learned that the
current Postgres optimizer's cost estimation equations are not very
close to reality at all.
Thanks for your good analysis.
I also have said current cost estimation for index-scan is too low.
But I have had no concrete numerical values.
I've wondered why we cound't analyze database without vacuum.
We couldn't run vacuum light-heartedly because it acquires an
exclusive lock for the target table.
In addition,vacuum error occurs with analyze option in most
cases AFAIK.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Thu Jan 20 20:55:35 2000
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 UAA26877
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 20:55:02 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA04664;
Fri, 21 Jan 2000 10:55:00 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-16 [133.137.84.16])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA06591;
Fri, 21 Jan 2000 10:54:57 +0900
To: tgl@sss.pgh.pa.us
Cc: lockhart@alumni.caltech.edu, t-ishii@sra.co.jp,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] timezone problem?
In-Reply-To: <25130.948408159@sss.pgh.pa.us>
References: <21248.948385763@sss.pgh.pa.us>
<38873D5F.1E7F83A5@alumni.caltech.edu>
<25130.948408159@sss.pgh.pa.us>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000121105651T.t-ishii@sra.co.jp>
Date: Fri, 21 Jan 2000 10:56:51 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 58
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
HST is interpreted by Postgres as Hawaii Standard Time, which is on
the other side of the date line from Japan. Planning a vacation
Tatsuo?? :))
I wish I could do so:-) I hate the cold winter in Japan...
Then there's still something wrong:
test=> select '1998-09-23 12:05:10 HST'::datetime;
------------------------------
Wed Sep 23 22:05:10 1998 JST10 hours behind JST (= GMT+9, IIRC) is in the wrong ocean to be
Hawaii...
Right. HST is GMT-10, and JST - HST = 19 hours. So '1998-09-23
12:05:10 HST' shoud be 'Thu Sep 24 07:05:10 1998 JST', rather than 'Wed
Sep 23 22:05:10 1998 JST'...
Looking into the zoneinfo files under /usr/share/zoneinfo, I found 'Japan'
as a valid zone name (I could not find 'JST' too on my RH box).
test=> select '1998-09-23 12:05:10 HST'::datetime;
?column?
------------------------------
Thu Sep 24 07:05:10 1998 JST -- correct
(1 row)
test=> set timezone to 'JST';
SET VARIABLE
test=> select '1998-09-23 12:05:10 HST'::datetime;
?column?
------------------------------
Wed Sep 23 22:05:10 1998 JST -- wrong. seems interpreted as GMT (UTC)
(1 row)
test=> set timezone to 'Japan';
SET VARIABLE
test=> select '1998-09-23 12:05:10 HST'::datetime;
?column?
------------------------------
Thu Sep 24 07:05:10 1998 JST -- correct. but why showed as JST?
(1 row)
test=> reset timezone;
RESET VARIABLE
test=> select '1998-09-23 12:05:10 HST'::datetime;
?column?
------------------------------
Thu Sep 24 07:05:10 1998 JST -- again, correct
(1 row)
Seems something wrong with my RH 5.2. Note that FreeBSD does have the
problem.
--
Tatsuo Ishii
From bouncefilter Thu Jan 20 20:58:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA27498
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 20:58:11 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA26646;
Thu, 20 Jan 2000 20:58:04 -0500 (EST)
To: prlw1@cam.ac.uk
cc: pgsql-hackers@postgreSQL.org
Subject: vacuum failure in current sources
In-reply-to: <20000120163645.J12966@quartz.newn.cam.ac.uk>
References: <20000120130318.E12966@quartz.newn.cam.ac.uk>
<21053.948383104@sss.pgh.pa.us>
<20000120155317.H12966@quartz.newn.cam.ac.uk>
<21189.948384383@sss.pgh.pa.us>
<20000120163645.J12966@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Thu, 20 Jan 2000 16:36:45 +0000"
Date: Thu, 20 Jan 2000 20:58:03 -0500
Message-ID: <26643.948419883@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
This is with source from yesterday, but I seem to remember the same
happening to me on 6th January. It used to work before then. I don't
know where to look!
% psql template1
template1=> create database test;
CREATE DATABASE
template1=> \c test
You are now connected to database test.
test=> create table atable (x int);
CREATE
test=> insert into atable values (1);
INSERT 558537 1
test=> vacuum analyze atable;
NOTICE: Vacuum: table not found
VACUUM
test=> select version();
version
-------------------------------------------------------------------------
PostgreSQL 7.0.0 on i386-unknown-netbsd1.4p, compiled by gcc egcs-1.1.2
(1 row)
Wow. It works fine for me. Platform-specific bug maybe? Can anyone
else reproduce this?
regards, tom lane
From bouncefilter Thu Jan 20 21:19:35 2000
Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA34534
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 21:19:26 -0500 (EST) (envelope-from xun@cs.ucsb.edu)
Received: from xp10-06.dialup.commserv.ucsb.edu
(root@xp10-06.dialup.commserv.ucsb.edu [128.111.253.249])
by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id SAA04655
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 18:19:22 -0800 (PST)
Received: from xp10-06.dialup.commserv.ucsb.edu (xun@localhost)
by xp10-06.dialup.commserv.ucsb.edu (8.9.3/8.9.3) with ESMTP id
SAA22377
for <pgsql-hackers@postgreSQL.org>; Thu, 20 Jan 2000 18:19:40 -0800
Message-Id: <200001210219.SAA22377@xp10-06.dialup.commserv.ucsb.edu>
To: pgsql-hackers@postgreSQL.org
Reply-to: xun@cs.ucsb.edu
Subject: Re. [HACKERS] Some notes on optimizer cost estimates
Date: Thu, 20 Jan 2000 18:19:40 -0800
From: Xun Cheng <xun@cs.ucsb.edu>
I'm very glad you bring up this cost estimate issue.
Recent work in database research have argued a more
detailed disk access cost model should be used for
large queries especially joins.
Traditional cost estimate only considers the number of
disk pages accessed. However a more detailed model
would consider three parameters: avg. seek, avg. latency
and avg. page transfer. For old disk, typical values are
SEEK=9.5 milliseconds, LATENCY=8.3 ms, TRANSFER=2.6ms.
A sequential continuous reading of a table (assuming
1000 continuous pages) would cost
(SEEK+LATENCY+1000*TRANFER=2617.8ms); while quasi-randomly
reading 200 times with 2 continuous pages/time would
cost (SEEK+200*LATENCY+400*TRANSFER=2700ms).
Someone from IBM lab re-studied the traditional
ad hoc join algorithms (nested, sort-merge, hash) using the detailed cost model
and found some interesting results.
I have been spending some time measuring actual runtimes for various
sequential-scan and index-scan query plans, and have learned that the
current Postgres optimizer's cost estimation equations are not very
close to reality at all.
One interesting question I'd like to ask is if this non-closeness
really affects the optimal choice of postgresql's query optimizer.
And to what degree the effects might be? My point is that
if the optimizer estimated the cost for sequential-scan is 10 and
the cost for index-scan is 20 while the actual costs are 10 vs. 40,
it should be ok because the optimizer would still choose sequential-scan
as it should.
1. Since main-table tuples are visited in index order, we'll be hopping
around from page to page in the table.
I'm not sure about the implementation in postgresql. One thing you might
be able to do is to first collect all must-read page addresses from
the index scan and then order them before the actual ordered page fetching.
It would at least avoid the same page being read twice (not entirely
true depending on the context (like in join) and algo.)
The current cost estimation
method essentially assumes that the buffer cache plus OS disk cache will
be 100% efficient --- we will never have to read the same page of the
main table twice in a scan, due to having discarded it between
references. This of course is unreasonably optimistic. Worst case
is that we'd fetch a main-table page for each selected tuple, but in
most cases that'd be unreasonably pessimistic.
This is actually the motivation that I asked before if postgresql
has a raw disk facility. That way we have much control on this cache
issue. Of course only if we can provide some algo. better than OS
cache algo. (depending on the context, like large joins), a raw disk
facility will be worthwhile (besides the recoverability).
Actually I have another question for you guys which is somehow related
to this cost estimation issue. You know the difference between OLTP
and OLAP. My question is how you target postgresql on both kinds
of applications or just OLTP. From what I know OLTP and OLAP would
have a big difference in query characteristics and thus
optimization difference. If postgresql is only targeted on
OLTP, the above cost estimation issue might not be that
important. However for OLAP, large tables and large queries are
common and optimization would be difficult.
xun
From bouncefilter Thu Jan 20 21:31:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA37422
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 21:31:02 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id VAA26761;
Thu, 20 Jan 2000 21:30:41 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
In-reply-to: <000b01bf63b1$093cbd40$2801007e@tpf.co.jp>
References: <000b01bf63b1$093cbd40$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Fri, 21 Jan 2000 10:44:20 +0900"
Date: Thu, 20 Jan 2000 21:30:41 -0500
Message-ID: <26758.948421841@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I've wondered why we cound't analyze database without vacuum.
We couldn't run vacuum light-heartedly because it acquires an
exclusive lock for the target table.
There is probably no real good reason, except backwards compatibility,
why the ANALYZE function (obtaining pg_statistic data) is part of
VACUUM at all --- it could just as easily be a separate command that
would only use read access on the database. Bruce is thinking about
restructuring VACUUM, so maybe now is a good time to think about
splitting out the ANALYZE code too.
In addition,vacuum error occurs with analyze option in most
cases AFAIK.
Still, with current sources? What's the error message? I fixed
a problem with pg_statistic tuples getting too big...
regards, tom lane
From bouncefilter Thu Jan 20 21:50:35 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA42525
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 21:50:29 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA07186;
Thu, 20 Jan 2000 21:48:58 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001210248.VAA07186@candle.pha.pa.us>
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
In-Reply-To: <26758.948421841@sss.pgh.pa.us> from Tom Lane at "Jan 20,
2000 09:30:41 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 20 Jan 2000 21:48:57 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I've wondered why we cound't analyze database without vacuum.
We couldn't run vacuum light-heartedly because it acquires an
exclusive lock for the target table.There is probably no real good reason, except backwards compatibility,
why the ANALYZE function (obtaining pg_statistic data) is part of
VACUUM at all --- it could just as easily be a separate command that
would only use read access on the database. Bruce is thinking about
restructuring VACUUM, so maybe now is a good time to think about
splitting out the ANALYZE code too.
I put it in vacuum because at the time I didn't know how to do such
things and vacuum already scanned the table. I just linked on the the
scan. Seemed like a good idea at the time.
It is nice that ANALYZE is done during vacuum. I can't imagine why you
would want to do an analyze without adding a vacuum to it. I guess
that's why I made them the same command.
If I made them separate commands, both would have to scan the table,
though the analyze could do it without the exclusive lock, which would
be good.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 20 21:54:36 2000
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 VAA42983
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 21:53:47 -0500 (EST) (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 LAA04135; Fri, 21 Jan 2000 11:53:41 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Some notes on optimizer cost estimates
Date: Fri, 21 Jan 2000 11:59:20 +0900
Message-ID: <001201bf63bb$83adc1a0$2801007e@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 V5.00.2314.1300
In-Reply-To: <26758.948421841@sss.pgh.pa.us>
Importance: Normal
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]In addition,vacuum error occurs with analyze option in most
cases AFAIK.Still, with current sources? What's the error message? I fixed
a problem with pg_statistic tuples getting too big...
Sorry,my English is poor.
When I saw vacuum bug reports,there were 'analyze' option mostly.
'Analyze' is harmful for safety of vacuum.
I'm thinking that 'analyze' is not preferable especially for index
recreation in vacuum.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Thu Jan 20 22:11:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA49224
for <pgsql-hackers@postgresql.org>;
Thu, 20 Jan 2000 22:10:42 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA27080;
Thu, 20 Jan 2000 22:10:28 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
In-reply-to: <200001210248.VAA07186@candle.pha.pa.us>
References: <200001210248.VAA07186@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Thu, 20 Jan 2000 21:48:57 -0500"
Date: Thu, 20 Jan 2000 22:10:28 -0500
Message-ID: <27077.948424228@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
It is nice that ANALYZE is done during vacuum. I can't imagine why you
would want to do an analyze without adding a vacuum to it. I guess
that's why I made them the same command.
Well, the main bad thing about ANALYZE being part of VACUUM is that
it adds to the length of time that VACUUM is holding an exclusive
lock on the table. I think it'd make more sense for it to be a
separate command.
I have also been thinking about how to make ANALYZE produce a more
reliable estimate of the most common value. The three-element list
that it keeps now is a good low-cost hack, but it really doesn't
produce a trustworthy answer unless the MCV is pretty darn C (since
it will never pick up on the MCV at all until there are at least
two occurrences in three adjacent tuples). The only idea I've come
up with is to use a larger list, which would be slower and take
more memory. I think that'd be OK in a separate command, but I
hesitate to do it inside VACUUM --- VACUUM has its own considerable
memory requirements, and there's still the issue of not holding down
an exclusive lock longer than you have to.
regards, tom lane
From bouncefilter Thu Jan 20 22:03:36 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA47430
for <hackers@postgreSQL.org>; Thu, 20 Jan 2000 22:03:21 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id DAA28893;
Fri, 21 Jan 2000 03:11:52 GMT
Sender: lockhart@hub.org
Message-ID: <3887CE78.5ACBF3EE@alumni.caltech.edu>
Date: Fri, 21 Jan 2000 03:11:52 +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: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: Date/time type
References: <Pine.LNX.4.21.0001201535470.349-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
... I was thinking along the lines of
If you want me to help writing something like this up, tell me.
Well, looks like you just did. If you want to plop it into sgml and
commit it, that would be great. Otherwise, I'll steal it and do it
sometime soon ;)
This is by no means to bash the documentation writers, I just like the
idea of supporting standard SQL over Postgres'isms where both are
equivalent. See also CAST vs ::, etc.
Right, I'm happy going through the docs and emphasizing SQL92 vs older
"Pig-isms" for equivalent features. For 7.0, I'd also like to go
through and reorganize the User's Guide, but I'm not sure if I'll get
time...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Jan 20 22:09:36 2000
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 WAA48832
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 22:08:43 -0500 (EST) (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 MAA04148; Fri, 21 Jan 2000 12:08:30 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Some notes on optimizer cost estimates
Date: Fri, 21 Jan 2000 12:14:10 +0900
Message-ID: <001301bf63bd$95cbe680$2801007e@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 V5.00.2314.1300
In-Reply-To: <200001210248.VAA07186@candle.pha.pa.us>
Importance: Normal
-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I've wondered why we cound't analyze database without vacuum.
We couldn't run vacuum light-heartedly because it acquires an
exclusive lock for the target table.There is probably no real good reason, except backwards compatibility,
why the ANALYZE function (obtaining pg_statistic data) is part of
VACUUM at all --- it could just as easily be a separate command that
would only use read access on the database. Bruce is thinking about
restructuring VACUUM, so maybe now is a good time to think about
splitting out the ANALYZE code too.I put it in vacuum because at the time I didn't know how to do such
things and vacuum already scanned the table. I just linked on the the
scan. Seemed like a good idea at the time.It is nice that ANALYZE is done during vacuum. I can't imagine why you
would want to do an analyze without adding a vacuum to it. I guess
that's why I made them the same command.If I made them separate commands, both would have to scan the table,
though the analyze could do it without the exclusive lock, which would
be good.
The functionality of VACUUM and ANALYZE is quite different.
I don't prefer to charge VACUUM more than now about analyzing
database. Probably looong lock,more aborts ....
Various kind of analysis would be possible by splitting out ANALYZE.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Thu Jan 20 22:28:36 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA51733
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 22:28:24 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id DAA28918;
Fri, 21 Jan 2000 03:36:32 GMT
Sender: lockhart@hub.org
Message-ID: <3887D440.27781C9E@alumni.caltech.edu>
Date: Fri, 21 Jan 2000 03:36:32 +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 <pgman@candle.pha.pa.us>, Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Status on 7.0
References: <Pine.LNX.4.21.0001201506290.349-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
What I'd suggest -- and the 7.0 release is certainly one of the better
times to do this -- is to change the catalog entries to "integer",
"bigint", etc. and instead do the translation of the "deprecated" (or
"traditional", if you like) types "int4", "int8", etc. into the standard
ones. As far as I can see this would require only two changes for each
datatype (gram.y:xlateSqlType(), and pg_type.h), so this could be done
transparently to the rest of the code. And client applications don't need
to know this at all.
Is there a problem with this I'm not seeing (other than perhaps affective
attachment to Postgres'isms)? This almost seems too trivial to not have
been done already.
One reason this hasn't been done is that we would lose the
(occasional) correspondence between internal names and external names,
which isn't a very good reason.
I've also thought that we might implement some "by reference" types to
replace the "by value" types we have now (and use the SQL92 names for
them). But Tom Lane has talked about fixing up the internal problems
we have with passing info about NULLs with "by value" types, so that
might be a bad way to head. However, the downside to eliminating "by
value"s (extra footprint?) might be offset by being able to remove
code which has to handle both cases (extra speed?).
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Jan 20 22:52:36 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA58176
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 22:52:34 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA09379;
Thu, 20 Jan 2000 22:52:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001210352.WAA09379@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Status on 7.0
In-Reply-To: <3887D440.27781C9E@alumni.caltech.edu> from Thomas Lockhart at
"Jan 21, 2000 03:36:32 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Thu, 20 Jan 2000 22:52:13 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
One reason this hasn't been done is that we would lose the
(occasional) correspondence between internal names and external names,
which isn't a very good reason.I've also thought that we might implement some "by reference" types to
replace the "by value" types we have now (and use the SQL92 names for
them). But Tom Lane has talked about fixing up the internal problems
we have with passing info about NULLs with "by value" types, so that
might be a bad way to head. However, the downside to eliminating "by
value"s (extra footprint?) might be offset by being able to remove
code which has to handle both cases (extra speed?).
I have added a TODO item:
* add pg_dump option to dump type names as standard ANSI types
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Jan 20 22:52:37 2000
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 WAA58097
for <pgsql-hackers@postgreSQL.org>;
Thu, 20 Jan 2000 22:51:50 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id MAA12934;
Fri, 21 Jan 2000 12:51:48 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-30 [133.137.84.30])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id MAA08135;
Fri, 21 Jan 2000 12:51:46 +0900
To: tgl@sss.pgh.pa.us
Cc: prlw1@cam.ac.uk, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] vacuum failure in current sources
In-Reply-To: <26643.948419883@sss.pgh.pa.us>
References: <21189.948384383@sss.pgh.pa.us>
<20000120163645.J12966@quartz.newn.cam.ac.uk>
<26643.948419883@sss.pgh.pa.us>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000121125339J.t-ishii@sra.co.jp>
Date: Fri, 21 Jan 2000 12:53:39 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 29
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
This is with source from yesterday, but I seem to remember the same
happening to me on 6th January. It used to work before then. I don't
know where to look!% psql template1
template1=> create database test;
CREATE DATABASE
template1=> \c test
You are now connected to database test.
test=> create table atable (x int);
CREATE
test=> insert into atable values (1);
INSERT 558537 1
test=> vacuum analyze atable;
NOTICE: Vacuum: table not found
VACUUM
test=> select version();
version
-------------------------------------------------------------------------
PostgreSQL 7.0.0 on i386-unknown-netbsd1.4p, compiled by gcc egcs-1.1.2
(1 row)Wow. It works fine for me. Platform-specific bug maybe? Can anyone
else reproduce this?
I do not see the problem neither. This is RH 5.2.
--
Tatsuo Ishii
From bouncefilter Thu Jan 20 23:17:36 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA65860
for <hackers@postgresql.org>; Thu, 20 Jan 2000 23:16:49 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id EAA29265;
Fri, 21 Jan 2000 04:25:17 GMT
Sender: lockhart@hub.org
Message-ID: <3887DFAD.85A3BEA@alumni.caltech.edu>
Date: Fri, 21 Jan 2000 04:25:17 +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: Vince Vielhaber <vev@michvhf.com>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] timezone problem?
References: <Pine.BSF.4.05.10001201218210.8515-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I can see why they'd have one for EST since Indiana doesn't observe, but
why MST? Perhaps there's a state I'm not thinking of. Found it, it
appears Arizona doesn't observe.
Ah, good call. I knew about Arizona, but not Indiana.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 21 00:10:37 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA83222
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 00:10:29 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA03459;
Fri, 21 Jan 2000 00:10:21 -0500 (EST)
To: prlw1@cam.ac.uk
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump disaster
In-reply-to: <20000119192454.A10697@quartz.newn.cam.ac.uk>
References: <20000119192454.A10697@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Wed, 19 Jan 2000 19:24:54 +0000"
Date: Fri, 21 Jan 2000 00:10:21 -0500
Message-ID: <3456.948431421@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
Trying to load a 6 January pg_dumpall file with today's postgresql gives
many
invalid command \N
probably because
PQexec: you gotta get out of a COPY state yourself.
db.out4:11621: invalid command \.
Somehow psql is out of sync and thinks the \N isn't within a COPY block.
The answer appears to be that Perlstein's "nonblocking mode" patches
have broken psql copy, and doubtless a lot of other applications as
well, because pqPutBytes no longer feels any particular compulsion
to actually send the data it's been handed. (Moreover, if it does
do only a partial send, there is no way to discover how much it sent;
while its callers might be blamed for not having checked for an error
return, they'd have no way to recover anyhow.)
I thought these patches should not have been applied without more
peer review, and now I'm sure of it. I recommend reverting 'em.
regards, tom lane
From bouncefilter Fri Jan 21 00:26:37 2000
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 AAA85356
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 00:25:44 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id OAA19816;
Fri, 21 Jan 2000 14:25:42 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id OAA09149;
Fri, 21 Jan 2000 14:25:42 +0900
To: lockhart@alumni.caltech.edu
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] timezone problem?
In-Reply-To: Your message of "Fri, 21 Jan 2000 05:28:44 +0000"
<3887EE8C.5A2E0044@alumni.caltech.edu>
References: <3887EE8C.5A2E0044@alumni.caltech.edu>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000121142541U.t-ishii@sra.co.jp>
Date: Fri, 21 Jan 2000 14:25:41 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 14
That is typical when you use the long form of the time zone name such
as "Japan". You will also find a "US/Pacific" on your machine:
Maybe I'm going to check where the translation Japan -> JST has benn
actually done.
Seems something wrong with my RH 5.2. Note that FreeBSD does have the
problem.Sorry, FreeBSD also has the problem, or does not??
Sorry, FreeBSD does *not* have the problem as far as I know.
--
Tatsuo Ishii
From bouncefilter Fri Jan 21 00:23:37 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA85114
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 00:23:28 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id FAA29338;
Fri, 21 Jan 2000 05:28:44 GMT
Sender: lockhart@hub.org
Message-ID: <3887EE8C.5A2E0044@alumni.caltech.edu>
Date: Fri, 21 Jan 2000 05:28:44 +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: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] timezone problem?
References: <21248.948385763@sss.pgh.pa.us>
<38873D5F.1E7F83A5@alumni.caltech.edu>
<25130.948408159@sss.pgh.pa.us> <20000121105651T.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tatsuo Ishii wrote:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
HST is interpreted by Postgres as Hawaii Standard Time, which is on
the other side of the date line from Japan. Planning a vacation
Tatsuo?? :))I wish I could do so:-) I hate the cold winter in Japan...
Then there's still something wrong:
test=> select '1998-09-23 12:05:10 HST'::datetime;
------------------------------
Wed Sep 23 22:05:10 1998 JST10 hours behind JST (= GMT+9, IIRC) is in the wrong ocean to be
Hawaii...Right. HST is GMT-10, and JST - HST = 19 hours. So '1998-09-23
12:05:10 HST' shoud be 'Thu Sep 24 07:05:10 1998 JST', rather than 'Wed
Sep 23 22:05:10 1998 JST'...Looking into the zoneinfo files under /usr/share/zoneinfo, I found 'Japan'
as a valid zone name (I could not find 'JST' too on my RH box).test=> select '1998-09-23 12:05:10 HST'::datetime;
?column?
------------------------------
Thu Sep 24 07:05:10 1998 JST -- correct
(1 row)test=> set timezone to 'JST';
SET VARIABLE
test=> select '1998-09-23 12:05:10 HST'::datetime;
?column?
------------------------------
Wed Sep 23 22:05:10 1998 JST -- wrong. seems interpreted as GMT (UTC)
(1 row)test=> set timezone to 'Japan';
SET VARIABLE
test=> select '1998-09-23 12:05:10 HST'::datetime;
?column?
------------------------------
Thu Sep 24 07:05:10 1998 JST -- correct. but why showed as JST?
(1 row)
That is typical when you use the long form of the time zone name such
as "Japan". You will also find a "US/Pacific" on your machine:
[root@golem zoneinfo]# setenv TZ US/Pacific
[root@golem zoneinfo]# date
Thu Jan 20 21:24:24 PST 2000
which is the same as PST8PDT.
In /usr/share/zoneinfo/US, the mysteries of the various states'
conventions are revealed:
[root@golem zoneinfo]# ls -1 US
Alaska
Aleutian
Arizona
Central
East-Indiana
Eastern
Hawaii
Indiana-Starke
Michigan
Mountain
Pacific
Samoa
where, as Vince pointed out, Indiana, Michigan, and Arizona seem to be
special cases within the usual three timezones.
Seems something wrong with my RH 5.2. Note that FreeBSD does have the
problem.
Sorry, FreeBSD also has the problem, or does not??
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 21 00:44:37 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA91378
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 00:44:04 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA13592;
Fri, 21 Jan 2000 00:43:49 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001210543.AAA13592@candle.pha.pa.us>
Subject: vacuum timings
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 21 Jan 2000 00:43:49 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I loaded 10,000,000 rows into CREATE TABLE test (x INTEGER); Table is
400MB and index is 160MB.
With index on the single in4 column, I got:
78 seconds for a vacuum
121 seconds for vacuum after deleting a single row
662 seconds for vacuum after deleting the entire table
With no index, I got:
43 seconds for a vacuum
43 seconds for vacuum after deleting a single row
43 seconds for vacuum after deleting the entire table
I find this quite interesting.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 21 00:41:37 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA91055
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 00:40:59 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id FAA29871;
Fri, 21 Jan 2000 05:47:49 GMT
Sender: lockhart@hub.org
Message-ID: <3887F305.68187BD0@alumni.caltech.edu>
Date: Fri, 21 Jan 2000 05:47:49 +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: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] timezone problem?
References: <3887EE8C.5A2E0044@alumni.caltech.edu>
<20000121142541U.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Maybe I'm going to check where the translation Japan -> JST has benn
actually done.
You will find it in the timezone file itself. Use "zdump" to look at
the file of interest:
[root@golem zoneinfo]# zdump -v /usr/share/zoneinfo/Japan
Japan Fri Dec 13 20:45:52 1901 GMT = Sat Dec 14 05:45:52 1901 JST
isdst=0
Japan Sat Dec 14 20:45:52 1901 GMT = Sun Dec 15 05:45:52 1901 JST
isdst=0
Japan Mon Jan 18 03:14:07 2038 GMT = Mon Jan 18 12:14:07 2038 JST
isdst=0
Japan Tue Jan 19 03:14:07 2038 GMT = Tue Jan 19 12:14:07 2038 JST
isdst=0
Wow, that is a short set of rules! The PST8PDT file is 374 lines ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 21 00:50:38 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA92231
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 00:49:58 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA13736;
Fri, 21 Jan 2000 00:49:34 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001210549.AAA13736@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_dump disaster
In-Reply-To: <3456.948431421@sss.pgh.pa.us> from Tom Lane at "Jan 21,
2000 00:10:21 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 21 Jan 2000 00:49:34 -0500 (EST)
CC: prlw1@cam.ac.uk, pgsql-hackers@postgreSQL.org, bright@wintelcom.net
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
Trying to load a 6 January pg_dumpall file with today's postgresql gives
many
invalid command \N
probably because
PQexec: you gotta get out of a COPY state yourself.
db.out4:11621: invalid command \.
Somehow psql is out of sync and thinks the \N isn't within a COPY block.The answer appears to be that Perlstein's "nonblocking mode" patches
have broken psql copy, and doubtless a lot of other applications as
well, because pqPutBytes no longer feels any particular compulsion
to actually send the data it's been handed. (Moreover, if it does
do only a partial send, there is no way to discover how much it sent;
while its callers might be blamed for not having checked for an error
return, they'd have no way to recover anyhow.)I thought these patches should not have been applied without more
peer review, and now I'm sure of it. I recommend reverting 'em.
Can we give the submitter a few days to address the issue?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 21 00:52:38 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA92633
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 00:51:56 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA03644;
Fri, 21 Jan 2000 00:51:51 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: vacuum timings
In-reply-to: <200001210543.AAA13592@candle.pha.pa.us>
References: <200001210543.AAA13592@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Fri, 21 Jan 2000 00:43:49 -0500"
Date: Fri, 21 Jan 2000 00:51:51 -0500
Message-ID: <3641.948433911@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I loaded 10,000,000 rows into CREATE TABLE test (x INTEGER); Table is
400MB and index is 160MB.
With index on the single in4 column, I got:
78 seconds for a vacuum
121 seconds for vacuum after deleting a single row
662 seconds for vacuum after deleting the entire table
With no index, I got:
43 seconds for a vacuum
43 seconds for vacuum after deleting a single row
43 seconds for vacuum after deleting the entire table
I find this quite interesting.
How long does it take to create the index on your setup --- ie,
if vacuum did a drop/create index, would it be competitive?
regards, tom lane
From bouncefilter Fri Jan 21 01:01:38 2000
Received: from caemrad.com.au (flame.caemrad.com.au [150.101.252.1])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA95665
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 01:01:14 -0500 (EST)
(envelope-from pauls@caemrad.com.au)
Received: (from mail@localhost) by caemrad.com.au (8.8.7/8.8.7) id QAA31433
for <pgsql-hackers@postgreSQL.org>; Fri, 21 Jan 2000 16:31:06 +1030
X-Authentication-Warning: stalag13.caemrad.com.au: mail set sender to
<pauls@caemrad.com.au> using -f
Received: from harpo.caemrad.com.au(150.101.132.19) by stalag13.caemrad.com.au
via smap (V2.1) id xma031431; Fri, 21 Jan 00 16:30:53 +1030
Received: from pion.caemrad.com.au [150.101.132.39] by harpo.caemrad.com.au
(8.6.12/AndrewR-950711-MRAD) with ESMTP id QAA20085 for
<pgsql-hackers@postgreSQL.org>; Fri, 21 Jan 2000 16:30:51 +1030
Received: (from pauls@localhost) by caemrad.com.au (8.9.3/8.8.7) id QAA12751
for pgsql-hackers@postgreSQL.org; Fri, 21 Jan 2000 16:28:43 +1030
From: Paul Schulz <pauls@caemrad.com.au>
Message-Id: <200001210558.QAA12751@caemrad.com.au>
Subject: Re: [HACKERS] timezone problem?
To: pgsql-hackers@postgreSQL.org
Date: Fri, 21 Jan 2000 16:28:43 +1030 (CST)
In-Reply-To: <3887F305.68187BD0@alumni.caltech.edu> from "Thomas Lockhart" at
Jan 21, 2000 05:47:49 AM
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Has anyone noticed the following timezoning problem..
If a datetime variable is read out, and then inserted back in again
(verbatim) I get a change in the time value. I suspect that it because
out lime zona Australia/Adelaide is CST, which I belive is also an
American timezone. Trimming the timezone info (CST) off, fixes this
problem. Can anyone shed any light?
How does one get the +1030 timezone format?
PaulS
Maybe I'm going to check where the translation Japan -> JST has benn
actually done.You will find it in the timezone file itself. Use "zdump" to look at
the file of interest:[root@golem zoneinfo]# zdump -v /usr/share/zoneinfo/Japan
Japan Fri Dec 13 20:45:52 1901 GMT = Sat Dec 14 05:45:52 1901 JST
isdst=0
Japan Sat Dec 14 20:45:52 1901 GMT = Sun Dec 15 05:45:52 1901 JST
isdst=0
Japan Mon Jan 18 03:14:07 2038 GMT = Mon Jan 18 12:14:07 2038 JST
isdst=0
Japan Tue Jan 19 03:14:07 2038 GMT = Tue Jan 19 12:14:07 2038 JST
isdst=0Wow, that is a short set of rules! The PST8PDT file is 374 lines ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California************
From bouncefilter Fri Jan 21 01:10:38 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA98847
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 01:10:05 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA03751;
Fri, 21 Jan 2000 01:09:58 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: prlw1@cam.ac.uk, pgsql-hackers@postgreSQL.org, bright@wintelcom.net
Subject: Re: [HACKERS] pg_dump disaster
In-reply-to: <200001210549.AAA13736@candle.pha.pa.us>
References: <200001210549.AAA13736@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Fri, 21 Jan 2000 00:49:34 -0500"
Date: Fri, 21 Jan 2000 01:09:57 -0500
Message-ID: <3748.948434997@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I thought these patches should not have been applied without more
peer review, and now I'm sure of it. I recommend reverting 'em.
Can we give the submitter a few days to address the issue?
Sure, we have plenty of time. But I don't think the problem can be
fixed without starting over. He's taken routines that had two possible
return conditions ("Success" and "Hard failure: he's dead, Jim") and
added a third condition ("I didn't do what I was supposed to do, or
perhaps only some of what I was supposed to do, because I was afraid
of blocking"). If dealing with that third condition could be hidden
entirely inside libpq, that'd be OK, but the entire point of this
set of changes is to bounce control back to the application rather
than block. Therefore, what we are looking at is a fundamental change
in the API of existing routines, which is *guaranteed* to break existing
applications. (Worse, it breaks them subtly: the code will compile,
and may even work under light load.)
I think the correct approach is to leave the semantics of the existing
exported routines alone, and add parallel entry points with new
semantics to be used by applications that need to avoid blocking.
That's what we've done for queries, and later for connecting, and it
hasn't broken anything.
regards, tom lane
From bouncefilter Fri Jan 21 01:27:38 2000
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA01710
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 01:26:44 -0500 (EST) (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 NAA01685;
Fri, 21 Jan 2000 13:26:33 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <3887FC19.80305217@krs.ru>
Date: Fri, 21 Jan 2000 13:26:33 +0700
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 <pgman@candle.pha.pa.us>
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] vacuum timings
References: <200001210543.AAA13592@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
I loaded 10,000,000 rows into CREATE TABLE test (x INTEGER); Table is
400MB and index is 160MB.With index on the single in4 column, I got:
78 seconds for a vacuum
121 seconds for vacuum after deleting a single row
662 seconds for vacuum after deleting the entire tableWith no index, I got:
43 seconds for a vacuum
43 seconds for vacuum after deleting a single row
43 seconds for vacuum after deleting the entire table
Wi/wo -F ?
Vadim
From bouncefilter Fri Jan 21 01:41:38 2000
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 BAA08868
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 01:40:43 -0500 (EST) (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 PAA04316; Fri, 21 Jan 2000 15:40:35 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "PostgreSQL-development" <pgsql-hackers@postgreSQL.org>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Subject: RE: [HACKERS] vacuum timings
Date: Fri, 21 Jan 2000 15:46:15 +0900
Message-ID: <000201bf63db$36cdae20$2801007e@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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <200001210543.AAA13592@candle.pha.pa.us>
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce MomjianI loaded 10,000,000 rows into CREATE TABLE test (x INTEGER); Table is
400MB and index is 160MB.With index on the single in4 column, I got:
78 seconds for a vacuum
vc_vaconeind() is called once
121 seconds for vacuum after deleting a single row
vc_vaconeind() is called twice
Hmmm,vc_vaconeind() takes pretty long time even if it does little.
662 seconds for vacuum after deleting the entire table
How about half of the rows deleted case ?
It would take longer time.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Fri Jan 21 01:50:38 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA09716
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 01:49:52 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA16050;
Fri, 21 Jan 2000 01:49:28 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001210649.BAA16050@candle.pha.pa.us>
Subject: Re: [HACKERS] vacuum timings
In-Reply-To: <3887FC19.80305217@krs.ru> from Vadim Mikheev at "Jan 21,
2000 01:26:33 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Fri, 21 Jan 2000 01:49:28 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
I loaded 10,000,000 rows into CREATE TABLE test (x INTEGER); Table is
400MB and index is 160MB.With index on the single in4 column, I got:
78 seconds for a vacuum
121 seconds for vacuum after deleting a single row
662 seconds for vacuum after deleting the entire tableWith no index, I got:
43 seconds for a vacuum
43 seconds for vacuum after deleting a single row
43 seconds for vacuum after deleting the entire tableWi/wo -F ?
With no -F.
I can get you -F times tomorrow.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 21 01:51:38 2000
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA09838
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 01:50:59 -0500 (EST) (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 NAA02303;
Fri, 21 Jan 2000 13:50:43 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <388801C2.3B78E1FA@krs.ru>
Date: Fri, 21 Jan 2000 13:50:42 +0700
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 <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] vacuum timings
References: <000201bf63db$36cdae20$2801007e@tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hiroshi Inoue wrote:
With index on the single in4 column, I got:
78 seconds for a vacuumvc_vaconeind() is called once
^^^^^^
not called ?
121 seconds for vacuum after deleting a single row
vc_vaconeind() is called twice
Hmmm,vc_vaconeind() takes pretty long time even if it does little.
It reads all index leaf pages in any case...
Vadim
From bouncefilter Fri Jan 21 01:58:38 2000
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 BAA10645
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 01:58:12 -0500 (EST) (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 PAA04328; Fri, 21 Jan 2000 15:57:55 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Vadim Mikheev" <vadim@krs.ru>
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>,
"PostgreSQL-development" <pgsql-hackers@postgreSQL.org>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Subject: RE: [HACKERS] vacuum timings
Date: Fri, 21 Jan 2000 16:03:35 +0900
Message-ID: <000301bf63dd$a2b42360$2801007e@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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <388801C2.3B78E1FA@krs.ru>
-----Original Message-----
From: root@sunpine.krs.ru [mailto:root@sunpine.krs.ru]On Behalf Of Vadim
MikheevHiroshi Inoue wrote:
With index on the single in4 column, I got:
78 seconds for a vacuumvc_vaconeind() is called once
^^^^^^
not called ?
Oops,you are right.
vc_scanoneind() is called once.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Fri Jan 21 02:09:39 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA15615
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 02:08:37 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA31014;
Fri, 21 Jan 2000 07:16:56 GMT
Sender: lockhart@hub.org
Message-ID: <388807E7.12B3BEB3@alumni.caltech.edu>
Date: Fri, 21 Jan 2000 07:16: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: Paul Schulz <pauls@caemrad.com.au>,
Michael Robinson <robinson@netrinsics.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] timezone problem?
References: <200001210558.QAA12751@caemrad.com.au>
Content-Type: multipart/mixed; boundary="------------A5B216F147C6ADC050E03B4B"
This is a multi-part message in MIME format.
--------------A5B216F147C6ADC050E03B4B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
If a datetime variable is read out, and then inserted back in again
(verbatim) I get a change in the time value. I suspect that it because
out lime zona Australia/Adelaide is CST, which I belive is also an
American timezone. Trimming the timezone info (CST) off, fixes this
problem. Can anyone shed any light?
Yup. Fully 1/4 of our timezone lookup table is consumed by Australian
time zones (y'all have multiple names for *everything*!). There are
some name conflicts, of course :(
How does one get the +1030 timezone format?
Use ACSST or CADT or SADT (at least that is what is defined in the
Postgres lookup table for *exactly* the same time offset).
Or...
Apply the enclosed patch, then compile the backend with:
-DUSE_AUSTRALIAN_RULES=1
(Or move to another country. Recompiling the backend is probably
easier... ;)
This is covered in the docs in the appendix on "Date/Time Support",
but CST was not included and it looks to me that EAST had sign
trouble. Both are fixed in the enclosed patch.
btw, the patch also tries to fix the "GMT+hhmm" timezone format
reported recently as being available on FreeBSD; perhaps someone could
test that at the same time.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
--------------A5B216F147C6ADC050E03B4B
Content-Type: text/plain; charset=us-ascii;
name="dt.c.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="dt.c.patch"
*** dt.c.orig Tue Jan 18 17:25:51 2000
--- dt.c Fri Jan 21 07:12:10 2000
***************
*** 1980,1986 ****
--- 1980,1990 ----
{"cdt", DTZ, NEG(30)}, /* Central Daylight Time */
{"cet", TZ, 6}, /* Central European Time */
{"cetdst", DTZ, 12}, /* Central European Dayl.Time */
+ #if USE_AUSTRALIAN_RULES
+ {"cst", TZ, 63}, /* Australia Eastern Std Time */
+ #else
{"cst", TZ, NEG(36)}, /* Central Standard Time */
+ #endif
{DCURRENT, RESERV, DTK_CURRENT}, /* "current" is always now */
{"dec", MONTH, 12},
{"december", MONTH, 12},
***************
*** 1988,1994 ****
{"dow", RESERV, DTK_DOW}, /* day of week */
{"doy", RESERV, DTK_DOY}, /* day of year */
{"dst", DTZMOD, 6},
! {"east", TZ, NEG(60)}, /* East Australian Std Time */
{"edt", DTZ, NEG(24)}, /* Eastern Daylight Time */
{"eet", TZ, 12}, /* East. Europe, USSR Zone 1 */
{"eetdst", DTZ, 18}, /* Eastern Europe */
--- 1992,1998 ----
{"dow", RESERV, DTK_DOW}, /* day of week */
{"doy", RESERV, DTK_DOY}, /* day of year */
{"dst", DTZMOD, 6},
! {"east", TZ, 60}, /* East Australian Std Time */
{"edt", DTZ, NEG(24)}, /* Eastern Daylight Time */
{"eet", TZ, 12}, /* East. Europe, USSR Zone 1 */
{"eetdst", DTZ, 18}, /* Eastern Europe */
***************
*** 2688,2693 ****
--- 2692,2712 ----
if (DecodeTimezone(field[i], tzp) != 0)
return -1;
tmask = DTK_M(TZ);
+
+ /*
+ * Swallow an immediately previous timezone if it is GMT
+ * This handles the odd case in FreeBSD of "GMT+0800"
+ * but note that we need to flip the sign on this too.
+ * Claims to be some sort of Posix standard format :(
+ * - thomas 2000-01-20
+ */
+ if ((tmask & fmask) && (tzp != NULL) && (*tzp == 0)
+ && ((*field[i] == '+') || (*field[i] == '-'))
+ && (i >= 1) && (strcasecmp(field[i-1], "GMT") == 0))
+ {
+ tmask &= ~DTK_M(TZ);
+ *tzp = -(*tzp);
+ }
break;case DTK_NUMBER:
--------------A5B216F147C6ADC050E03B4B--
From bouncefilter Fri Jan 21 06:59:42 2000
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA87797
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 06:59:08 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9D3E72.dip0.t-ipconnect.de
(root@p3E9D3E72.dip0.t-ipconnect.de [62.157.62.114])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id NAA21153
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 13:00:40 +0100 (CET)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id IAA00434
for pgsql-hackers@postgreSQL.org; Fri, 21 Jan 2000 08:35:07 +0100
Date: Fri, 21 Jan 2000 08:35:07 +0100
From: Michael Meskes <meskes@postgreSQL.org>
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] off topic
Message-ID: <20000121083507.A426@fam-meskes.de>
Mail-Followup-To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
References: <20000120190014.A868@fam-meskes.de>
<200001201856.NAA10879@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <200001201856.NAA10879@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Thu, Jan 20, 2000 at 01:56:49PM
-0500
On Thu, Jan 20, 2000 at 01:56:49PM -0500, Bruce Momjian wrote:
I think we are all insane, or very sane. Not sure which.
Ask my wife and she surely says the former. :-)
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Fri Jan 21 03:39:40 2000
Received: from netrinsics.com ([202.106.6.112])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA39190
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 03:39:22 -0500 (EST)
(envelope-from robinson@netrinsics.com)
Received: (from robinson@localhost)
by netrinsics.com (8.9.3/8.9.3) id QAA01497;
Fri, 21 Jan 2000 16:39:00 +0800 (+0800) (envelope-from robinson)
Date: Fri, 21 Jan 2000 16:39:00 +0800 (+0800)
From: Michael Robinson <robinson@netrinsics.com>
Message-Id: <200001210839.QAA01497@netrinsics.com>
To: lockhart@alumni.caltech.edu, pauls@caemrad.com.au, robinson@netrinsics.com
Subject: Re: [HACKERS] timezone problem?
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <388807E7.12B3BEB3@alumni.caltech.edu>
If a datetime variable is read out, and then inserted back in again
(verbatim) I get a change in the time value. I suspect that it because
out lime zona Australia/Adelaide is CST, which I belive is also an
American timezone. Trimming the timezone info (CST) off, fixes this
problem. Can anyone shed any light?
Yes, and even worse, CST also is "China Standard Time" in some operating
systems. I won't go into how broken every operating system is vis-a-vis
Chinese timezones (but, believe me, it's a mess).
From here on out, I'm strictly in "+0800".
Yup. Fully 1/4 of our timezone lookup table is consumed by Australian
time zones (y'all have multiple names for *everything*!). There are
some name conflicts, of course :(
I've become convinced that any project that thinks it is going to keep
comprehensive, accurate, non-conflicting, non-obsolete timezone information
in an application-specific table is woefully misguided.
btw, the patch also tries to fix the "GMT+hhmm" timezone format
reported recently as being available on FreeBSD; perhaps someone could
test that at the same time.
Does this patch apply cleanly against 6.5.3?
-Michael Robinson
From bouncefilter Fri Jan 21 03:48:40 2000
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 DAA40409
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 03:47:59 -0500 (EST) (envelope-from wieck@debis.com)
Received: from debis.com by orion.SAPserv.Hamburg.dsh.de with smtp
for <pgsql-hackers@postgreSQL.org>
id m12BZax-0003kIC; Fri, 21 Jan 100 09:39 MET
Sender: wieck
Message-ID: <38881B27.482D8D97@debis.com>
Date: Fri, 21 Jan 2000 09:39:03 +0100
From: Jan Wieck <wieck@debis.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>,
Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: Status on 7.0
References: <200001190341.WAA15358@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Can I ask how our big open items for 7.0 are doing:
Long tuples/TOAST(Jan)
Foriegn keys/action buffer(Jan)
Unify date/time types(Thomas)
Outer Joins(Thomas)I am only asking to know if we should continue with the planned Feb 1
beta?
I know now that I have to do all the missing FOREIGN KEY stuff
myself. And thats not the file buffering alone. We cannot ship
FOREIGN KEY if pg_dump cannot handle it.
Up to now, nothing I did for TOAST changed anything visible. So it
has to wait for FK.
Currently, I'm a little busy, so I don't expect TOAST for 7.0
anymore - sorry.
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 Fri Jan 21 04:32:40 2000
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA50818;
Fri, 21 Jan 2000 04:32:23 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (sfcabop1.nettuno.it [193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id KAA22898;
Fri, 21 Jan 2000 10:32:21 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 12Bal3-0000Tq-00; Fri, 21 Jan 2000 09:53:33 +0000
Message-ID: <38881F35.CAA49A56@sferacarta.com>
Date: Fri, 21 Jan 2000 09:56:21 +0100
From: Jose Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: interfaces <pgsql-interfaces@postgresql.org>,
hackers <pgsql-hackers@postgresql.org>
Subject: ODBC drive strange behavior
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Please help!
The PSQLODBC aborts a transaction with a strange error while execute a
legal query.
The message is:
"Could not begin a transaction; unexpected protocol character from
backend (sen_query) (#1)"
I tried the same query with psql client and it works with no problems.
Does anyone know what this message means ?
My configuration:
Data base server: PostgreSQL v6.5.2
OS server: Linux 2.0.37 (Debian)
Win Client: M$_Access95
PsqlODBC v6.40.0006
log file attached.
Any help would be very apreciated.
Jos���
From bouncefilter Fri Jan 21 04:32:40 2000
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA50834;
Fri, 21 Jan 2000 04:32:24 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (sfcabop1.nettuno.it [193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id KAA12383;
Fri, 21 Jan 2000 10:32:22 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 12BanL-0000Tt-00; Fri, 21 Jan 2000 09:55:55 +0000
Message-ID: <38881FC3.D34B1BEC@sferacarta.com>
Date: Fri, 21 Jan 2000 09:58:43 +0100
From: Jose Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: interfaces <pgsql-interfaces@postgresql.org>,
hackers <pgsql-hackers@postgresql.org>
Subject: Re: ODBC drive strange behavior
References: <38881F35.CAA49A56@sferacarta.com>
Content-Type: multipart/mixed; boundary="------------4C67C5F375F657E37C344777"
This is a multi-part message in MIME format.
--------------4C67C5F375F657E37C344777
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sorry I forgot to send the attachement :)
Jose Soares wrote:
Please help!
The PSQLODBC aborts a transaction with a strange error while execute a
legal query.
The message is:"Could not begin a transaction; unexpected protocol character from
backend (sen_query) (#1)"I tried the same query with psql client and it works with no problems.
Does anyone know what this message means ?
My configuration:
Data base server: PostgreSQL v6.5.2
OS server: Linux 2.0.37 (Debian)
Win Client: M$_Access95
PsqlODBC v6.40.0006
log file attached.Any help would be very apreciated.
Jos���
--------------4C67C5F375F657E37C344777
Content-Type: application/x-unknown-content-type-txtfile; name="LOG_ERROR.log"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="LOG_ERROR.log"
PERFTEVURUQ+DQpjb25uPTEyODk1MDU0NCwgcXVlcnk9J0JFR0lOJw0KY29ubj0xMjg5NTA1
NDQsIHF1ZXJ5PSdkZWNsYXJlIFNRTF9DVVIwN0IwNTY5OCBjdXJzb3IgZm9yIFNFTEVDVCAi
Y29kaWNlX2Zpc2NhbGUiICBGUk9NICJ1dGVudGkiIFdIRVJFIE5PVCgoImNvZGljZV9maXNj
YWxlIiA9ICJhemllbmRhIiApICkgR1JPVVAgQlkgImNvZGljZV9maXNjYWxlIiAgSEFWSU5H
IChDT1VOVCgiY29kaWNlX2Zpc2NhbGUiICkgID4gMSApICcNCmNvbm49MTI4OTUwNTQ0LCBx
dWVyeT0nZmV0Y2ggMTAwIGluIFNRTF9DVVIwN0IwNTY5OCcNCiAgICBbIGZldGNoZWQgMCBy
b3dzIF0NCmNvbm49MTI4OTUwNTQ0LCBxdWVyeT0nY2xvc2UgU1FMX0NVUjA3QjA1Njk4Jw0K
Y29ubj0xMjg5NTA1NDQsIHF1ZXJ5PSdFTkQnDQpjb25uPTEyODk1MDU0NCwgcXVlcnk9J0JF
R0lOJw0KY29ubj0xMjg5NTA1NDQsIHF1ZXJ5PScoU0VMRUNUICJmaWd1cmUiLiJhemllbmRh
IiAsImZpZ3VyZSIuImNvZGljZV9maWd1cmEiICwidXRlbnRpIi4icmFnaW9uZV9zb2NpYWxl
IiAsInV0ZW50aSIuImlzdGF0IiAsInV0ZW50aSIuImNhcCIgLCJ1dGVudGkiLiJpbmRpcml6
em8iICwidXRlbnRpIi4iY2l2aWNvIiAsImZpZ3VyZSIuInRpcG8iICwidXRlbnRpIi4iY29k
aWNlX2Zpc2NhbGUiICwidXRlbnRpIi4icGFydGl0YV9pdmEiICwiZmlndXJlIi4iZmluZV9h
dHRpdml0YSIgLCJmaWd1cmUiLiJkYXRhX2VzcG9ydGF6aW9uZSIgLCJmaWd1cmUiLiJkYXRh
X2FnZ2lvcm5hbWVudG8iICwidXRlbnRpIi4iZGlzdHJldHRvIiAsImZpZ3VyZSIuImdydXBw
byIgLCJmaWd1cmUiLiJkYXRhX2VzcG9ydGF6aW9uZSIgLCJ1dGVudGkiLiJkYXRhX2VzcG9y
dGF6aW9uZSIgIEZST00gImZpZ3VyZSIsInV0ZW50aSIgV0hFUkUgKCgiZmlndXJlIi4idGlw
byIgSU4gKCdEJyAsJ0RCJyAsJ0RPJyAsJ0RTJyApICkgQU5EICgiZmlndXJlIi4iY29kaWNl
X2ZpZ3VyYSIgPSAidXRlbnRpIi4iYXppZW5kYSIgKSApICkgVU5JT04gQUxMIChTRUxFQ1Qg
ImZpZ3VyZSIuImF6aWVuZGEiICwiZmlndXJlIi4iY29kaWNlX2ZpZ3VyYSIgLCJ1dGVudGki
LiJyYWdpb25lX3NvY2lhbGUiICwidXRlbnRpIi4iaXN0YXQiICwidXRlbnRpIi4iY2FwIiAs
InV0ZW50aSIuImluZGlyaXp6byIgLCJ1dGVudGkiLiJjaXZpY28iICwiZmlndXJlIi4idGlw
byIgLCJ1dGVudGkiLiJjb2RpY2VfZmlzY2FsZSIgLCJ1dGVudGkiLiJwYXJ0aXRhX2l2YSIg
LCJmaWd1cmUiLiJmaW5lX2F0dGl2aXRhIiAsImZpZ3VyZSIuImRhdGFfZXNwb3J0YXppb25l
IiAsImZpZ3VyZSIuImRhdGFfYWdnaW9ybmFtZW50byIgLCJ1dGVudGkiLiJkaXN0cmV0dG8i
ICwiZmlndXJlIi4iZ3J1cHBvIiAsImZpZ3VyZSIuImRhdGFfZXNwb3J0YXppb25lIiAsInV0
ZW50aSIuImRhdGFfZXNwb3J0YXppb25lIiAgRlJPTSAiZmlndXJlIiwidXRlbnRpIiBXSEVS
RSAoKCJmaWd1cmUiLiJ0aXBvIiBJTiAoJ1AnICwnUEInICwnUE8nICwnUFMnICwnQScgKSAp
IEFORCAoImZpZ3VyZSIuImNvZGljZV9maWd1cmEiID0gInV0ZW50aSIuImF6aWVuZGEiICkg
KSApJw0KY29ubj0xMjg5NTA1NDQsIHF1ZXJ5PSdBQk9SVCcNClNUQVRFTUVOVCBFUlJPUjog
ZnVuYz1TQ19leGVjdXRlLCBkZXNjPScnLCBlcnJudW09MSwgZXJybXNnPSdFcnJvciB3aGls
ZSBleGVjdXRpbmcgdGhlIHF1ZXJ5Jw0KICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAg
ICAgICAgICAgICAgaGRiYz0xMjg5NTA1NDQsIHN0bXQ9MTI4OTk3MDE2LCByZXN1bHQ9MA0K
ICAgICAgICAgICAgICAgICBtYW51YWxfcmVzdWx0PTAsIHByZXBhcmU9MCwgaW50ZXJuYWw9
MA0KICAgICAgICAgICAgICAgICBiaW5kaW5ncz0wLCBiaW5kaW5nc19hbGxvY2F0ZWQ9MA0K
ICAgICAgICAgICAgICAgICBwYXJhbWV0ZXJzPTAsIHBhcmFtZXRlcnNfYWxsb2NhdGVkPTAN
CiAgICAgICAgICAgICAgICAgc3RhdGVtZW50X3R5cGU9LTEsIHN0YXRlbWVudD0nKFNFTEVD
VCAiZmlndXJlIi4iYXppZW5kYSIgLCJmaWd1cmUiLiJjb2RpY2VfZmlndXJhIiAsInV0ZW50
aSIuInJhZ2lvbmVfc29jaWFsZSIgLCJ1dGVudGkiLiJpc3RhdCIgLCJ1dGVudGkiLiJjYXAi
ICwidXRlbnRpIi4iaW5kaXJpenpvIiAsInV0ZW50aSIuImNpdmljbyIgLCJmaWd1cmUiLiJ0
aXBvIiAsInV0ZW50aSIuImNvZGljZV9maXNjYWxlIiAsInV0ZW50aSIuInBhcnRpdGFfaXZh
IiAsImZpZ3VyZSIuImZpbmVfYXR0aXZpdGEiICwiZmlndXJlIi4iZGF0YV9lc3BvcnRhemlv
bmUiICwiZmlndXJlIi4iZGF0YV9hZ2dpb3JuYW1lbnRvIiAsInV0ZW50aSIuImRpc3RyZXR0
byIgLCJmaWd1cmUiLiJncnVwcG8iICwiZmlndXJlIi4iZGF0YV9lc3BvcnRhemlvbmUiICwi
dXRlbnRpIi4iZGF0YV9lc3BvcnRhemlvbmUiICBGUk9NICJmaWd1cmUiLCJ1dGVudGkiIFdI
RVJFICgoImZpZ3VyZSIuInRpcG8iIElOICgnRCcgLCdEQicgLCdETycgLCdEUycgKSApIEFO
RCAoImZpZ3VyZSIuImNvZGljZV9maWd1cmEiID0gInV0ZW50aSIuImF6aWVuZGEiICkgKSAp
IFVOSU9OIEFMTCAoU0VMRUNUICJmaWd1cmUiLiJhemllbmRhIiAsImZpZ3VyZSIuImNvZGlj
ZV9maWd1cmEiICwidXRlbnRpIi4icmFnaW9uZV9zb2NpYWxlIiAsInV0ZW50aSIuImlzdGF0
IiAsInV0ZW50aSIuImNhcCIgLCJ1dGVudGkiLiJpbmRpcml6em8iICwidXRlbnRpIi4iY2l2
aWNvIiAsImZpZ3VyZSIuInRpcG8iICwidXRlbnRpIi4iY29kaWNlX2Zpc2NhbGUiICwidXRl
bnRpIi4icGFydGl0YV9pdmEiICwiZmlndXJlIi4iZmluZV9hdHRpdml0YSIgLCJmaWd1cmUi
LiJkYXRhX2VzcG9ydGF6aW9uZSIgLCJmaWd1cmUiLiJkYXRhX2FnZ2lvcm5hbWVudG8iICwi
dXRlbnRpIi4iZGlzdHJldHRvIiAsImZpZ3VyZSIuImdydXBwbyIgLCJmaWd1cmUiLiJkYXRh
X2VzcG9ydGF6aW9uZSIgLCJ1dGVudGkiLiJkYXRhX2VzcG9ydGF6aW9uZSIgIEZST00gImZp
Z3VyZSIsInV0ZW50aSIgV0hFUkUgKCgiZmlndXJlIi4idGlwbyIgSU4gKCdQJyAsJ1BCJyAs
J1BPJyAsJ1BTJyAsJ0EnICkgKSBBTkQgKCJmaWd1cmUiLiJjb2RpY2VfZmlndXJhIiA9ICJ1
dGVudGkiLiJhemllbmRhIiApICkgKScNCiAgICAgICAgICAgICAgICAgc3RtdF93aXRoX3Bh
cmFtcz0nKFNFTEVDVCAiZmlndXJlIi4iYXppZW5kYSIgLCJmaWd1cmUiLiJjb2RpY2VfZmln
dXJhIiAsInV0ZW50aSIuInJhZ2lvbmVfc29jaWFsZSIgLCJ1dGVudGkiLiJpc3RhdCIgLCJ1
dGVudGkiLiJjYXAiICwidXRlbnRpIi4iaW5kaXJpenpvIiAsInV0ZW50aSIuImNpdmljbyIg
LCJmaWd1cmUiLiJ0aXBvIiAsInV0ZW50aSIuImNvZGljZV9maXNjYWxlIiAsInV0ZW50aSIu
InBhcnRpdGFfaXZhIiAsImZpZ3VyZSIuImZpbmVfYXR0aXZpdGEiICwiZmlndXJlIi4iZGF0
YV9lc3BvcnRhemlvbmUiICwiZmlndXJlIi4iZGF0YV9hZ2dpb3JuYW1lbnRvIiAsInV0ZW50
aSIuImRpc3RyZXR0byIgLCJmaWd1cmUiLiJncnVwcG8iICwiZmlndXJlIi4iZGF0YV9lc3Bv
cnRhemlvbmUiICwidXRlbnRpIi4iZGF0YV9lc3BvcnRhemlvbmUiICBGUk9NICJmaWd1cmUi
LCJ1dGVudGkiIFdIRVJFICgoImZpZ3VyZSIuInRpcG8iIElOICgnRCcgLCdEQicgLCdETycg
LCdEUycgKSApIEFORCAoImZpZ3VyZSIuImNvZGljZV9maWd1cmEiID0gInV0ZW50aSIuImF6
aWVuZGEiICkgKSApIFVOSU9OIEFMTCAoU0VMRUNUICJmaWd1cmUiLiJhemllbmRhIiAsImZp
Z3VyZSIuImNvZGljZV9maWd1cmEiICwidXRlbnRpIi4icmFnaW9uZV9zb2NpYWxlIiAsInV0
ZW50aSIuImlzdGF0IiAsInV0ZW50aSIuImNhcCIgLCJ1dGVudGkiLiJpbmRpcml6em8iICwi
dXRlbnRpIi4iY2l2aWNvIiAsImZpZ3VyZSIuInRpcG8iICwidXRlbnRpIi4iY29kaWNlX2Zp
c2NhbGUiICwidXRlbnRpIi4icGFydGl0YV9pdmEiICwiZmlndXJlIi4iZmluZV9hdHRpdml0
YSIgLCJmaWd1cmUiLiJkYXRhX2VzcG9ydGF6aW9uZSIgLCJmaWd1cmUiLiJkYXRhX2FnZ2lv
cm5hbWVudG8iICwidXRlbnRpIi4iZGlzdHJldHRvIiAsImZpZ3VyZSIuImdydXBwbyIgLCJm
aWd1cmUiLiJkYXRhX2VzcG9ydGF6aW9uZSIgLCJ1dGVudGkiLiJkYXRhX2VzcG9ydGF6aW9u
ZSIgIEZST00gImZpZ3VyZSIsInV0ZW50aSIgV0hFUkUgKCgiZmlndXJlIi4idGlwbyIgSU4g
KCdQJyAsJ1BCJyAsJ1BPJyAsJ1BTJyAsJ0EnICkgKSBBTkQgKCJmaWd1cmUiLiJjb2RpY2Vf
ZmlndXJhIiA9ICJ1dGVudGkiLiJhemllbmRhIiApICkgKScNCiAgICAgICAgICAgICAgICAg
ZGF0YV9hdF9leGVjPS0xLCBjdXJyZW50X2V4ZWNfcGFyYW09LTEsIHB1dF9kYXRhPTANCiAg
ICAgICAgICAgICAgICAgY3VyclR1cGxlPS0xLCBjdXJyZW50X2NvbD0tMSwgbG9ial9mZD0t
MQ0KICAgICAgICAgICAgICAgICBtYXhSb3dzPTAsIHJvd3NldF9zaXplPTEsIGtleXNldF9z
aXplPTAsIGN1cnNvcl90eXBlPTAsIHNjcm9sbF9jb25jdXJyZW5jeT0xDQogICAgICAgICAg
ICAgICAgIGN1cnNvcl9uYW1lPSdTUUxfQ1VSMDdCMDU2OTgnDQogICAgICAgICAgICAgICAg
IC0tLS0tLS0tLS0tLS0tLS1RUmVzdWx0IEluZm8gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KQ09OTiBFUlJPUjogZnVuYz1TQ19leGVjdXRlLCBkZXNjPScnLCBlcnJudW09
MTA2LCBlcnJtc2c9J1VuZXhwZWN0ZWQgcHJvdG9jb2wgY2hhcmFjdGVyIGZyb20gYmFja2Vu
ZCAoc2VuZF9xdWVyeSknDQogICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgIGhlbnY9
MTI5OTYxODgwLCBjb25uPTEyODk1MDU0NCwgc3RhdHVzPTEsIG51bV9zdG10cz0xNg0KICAg
ICAgICAgICAgc29jaz0xMjg5NDEzMTYsIHN0bXRzPTEyODk0MTM1NiwgbG9ial90eXBlPS05
OTkNCiAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0gU29ja2V0IEluZm8gLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAgc29ja2V0PTMyMCwgcmV2ZXJz
ZT0wLCBlcnJvcm51bWJlcj0wLCBlcnJvcm1zZz0nKG51bGwpJw0KICAgICAgICAgICAgYnVm
ZmVyX2luPTEyODk1Njg3MiwgYnVmZmVyX291dD0xMjg5NjA5NzINCiAgICAgICAgICAgIGJ1
ZmZlcl9maWxsZWRfaW49NDA5NiwgYnVmZmVyX2ZpbGxlZF9vdXQ9MCwgYnVmZmVyX3JlYWRf
aW49OQ0KPERFTEVURUQ+DQo=
--------------4C67C5F375F657E37C344777--
From bouncefilter Fri Jan 21 03:42:40 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA39602
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 03:42:04 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id BAA28828;
Fri, 21 Jan 2000 01:03:05 -0800 (PST)
Date: Fri, 21 Jan 2000 01:03:05 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, prlw1@cam.ac.uk,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump disaster
Message-ID: <20000121010305.K14030@fw.wintelcom.net>
References: <3456.948431421@sss.pgh.pa.us>
<200001210549.AAA13736@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200001210549.AAA13736@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Fri, Jan 21, 2000 at 12:49:34AM
-0500
* Bruce Momjian <pgman@candle.pha.pa.us> [000120 22:13] wrote:
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
Trying to load a 6 January pg_dumpall file with today's postgresql gives
many
invalid command \N
probably because
PQexec: you gotta get out of a COPY state yourself.
db.out4:11621: invalid command \.
Somehow psql is out of sync and thinks the \N isn't within a COPY block.The answer appears to be that Perlstein's "nonblocking mode" patches
have broken psql copy, and doubtless a lot of other applications as
well, because pqPutBytes no longer feels any particular compulsion
to actually send the data it's been handed. (Moreover, if it does
do only a partial send, there is no way to discover how much it sent;
while its callers might be blamed for not having checked for an error
return, they'd have no way to recover anyhow.)I thought these patches should not have been applied without more
peer review, and now I'm sure of it. I recommend reverting 'em.Can we give the submitter a few days to address the issue?
Tom is wrong in his assessment, this is exactly the reason I brought
the patches in.
pqPutBytes _never_ felt any compulsion to flush the buffer to the backend,
or at least not since I started using it. The only change I made was
for send reservations to be made for non-blocking connections, nothing
inside of postgresql uses non-blocking connections.
pqPutBytes from revision 1.33: (plus my commentary)
static int
pqPutBytes(const char *s, size_t nbytes, PGconn *conn)
{
size_t avail = Max(conn->outBufSize - conn->outCount, 0);
/* while the amount to send is greater than the output buffer */
while (nbytes > avail)
{
/* copy as much as we can into the buffer */
memcpy(conn->outBuffer + conn->outCount, s, avail);
conn->outCount += avail;
s += avail;
nbytes -= avail;
/* try to flush it.... */
if (pqFlush(conn))
return EOF;
avail = conn->outBufSize;
}
/* XXX: ok, we have enough room... where is the flush? */
memcpy(conn->outBuffer + conn->outCount, s, nbytes);
conn->outCount += nbytes;
return 0;
}
I may have introduced bugs elsewhere, but i doubt it was in pqPutBytes.
This is the exact problem I was describing and why I felt that routines
that checked for data needed to flush beforehand, there may have been
data that still needed to be sent.
I'll be reviewing my own changes again to make sure I haven't broken
something else that could be causing this.
The implications of this is trully annoying, exporting the socket to
the backend to the client application causes all sorts of problems because
the person select()'ing on the socket sees that it's 'clear' but yet
all thier data has not been sent...
-Alfred
-- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
From bouncefilter Fri Jan 21 08:31:43 2000
Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net
[137.118.22.15]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA09082
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 08:31:01 -0500 (EST)
(envelope-from mhh@nortelnetworks.com)
Received: from zrtpd004.us.nortel.com (actually zrtpd004)
by smtprtp.ntcom.nortel.net; Fri, 21 Jan 2000 08:29:48 -0500
Received: from zrtpd003.us.nortel.com ([47.140.224.137])
by zrtpd004.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id Y6961DYD; Fri, 21 Jan 2000 08:29:48 -0500
Received: from americasm01.nt.com (hrtpp28d.us.nortel.com [47.190.110.250])
by zrtpd003.us.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id DJLAHJ2Z; Fri, 21 Jan 2000 08:29:47 -0500
Message-ID: <38885FB2.5F1385E6@americasm01.nt.com>
Date: Fri, 21 Jan 2000 08:31:30 -0500
From: "Mark Hollomon" <mhh@nortelnetworks.com>
Reply-To: "Mark Hollomon" <mhh@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Building Documentation under Debian
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
If anyone cares, here is what I had to do to build the postgresql
documentation on a Debian system.
1. install jade, docbook, and unzip
apt-get install jade
apt-get install docbook
apt-get install unzip
2. grab the DSSSL stuff from http://www.nwalsh.com/docbook/dsssl
and unzip it somewhere (I chose /usr/share).
3. edit Makefile.custom to add appropriate HSTYLE and PSTYLE
definitions
HSTYLE= /usr/share/docbook/html
PSTYLE= /usr/share/docbook/print
And thats it.
--
Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008
From bouncefilter Fri Jan 21 08:46:43 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA14910
for <pgsql-hackers@postgresql.org>;
Fri, 21 Jan 2000 08:45:46 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA65312
for <pgsql-hackers@postgresql.org>;
Fri, 21 Jan 2000 09:46:03 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 21 Jan 2000 09:46:03 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Playing with UPDATEs ...
Message-ID: <Pine.BSF.4.21.0001210943200.23487-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Just curious, but shouldn't something like this be possible? Or is my
syntax just off?
update dict d, dictionary m
set d.word = m.word_val
where d.word = m.word;
I want to go through one table and replace all occurances of every word in
the second table with a numeric value ...
I've tried it as:
update dict, dictionary
set dict.word = dictionary.word_val
where dict.word = dictionary.word;
and that doesn't work either ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 21 08:51:44 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA15749
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 08:51:31 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max02-053.enterprise.net
[194.72.195.173])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id NAA18513;
Fri, 21 Jan 2000 13:51:29 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id NAA17139;
Fri, 21 Jan 2000 13:51:24 GMT
Message-Id: <200001211351.NAA17139@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: "Mark Hollomon" <mhh@nortelnetworks.com>
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
olly@linda.lfix.co.uk
Subject: Re: [HACKERS] Building Documentation under Debian
In-Reply-To: Message from "Mark Hollomon" <mhh@nortelnetworks.com> of "Fri,
21 Jan 2000 08:31:30 EST." <38885FB2.5F1385E6@americasm01.nt.com>
References: <38885FB2.5F1385E6@americasm01.nt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 21 Jan 2000 13:51:24 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
"Mark Hollomon" wrote:
If anyone cares, here is what I had to do to build the postgresql
documentation on a Debian system.
...
Thomas, don't you do some hand-tweaking after the standard build?
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"For we wrestle not against flesh and blood, but
against principalities, against powers, against the
rulers of the darkness of this world, against
spiritual wickedness in high places. Wherefore take
unto you the whole armour of God, that ye may be able
to withstand in the evil day, and having done all, to
stand." Ephesians 6:12,13
From bouncefilter Fri Jan 21 08:58:44 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA16936
for <pgsql-hackers@postgresql.org>;
Fri, 21 Jan 2000 08:58:01 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA65402;
Fri, 21 Jan 2000 09:57:06 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 21 Jan 2000 09:57:06 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, prlw1@cam.ac.uk,
pgsql-hackers@postgresql.org, bright@wintelcom.net
Subject: Re: [HACKERS] pg_dump disaster
In-Reply-To: <200001210549.AAA13736@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001210952320.23487-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 21 Jan 2000, Bruce Momjian wrote:
I thought these patches should not have been applied without more
peer review, and now I'm sure of it. I recommend reverting 'em.Can we give the submitter a few days to address the issue?
Considering that we haven't even gone BETA yet, I *heavily* second this
... Alfred, so far as I've seen, has a) spent alot of time on these
patches and b) tried to address any concerns as they've been presented
concerning them...
IMHO, if we hadn't commit'd the patches, we wouldn't have found the bug,
and getting feedback on the pathes without applying them, so far, has been
about as painful as pulling teeth ...
From what I've seen, nobody has been spending much time in libpq *anyway*,
so it isn't as if reverting them if we have to is a big issue ...
But, on the other side of hte coin ... Alfred, we need relatively quick
turnaround on fixing this, as libpq is kinda crucial :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 21 08:57:44 2000
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA16823
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 08:57:38 -0500 (EST) (envelope-from geek+@cmu.edu)
Received: from export.andrew.cmu.edu (EXPORT.ANDREW.CMU.EDU [128.2.23.2])
by smtp2.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id IAA04397
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 08:57:37 -0500 (EST)
Date: 21 Jan 2000 08:57:35 -0500
Message-ID: <emacs-smtp-15221-14472-26063-628533@export.andrew.cmu.edu>
From: Brian E Gallew <geek+@cmu.edu>
X-Mailer: BatIMail version 3.2
To: pgsql-hackers@postgreSQL.org
In-reply-to: <25387.948414692@sss.pgh.pa.us>
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
References: <25387.948414692@sss.pgh.pa.us>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/signed; protocol="application/pgp-signature";
boundary="pgp-sign-Multipart_Fri_Jan_21_08:57:34_2000-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
--pgp-sign-Multipart_Fri_Jan_21_08:57:34_2000-1
Content-Type: text/plain; charset=US-ASCII
Then <tgl@sss.pgh.pa.us> spoke up and said:
As best I can measure on my hardware, the cost of a nonsequential
disk read should be estimated at 4 to 5 times the cost of a sequential
one --- I'm getting numbers like 2.2 msec per disk page for sequential
scans, and as much as 11 msec per page for index scans. I don't
know, however, if this ratio is similar enough on other platforms
to be useful for cost estimating. We could make it a parameter like
we do for CPU_PAGE_WEIGHT ... but you know and I know that no one
ever bothers to adjust those numbers in the field ...
Here's a thought: there are tools (bonnie, ioscan) whose job is
determining details of disk performance. Do we want to look at
creating a small tool/script of our own that would (optionally)
determine the correct parameters for the system it is installed on and
update the appropriate parameters?
--
=====================================================================
| JAVA must have been developed in the wilds of West Virginia. |
| After all, why else would it support only single inheritance?? |
=====================================================================
| Finger geek@cmu.edu for my public key. |
=====================================================================
--pgp-sign-Multipart_Fri_Jan_21_08:57:34_2000-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface
iQBVAwUBOIhlz4dzVnzma+gdAQEI/wH/ZP8tLAiOU31Yfvrg3kHRx6L2WaX6VTh5
x0sB7U9NsWOdcaDgMf2KT6yyvg6SFjPY/Mj3iUqMmAGqdThvL3p9KA==
=pLaK
-----END PGP MESSAGE-----
--pgp-sign-Multipart_Fri_Jan_21_08:57:34_2000-1--
From bouncefilter Sat Jan 22 03:45:56 2000
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA40041
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 03:45:03 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9B98BB.dip0.t-ipconnect.de
(root@p3E9B98BB.dip0.t-ipconnect.de [62.155.152.187])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id JAA21544
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 09:46:30 +0100 (CET)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id PAA00378
for pgsql-hackers@postgresql.org; Fri, 21 Jan 2000 15:11:32 +0100
Date: Fri, 21 Jan 2000 15:11:32 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Types
Message-ID: <20000121151132.A372@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
libpq gives back the internal typenumbers of the attributes. How do I know
which number means which type? I need to find out if the type is an array.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Fri Jan 21 09:13:43 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA23390
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 09:13:14 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id KAA65490;
Fri, 21 Jan 2000 10:12:26 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 21 Jan 2000 10:12:26 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
In-Reply-To: <200001210248.VAA07186@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001211011130.23487-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 20 Jan 2000, Bruce Momjian wrote:
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
I've wondered why we cound't analyze database without vacuum.
We couldn't run vacuum light-heartedly because it acquires an
exclusive lock for the target table.There is probably no real good reason, except backwards compatibility,
why the ANALYZE function (obtaining pg_statistic data) is part of
VACUUM at all --- it could just as easily be a separate command that
would only use read access on the database. Bruce is thinking about
restructuring VACUUM, so maybe now is a good time to think about
splitting out the ANALYZE code too.I put it in vacuum because at the time I didn't know how to do such
things and vacuum already scanned the table. I just linked on the the
scan. Seemed like a good idea at the time.It is nice that ANALYZE is done during vacuum. I can't imagine why you
would want to do an analyze without adding a vacuum to it. I guess
that's why I made them the same command.
Hrmmm...how about making ANALYZE a seperate function, while a VACUUM does
an ANALYZE implicitly?
Then again, whatever happened with the work that was being done to make
VACUUM either non-locking *or*, at least, lock only the table being
vacuum'd?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 21 09:06:43 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA22107
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 09:06:30 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA31526;
Fri, 21 Jan 2000 14:14:36 GMT
Sender: lockhart@hub.org
Message-ID: <388869CC.580278C1@alumni.caltech.edu>
Date: Fri, 21 Jan 2000 14:14:36 +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: Michael Robinson <robinson@netrinsics.com>,
Bruce Momjian <maillist@candle.pha.pa.us>
CC: pauls@caemrad.com.au, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] timezone problem?
References: <200001210839.QAA01497@netrinsics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Yes, and even worse, CST also is "China Standard Time" in some operating
systems. I won't go into how broken every operating system is vis-a-vis
Chinese timezones (but, believe me, it's a mess).From here on out, I'm strictly in "+0800".
I've become convinced that any project that thinks it is going to keep
comprehensive, accurate, non-conflicting, non-obsolete timezone information
in an application-specific table is woefully misguided.
Yup. And that brings up an issue: I would like to have the *default*
style for date/time output in 7.0 be ISO, rather than the current
"traditional Postgres". I was waiting for a major rev to do this (but
it probably should have happened before the y2k change of year). It's
a one-liner to update this.
Bruce, can you add this to the "critical items" for 7.0, barring fatal
objections from other developers?
btw, the patch also tries to fix the "GMT+hhmm" timezone format
reported recently as being available on FreeBSD; perhaps someone could
test that at the same time.Does this patch apply cleanly against 6.5.3?
I'm not certain, but it should since this area of the code does not
change very much. If you apply with
cd src/backend/utils/adt
patch < dt.c.patch
you should get a dt.c.orig so can revert easily if necessary.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 21 09:53:44 2000
Received: from [12.6.225.3] ([12.6.225.3])
by hub.org (8.9.3/8.9.3) with SMTP id JAA33420
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 09:52:48 -0500 (EST)
(envelope-from rdavis@lillysoftware.com)
Received: from lillysoftware.com by [12.6.225.3]
via smtpd (for postgresql.org [216.126.84.28]) with SMTP;
21 Jan 2000 14:51:18 UT
Received: from lillysoftware.com (BOBIBM333 [173.100.2.237]) by
ponyexpress.LillySoftware.com with SMTP (Microsoft Exchange
Internet Mail Service Version 5.5.2448.0)
id D1RCYHBA; Fri, 21 Jan 2000 09:50:29 -0500
Message-ID: <388872B7.EE46009A@lillysoftware.com>
Date: Fri, 21 Jan 2000 09:52:39 -0500
From: Robert Davis <rdavis@lillysoftware.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] off topic
References: <Pine.LNX.4.21.0001201910480.349-100000@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Thanks for all the responses.
I really have the heart of doing this all the time but I dont have the will.
I have 3 kids and a wife and I enjoy boating, hiking etc. I just cant seem to find the extra time. I like the idea of convincing work to let me work on projects like this.
I was surprised that nobody fit into category 5.
I assumed you were all young kids w/o wife and kids and could spend all your free time on this. ;-)
Actually I think about doing something like this when I make my first million and retire.
thanks again
bob
Peter Eisentraut wrote:
It's a learning experience. This project touches all the interesting
aspects of computer science at once.Also, I have no life, of course.
On 2000-01-20, Robert Davis mentioned:
I know this is off topic but...
How do the programmers here get paid?
1. You do this in your spare time and dont get paid.
2. Your day job encourages you to spend some of your time developing the db that your company uses.
3. There is an organization that accepts money and distributes it to the hackers.
4. You are all independently wealthy and do this for the fun of it.
5. You are still living at home with mom and expect one day to get a real job from this.Seriously
My friend and I were talking about the open software movement and how great it is and he keeps on asking how people like us get paid.
Basically my friend and me are the type that like to stay home and not visit customers and just solve problems and write code. Probably a lot like all of you.thanks
bob--
rdavis@lillysoftware.com
rsdavis@mediaone.net
http://people.ne.mediaone.net/rsdavis************
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
--
rdavis@lillysoftware.com
rsdavis@mediaone.net
http://people.ne.mediaone.net/rsdavis
From bouncefilter Fri Jan 21 10:03:45 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA38797;
Fri, 21 Jan 2000 10:03:16 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA01869;
Fri, 21 Jan 2000 10:03:07 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001211503.KAA01869@candle.pha.pa.us>
Subject: Re: [HACKERS] off topic
In-Reply-To: <20000121083507.A426@fam-meskes.de> from Michael Meskes at "Jan
21, 2000 08:35:07 am"
To: Michael Meskes <meskes@postgreSQL.org>
Date: Fri, 21 Jan 2000 10:03:07 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Thu, Jan 20, 2000 at 01:56:49PM -0500, Bruce Momjian wrote:
I think we are all insane, or very sane. Not sure which.
Ask my wife and she surely says the former. :-)
The book helped my wife see some value in this. "Gee, I don't know
anyone who wrote a book", she said.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 21 10:00:44 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA34825
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 10:00:13 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA31603;
Fri, 21 Jan 2000 15:06:40 GMT
Sender: lockhart@hub.org
Message-ID: <38887600.E560D422@alumni.caltech.edu>
Date: Fri, 21 Jan 2000 15:06:40 +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: Mark Hollomon <mhh@nortelnetworks.com>
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Building Documentation under Debian
References: <38885FB2.5F1385E6@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mark Hollomon wrote:
If anyone cares, here is what I had to do to build the postgresql
documentation on a Debian system.
Thanks. I've added a section on Debian to the "Doc Guide" appendix.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 21 10:31:44 2000
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 KAA47433
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 10:31:10 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA02185;
Fri, 21 Jan 2000 10:11:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001211511.KAA02185@candle.pha.pa.us>
Subject: Re: Status on 7.0
In-Reply-To: <38881B27.482D8D97@debis.com> from Jan Wieck at "Jan 21,
2000 09:39:03 am"
To: Jan Wieck <wieck@debis.com>
Date: Fri, 21 Jan 2000 10:11:26 -0500 (EST)
CC: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>,
Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I know now that I have to do all the missing FOREIGN KEY stuff
myself. And thats not the file buffering alone. We cannot ship
FOREIGN KEY if pg_dump cannot handle it.Up to now, nothing I did for TOAST changed anything visible. So it
has to wait for FK.Currently, I'm a little busy, so I don't expect TOAST for 7.0
anymore - sorry.
That's fine. Better to say it now and take the pressure of yourself.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 21 10:04:44 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA39069
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 10:04:20 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA31617;
Fri, 21 Jan 2000 15:12:48 GMT
Sender: lockhart@hub.org
Message-ID: <38887770.B2CB2E2F@alumni.caltech.edu>
Date: Fri, 21 Jan 2000 15:12: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: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Playing with UPDATEs ...
References: <Pine.BSF.4.21.0001210943200.23487-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
update dict
set word = m.word_val
from dictionary m
where dict.word = m.word;
I want to go through one table and replace all occurances of every word in
the second table with a numeric value ...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 21 10:12:44 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA40841
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 10:12:30 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA31628;
Fri, 21 Jan 2000 15:16:39 GMT
Sender: lockhart@hub.org
Message-ID: <38887857.617F446@alumni.caltech.edu>
Date: Fri, 21 Jan 2000 15:16:39 +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: Oliver Elphick <olly@lfix.co.uk>
CC: Mark Hollomon <mhh@nortelnetworks.com>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>,
olly@linda.lfix.co.uk
Subject: Re: [HACKERS] Building Documentation under Debian
References: <38885FB2.5F1385E6@americasm01.nt.com>
<200001211351.NAA17139@linda.lfix.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
If anyone cares, here is what I had to do to build the postgresql
documentation on a Debian system.Thomas, don't you do some hand-tweaking after the standard build?
For hardcopy, yes, to spiff up the page breaks and get the page
numbering right. But nothing gets tweaked for html...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 21 10:31:45 2000
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 KAA47871
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 10:31:32 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA02428;
Fri, 21 Jan 2000 10:18:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001211518.KAA02428@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_dump disaster
In-Reply-To: <Pine.BSF.4.21.0001210952320.23487-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 21, 2000 09:57:06 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Fri, 21 Jan 2000 10:18:02 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, prlw1@cam.ac.uk,
pgsql-hackers@postgreSQL.org, bright@wintelcom.net
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Fri, 21 Jan 2000, Bruce Momjian wrote:
I thought these patches should not have been applied without more
peer review, and now I'm sure of it. I recommend reverting 'em.Can we give the submitter a few days to address the issue?
Considering that we haven't even gone BETA yet, I *heavily* second this
... Alfred, so far as I've seen, has a) spent alot of time on these
patches and b) tried to address any concerns as they've been presented
concerning them...IMHO, if we hadn't commit'd the patches, we wouldn't have found the bug,
and getting feedback on the pathes without applying them, so far, has been
about as painful as pulling teeth ...
Yes, he has worked very hard on this. That's why I want to give him
some time to address the issues. In fact, he already has replied, and I
am sure a dialog will resolve the issue.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 21 10:26:44 2000
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 KAA44323
for <hackers@postgreSQL.org>; Fri, 21 Jan 2000 10:25:47 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id AAA27118;
Sat, 22 Jan 2000 00:25:44 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id AAA16964;
Sat, 22 Jan 2000 00:25:44 +0900
To: vadim@krs.ru
Cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Well...
In-Reply-To: Your message of "Wed, 19 Jan 2000 11:57:22 +0700"
<38854432.54EE2F01@krs.ru>
References: <38854432.54EE2F01@krs.ru>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000122002543Q.t-ishii@sra.co.jp>
Date: Sat, 22 Jan 2000 00:25:43 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 10
I hope to get H1B visa Feb 4 and leave for
San-Francisco on Feb 6...
I'll be in Krasnoyarsk till Feb 2.
That means you are going to spend 2 or 3 months in US, then come back
in April or May? I just think it would be really nice if you could
stop over Japan...
--
Tatsuo Ishii
From bouncefilter Fri Jan 21 10:44:46 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA56445
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 10:44:16 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA04773;
Fri, 21 Jan 2000 10:44:03 -0500 (EST)
To: Alfred Perlstein <bright@wintelcom.net>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, prlw1@cam.ac.uk,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump disaster
In-reply-to: <20000121010305.K14030@fw.wintelcom.net>
References: <3456.948431421@sss.pgh.pa.us>
<200001210549.AAA13736@candle.pha.pa.us>
<20000121010305.K14030@fw.wintelcom.net>
Comments: In-reply-to Alfred Perlstein <bright@wintelcom.net>
message dated "Fri, 21 Jan 2000 01:03:05 -0800"
Date: Fri, 21 Jan 2000 10:44:02 -0500
Message-ID: <4769.948469442@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Alfred Perlstein <bright@wintelcom.net> writes:
The answer appears to be that Perlstein's "nonblocking mode" patches
have broken psql copy, and doubtless a lot of other applications as
well, because pqPutBytes no longer feels any particular compulsion
to actually send the data it's been handed. (Moreover, if it does
do only a partial send, there is no way to discover how much it sent;
while its callers might be blamed for not having checked for an error
return, they'd have no way to recover anyhow.)
pqPutBytes _never_ felt any compulsion to flush the buffer to the backend,
or at least not since I started using it.
Sorry, I was insufficiently careful about my wording. It's true that
pqPutBytes doesn't worry about actually flushing the data out to the
backend. (It shouldn't, either, since it is typically called with small
fragments of a message rather than complete messages.) It did, however,
take care to *accept* all the data it was given and ensure that the data
was queued in the output buffer. As the code now stands, it's
impossible to tell whether all the passed data was queued or not, or how
much of it was queued. This is a fundamental design error, because the
caller has no way to discover what to do after a failure return (nor
even a way to tell if it was a hard failure or just I-won't-block).
Moreover, no existing caller of PQputline thinks it should have to worry
about looping around the call, so even if you put in a usable return
convention, existing apps would still be broken.
Similarly, PQendcopy is now willing to return without having gotten
the library out of the COPY state, but the caller can't easily tell
what to do about it --- nor do existing callers believe that they
should have to do anything about it.
The implications of this is trully annoying, exporting the socket to
the backend to the client application causes all sorts of problems because
the person select()'ing on the socket sees that it's 'clear' but yet
all thier data has not been sent...
Yeah, the original set of exported routines was designed without any
thought of handling a nonblock mode. But you aren't going to be able
to fix them this way. There will need to be a new set of entry points
that add a concept of "operation not complete" to their API, and apps
that want to avoid blocking will need to call those instead. Compare
what's been done for connecting (PQconnectPoll) and COPY TO STDOUT
(PQgetlineAsync).
It's possible that things were broken before you got to them --- there
have been several sets of not-very-carefully-reviewed patches to libpq
during the current development cycle, so someone else may have created
the seeds of the problem. However, we weren't seeing failures in psql
before this week...
regards, tom lane
From bouncefilter Fri Jan 21 11:49:46 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA76594
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 11:49:01 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id IAA00225;
Fri, 21 Jan 2000 08:47:26 -0800 (PST)
Message-Id: <3.0.1.32.20000121081044.01036290@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 21 Jan 2000 08:10:44 -0800
To: xun@cs.ucsb.edu, pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: Re. [HACKERS] Some notes on optimizer cost estimates
In-Reply-To: <200001210219.SAA22377@xp10-06.dialup.commserv.ucsb.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 06:19 PM 1/20/00 -0800, Xun Cheng wrote:
I'm very glad you bring up this cost estimate issue.
Recent work in database research have argued a more
detailed disk access cost model should be used for
large queries especially joins.
Traditional cost estimate only considers the number of
disk pages accessed. However a more detailed model
would consider three parameters: avg. seek, avg. latency
and avg. page transfer. For old disk, typical values are
SEEK=9.5 milliseconds, LATENCY=8.3 ms, TRANSFER=2.6ms.
A sequential continuous reading of a table (assuming
1000 continuous pages) would cost
(SEEK+LATENCY+1000*TRANFER=2617.8ms); while quasi-randomly
reading 200 times with 2 continuous pages/time would
cost (SEEK+200*LATENCY+400*TRANSFER=2700ms).
Someone from IBM lab re-studied the traditional
ad hoc join algorithms (nested, sort-merge, hash) using the detailed cost
model
and found some interesting results.
One complication when doing an index scan is that you are
accessing two separate files (table and index), which can frequently
be expected to cause an considerable increase in average seek time.
Oracle and other commercial databases recommend spreading indices and
tables over several spindles if at all possible in order to minimize
this effect.
I suspect it also helps their optimizer make decisions that are
more consistently good for customers with the largest and most
complex databases and queries, by making cost estimates more predictably
reasonable.
Still...this doesn't help with the question about the effect of the
filesystem system cache. I wandered around the web for a little bit
last night, and found one summary of a paper by Osterhout on the
effect of the Solaris cache on a fileserver serving diskless workstations.
There was reference to the hierarchy involved (i.e. the local workstation
cache is faster than the fileserver's cache which has to be read via
the network which in turn is faster than reading from the fileserver's
disk). It appears the rule-of-thumb for the cache-hit ratio on reads,
presumably based on measuring some internal Sun systems, used in their
calculations was 80%.
Just a datapoint to think about.
There's also considerable operating system theory on paging systems
that might be useful for thinking about trying to estimate the
Postgres cache/hit ratio. Then again, maybe Postgres could just
keep count of how many pages of a given table are in the cache at
any given time? Or simply keep track of the current ratio of hits
and misses?
I have been spending some time measuring actual runtimes for various
sequential-scan and index-scan query plans, and have learned that the
current Postgres optimizer's cost estimation equations are not very
close to reality at all.
One interesting question I'd like to ask is if this non-closeness
really affects the optimal choice of postgresql's query optimizer.
And to what degree the effects might be? My point is that
if the optimizer estimated the cost for sequential-scan is 10 and
the cost for index-scan is 20 while the actual costs are 10 vs. 40,
it should be ok because the optimizer would still choose sequential-scan
as it should.
This is crucial, of course - if there are only two types of scans
available, what ever heuristic is used only has to be accurate enough
to pick the right one. Once the choice is made, it doesn't really
matter (from the optimizer's POV) just how long it will actually take,
the time will be spent and presumably it will be shorter than the
alternative.
How frequently will the optimizer choose wrongly if:
1. All of the tables and indices were in PG buffer cache or filesystem
cache? (i.e. fixed access times for both types of scans)
or
2. The table's so big that only a small fraction can reside in RAM
during the scan and join, which means that the non-sequential
disk access pattern of the indexed scan is much more expensive.
Also, if you pick sequential scans more frequently based on a presumption
that index scans are expensive due to increased average seek time, how
often will this penalize the heavy-duty user that invests in extra
drives and lots of RAM?
...
The current cost estimation
method essentially assumes that the buffer cache plus OS disk cache will
be 100% efficient --- we will never have to read the same page of the
main table twice in a scan, due to having discarded it between
references. This of course is unreasonably optimistic. Worst case
is that we'd fetch a main-table page for each selected tuple, but in
most cases that'd be unreasonably pessimistic.This is actually the motivation that I asked before if postgresql
has a raw disk facility. That way we have much control on this cache
issue. Of course only if we can provide some algo. better than OS
cache algo. (depending on the context, like large joins), a raw disk
facility will be worthwhile (besides the recoverability).
Postgres does have control over its buffer cache. The one thing that
raw disk I/O would give you is control over where blocks are placed,
meaning you could more accurately model the cost of retrieving them.
So presumably the cache could be tuned to the allocation algorithm
used to place various structures on the disk.
I still wonder just how much gain you get by this approach. Compared,
to, say simply spending $2,000 on a gigabyte of RAM. Heck, PCs even
support a couple gigs of RAM now.
Actually I have another question for you guys which is somehow related
to this cost estimation issue. You know the difference between OLTP
and OLAP. My question is how you target postgresql on both kinds
of applications or just OLTP. From what I know OLTP and OLAP would
have a big difference in query characteristics and thus
optimization difference. If postgresql is only targeted on
OLTP, the above cost estimation issue might not be that
important. However for OLAP, large tables and large queries are
common and optimization would be difficult.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Fri Jan 21 11:12:45 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA64927
for <hackers@postgresql.org>; Fri, 21 Jan 2000 11:11:58 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA31773;
Fri, 21 Jan 2000 16:19:36 GMT
Sender: lockhart@hub.org
Message-ID: <38888718.E45F31C4@alumni.caltech.edu>
Date: Fri, 21 Jan 2000 16:19:36 +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: "gary.wolfe" <gary.wolfe@biosourcetechnologies.com>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: memory leak????
References: <38887ECC.DDE7445D@biosourcetechnologies.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I am getting an error: FATAL 1: Memory exausted in allocSetAlloc().
(taken on-list)
I get this when I do the attached command. The table definition is the
second attachment. When I did the select statement, I only had 200 or so
lines in the table. I was doing the select command in both psql and libpq.
This is known and expected behavior, though certainly undesirable for
your query. I don't know much about it, but I'll guess that you are
exhausting memory just trying to *plan* the query, or that the
bazillion intermediate results from the huge number of "or" clauses is
chewing things up.
I would try two things (again, I'm not recalling all I should here):
1) Do an "explain" on your query. If it fails, set Postgres to use the
genetic optimizer (SET GEQO ON;)
2) Ask on the hackers mailing list. Perhaps there is a way to clear
memory from intermediate results (or a better workaround). I'm
guessing that there is for multiple statements within a transaction,
but maybe not within a single query. The hackers mailing list archives
might have some details on this.
Good luck.
- Thomas
----------------------------------------------------------------------
select seqid, barcode, run from sequence where (seqid=28904 and phredsum=170) or (seqid=28907 and phredsum=48) or (seqid=28912 and phredsum=212) or (seqid=28923 and phredsum=124) or (seqid=28924 and phredsum=224) or (seqid=28928 and phredsum=52) or (seqid=28929 and phredsum=176) or (seqid=28930 and phredsum=197) or (seqid=28931 and phredsum=184) or (seqid=28932 and phredsum=169) or (seqid=28936 and phredsum=274) or (seqid=28937 and phredsum=165) or (seqid=28938 and phredsum=297) or (seqid=28939 and phredsum=172) or (seqid=28942 and phredsum=162) or (seqid=28943 and phredsum=211) or (seqid=28944 and phredsum=246) or (seqid=28945 and phredsum=259) or (seqid=28946 and phredsum=357) or (seqid=28947 and phredsum=295) or (seqid=28955 and phredsum=239) or (seqid=28956 and phredsum=129) or (seqid=28958 and phredsum=13) or (seqid=28959 and phredsum=263) or (seqid=28960 and phredsum=171) or (seqid=28962 and phredsum=46) or (seqid=28963 and phredsum=297) or (seqid=28964 and phredsum=17!
7) or (seqid=28965 and phredsum=97) or (seqid=28967 and phredsum=143) or (seqid=28968 and phredsum=109) or (seqid=28969 and phredsum=233) or (seqid=28976 and phredsum=76);
---------------------------------------------------------------------- +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ | seqid | int4 not null | 4 | | barcode | int4 not null | 4 | | run | int2 not null | 2 | | sequence | text | var | | quality | text | var | | length | int2 | 2 | | seqtime | datetime | 8 | | geltype | text | var | | phredsum | int2 | 2 | | identifier | int4 not null default nextval ( | 4 | +----------------------------------+----------------------------------+-------+ Indices: phredsum_ind seqid_ind sequence_pkey
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 21 11:23:45 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id LAA67503
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 11:23:41 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 13219 invoked by uid 1001); 21 Jan 2000 16:23:40 -0000
Message-ID: <XFMail.000121112340.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <3887EE8C.5A2E0044@alumni.caltech.edu>
Date: Fri, 21 Jan 2000 11:23:40 -0500 (EST)
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: Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] timezone problem?
Cc: pgsql-hackers@postgreSQL.org, tgl@sss.pgh.pa.us,
Tatsuo Ishii <t-ishii@sra.co.jp>
On 21-Jan-00 Thomas Lockhart wrote:
In /usr/share/zoneinfo/US, the mysteries of the various states'
conventions are revealed:[root@golem zoneinfo]# ls -1 US
Alaska
Aleutian
Arizona
Central
East-Indiana
Eastern
Hawaii
Indiana-Starke
Michigan
Mountain
Pacific
Samoawhere, as Vince pointed out, Indiana, Michigan, and Arizona seem to be
special cases within the usual three timezones.
Michigan isn't a special case. We're EST5EDT, I never did figure out why
we're listed in there. Perhaps we were among the first to fully implement
DST? I know I remember we were doing it in a test case long before it went
on the ballot in the state (which was controversial in itself).
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Fri Jan 21 11:32:45 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA73245
for <hackers@postgreSQL.org>; Fri, 21 Jan 2000 11:32:17 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA04970;
Fri, 21 Jan 2000 11:30:55 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: "gary.wolfe" <gary.wolfe@biosourcetechnologies.com>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: memory leak????
In-reply-to: <38888718.E45F31C4@alumni.caltech.edu>
References: <38887ECC.DDE7445D@biosourcetechnologies.com>
<38888718.E45F31C4@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Fri, 21 Jan 2000 16:19:36 +0000"
Date: Fri, 21 Jan 2000 11:30:54 -0500
Message-ID: <4967.948472254@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
... I don't know much about it, but I'll guess that you are
exhausting memory just trying to *plan* the query, or that the
bazillion intermediate results from the huge number of "or" clauses is
chewing things up.
SET KSQO = 'ON' might help. I've reduced cnfify's tendence to eat
memory when presented with a big OR-of-ANDs clause, but that fix isn't
in 6.5.* (it still needs more work).
regards, tom lane
From bouncefilter Fri Jan 21 11:50:45 2000
Received: from genomics1.biosourcetechnologies.com ([209.179.110.105])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA76841
for <hackers@postgreSQL.org>; Fri, 21 Jan 2000 11:50:07 -0500 (EST)
(envelope-from gary.wolfe@biosourcetechnologies.com)
Received: from biosourcetechnologies.com (vaca2 [10.0.0.12]) by
genomics1.biosourcetechnologies.com with SMTP (Microsoft
Exchange Internet Mail Service Version 5.5.2448.0)
id C9Y0AB3V; Fri, 21 Jan 2000 08:40:59 -0800
Sender: gwolfe
Message-ID: <38888E33.43B9FCC9@biosourcetechnologies.com>
Date: Fri, 21 Jan 2000 08:49:55 -0800
From: "gary.wolfe" <gary.wolfe@biosourcetechnologies.com>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: memory leak????
References: <38887ECC.DDE7445D@biosourcetechnologies.com>
<38888718.E45F31C4@alumni.caltech.edu>
<4967.948472254@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
... I don't know much about it, but I'll guess that you are
exhausting memory just trying to *plan* the query, or that the
bazillion intermediate results from the huge number of "or" clauses is
chewing things up.
The problem can also be solved by doing SELECT UNION SELCT
for each "or" clause. This is only a cute fix, it does not solve the
problemof multiple "or" "and" statements.
Gary
From bouncefilter Fri Jan 21 12:52:48 2000
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 MAA95720
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 12:52:39 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA12106;
Fri, 21 Jan 2000 12:51:53 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001211751.MAA12106@candle.pha.pa.us>
Subject: Re: vacuum timings
In-Reply-To: <3641.948433911@sss.pgh.pa.us> from Tom Lane at "Jan 21,
2000 00:51:51 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 21 Jan 2000 12:51:53 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I loaded 10,000,000 rows into CREATE TABLE test (x INTEGER); Table is
400MB and index is 160MB.With index on the single in4 column, I got:
78 seconds for a vacuum
121 seconds for vacuum after deleting a single row
662 seconds for vacuum after deleting the entire tableWith no index, I got:
43 seconds for a vacuum
43 seconds for vacuum after deleting a single row
43 seconds for vacuum after deleting the entire tableI find this quite interesting.
How long does it take to create the index on your setup --- ie,
if vacuum did a drop/create index, would it be competitive?
OK, new timings with -F enabled:
index no index
519 same load
247 " first vacuum
40 " other vacuums
1222 X index creation
90 X first vacuum
80 X other vacuums
<1 90 delete one row
121 38 vacuum after delete 1 row
346 344 delete all rows
440 44 first vacuum
20 <1 other vacuums(index is still same size)
Conclusions:
o indexes never get smaller
o drop/recreate index is slower than vacuum of indexes
What other conclusions can be made?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 21 13:09:46 2000
Received: from cherry.infoplease.com (cherry.infoplease.com [208.222.166.5])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA02304
for <hackers@postgreSQL.org>; Fri, 21 Jan 2000 13:09:32 -0500 (EST)
(envelope-from kdebisschop@infoplease.com)
Received: from infoplease.com (skillet.infoplease.com [10.0.1.212]) by
cherry.infoplease.com with SMTP (Microsoft Exchange Internet
Mail Service Version 5.5.2650.21)
id C5CJ5D8W; Fri, 21 Jan 2000 13:09:28 -0500
Sender: kdebisschop
Message-ID: <3888A0BC.9D781EB4@infoplease.com>
Date: Fri, 21 Jan 2000 13:09:00 -0500
From: Karl DeBisschop <kdebisschop@infoplease.com>
Reply-To: kdebisschop@range.infoplease.com
Organization: Information Please, LLC
X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgreSQL.org
Subject: RE: Unable to create tables...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
------------------------------------------------------------------------
Unable to create tables...
------------------------------------------------------------------------
* From: Don Baccus <dhogaza@pacifier.com>
* To: Postgres Hackers List <hackers@postgreSQL.org>
* Subject: Unable to create tables...
* Date: Fri, 06 Aug 1999 09:42:28 -0700------------------------------------------------------------------------
I mentioned this earlier in the context of pg_dump, which fails
trying to create the table "pgdump_oid".After a bit, a memory jog reminded me that I've seen this
before, with the table "foo", which I once used for testing.After a fair number of "create/drop" cycles, making then
dropping tables for testing, pgsql now refuses to let me
"create table foo...", giving the same simple error message
"can't create foo" as pg_dump's getting on pgdump_oid.I can't "drop table foo", getting an error message telling
me the class doesn't exist, so that's not the problem.I CAN create/drop other tables, i.e. "create table bar..."
followed by "drop table bar" works fine.So it doesn't appear to be a general permissions problem,
i.e. it's not as though the system thinks I don't have
create table rights.It would seem as some system table is being corrupted???
Does this sound at all familiar?
Unfortunately, I don't know how to reproduce this other
than create/drop tables until eventually it fails. As
I mentioned in my first note, pg_dump has been running
nightly on this database for weeks, at least, with no
errors reported. Suddenly - poof! can't create pgdump_oid.- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
Well, this is a very old post, but I may have part of an answer.
I'm using 6.5.3 on linux (redhat 6.0).
I had a similar or identical problem. I could not dump a table with
oids. The error message was something like "cannot create table -
relation pgdump_oid already exists.
But looking at the system table showed that it was nowhere to be found.
And since it couldn't be found, when I tried to drop it, it told me it
did not exist.
So i vacuumed (even though it's done nightly).
I found errors like:
NOTICE: Index pg_class_relname_index: NUMBER OF INDEX' TUPLES (84) IS
NOT THE SAME AS HEAP' (83)
NOTICE: Index pg_class_oid_index: NUMBER OF INDEX' TUPLES (84) IS NOT
THE SAME AS HEAP' (83)
VACUUM
There were 4 the first time i vacuumed, but subsequent vacuums showed
only these 2.
So I tried dropping and rebuilding the indexes - can't do that for
system indexes.
I was about to give up and post for help. But on a lark, I tried to
dump pgdump_oid again. This time it worked.
Hopefully this is a rare problem. And I don't know if this will work in
all situations where the above symtoms are found. But it worked for me,
so I thought I'd post it in case anyone else search the archives for
advice on this sort of problem.
--
Karl DeBisschop <kdebisschop@alert.infoplease.com>
617.832.0332 (Fax: 617.956.2696)
Information Please - your source for FREE online reference
http://www.infoplease.com - Your Ultimate Fact Finder
http://kids.infoplease.com - The Great Homework Helper
Netsaint Plugins Development
http://netsaintplug.sourceforge.net
From bouncefilter Fri Jan 21 13:47:47 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA12244
for <pgsql-hackers@postgresql.org>;
Fri, 21 Jan 2000 13:47:20 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id OAA68289;
Fri, 21 Jan 2000 14:45:35 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 21 Jan 2000 14:45:34 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: vacuum timings
In-Reply-To: <200001211751.MAA12106@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001211443480.23487-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 21 Jan 2000, Bruce Momjian wrote:
OK, new timings with -F enabled:
index no index
519 same load
247 " first vacuum
40 " other vacuums1222 X index creation
90 X first vacuum
80 X other vacuums<1 90 delete one row
121 38 vacuum after delete 1 row346 344 delete all rows
440 44 first vacuum
20 <1 other vacuums(index is still same size)Conclusions:
o indexes never get smaller
this one, I thought, was a known? if I remember right, Vadim changed it
so that space was reused, but index never shrunk in size ... no?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 21 14:05:47 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA19054
for <hackers@postgreSQL.org>; Fri, 21 Jan 2000 14:04:59 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id OAA16455;
Fri, 21 Jan 2000 14:03:15 -0500 (EST)
To: "gary.wolfe" <gary.wolfe@biosourcetechnologies.com>
cc: hackers@postgreSQL.org
Subject: Re: set command
In-reply-to: <38889AD0.2232B817@biosourcetechnologies.com>
References: <38889AD0.2232B817@biosourcetechnologies.com>
Comments: In-reply-to "gary.wolfe" <gary.wolfe@biosourcetechnologies.com>
message dated "Fri, 21 Jan 2000 09:43:44 -0800"
Date: Fri, 21 Jan 2000 14:03:15 -0500
Message-ID: <16452.948481395@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"gary.wolfe" <gary.wolfe@biosourcetechnologies.com> writes:
Are there any disadvantages to having KSQO='on' instead
of the default value of "OFF"
Other than it being a kluge, you mean ;-) ?
Basically it rewrites queries with long strings of ORs into SELECT UNION
SELECT queries, which the optimizer can cope with a little better.
Unfortunately the semantics aren't really quite the same, since UNION
implies a DISTINCT pass over the output --- the UNION form will never
emit two identical rows, whereas the original query would have if there
were identical input rows.
I'm hoping to get rid of KSQO soon by upgrading the optimizer to
the point where it doesn't choke on big ORs. In the meantime, though,
you really don't have much choice if your application requires queries
with lots of ORs.
regards, tom lane
From bouncefilter Fri Jan 21 14:06:47 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA19316
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 14:06:44 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id OAA16501;
Fri, 21 Jan 2000 14:06:31 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: vacuum timings
In-reply-to: <200001211751.MAA12106@candle.pha.pa.us>
References: <200001211751.MAA12106@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Fri, 21 Jan 2000 12:51:53 -0500"
Date: Fri, 21 Jan 2000 14:06:31 -0500
Message-ID: <16498.948481591@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Conclusions:
o indexes never get smaller
Which we knew...
o drop/recreate index is slower than vacuum of indexes
Quite a few people have reported finding the opposite in practice.
You should probably try vacuuming after deleting or updating some
fraction of the rows, rather than just the all or none cases.
regards, tom lane
From bouncefilter Fri Jan 21 14:07:48 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA19417
for <pgsql-hackers@postgresql.org>;
Fri, 21 Jan 2000 14:07:06 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12BjOp-000500-00; Fri, 21 Jan 2000 19:07:11 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12BjOd-0004hu-00; Fri, 21 Jan 2000 19:06:59 +0000
Date: Fri, 21 Jan 2000 19:06:59 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>, prlw1@cam.ac.uk,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [GENERAL] Variable case database names
Message-ID: <20000121190659.D18047@quartz.newn.cam.ac.uk>
References: <Pine.LNX.4.21.0001202242260.349-100000@localhost.localdomain>
<200001202204.RAA20758@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <200001202204.RAA20758@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Thu, Jan 20, 2000 at 05:04:45PM
-0500
On Thu, Jan 20, 2000 at 05:04:45PM -0500, Bruce Momjian wrote:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
There is some code in libpq which converts all database names to
lower-case, unless it's double quoted. That seems a little ill-conceived
to me, since you'd actually have to pass it something like
PGconnectdb("dbname=\"Newnham\"");If anything, this would make it inconvenient it psql, because you'd have
to write
\c '"Newnham"'
since
\c "Newnham"
is interpreted differently.Does anyone have an explanation for this? Why not leave the name as is?
We do the same thing with queries, right? We force identifiers to lower
case unless quoted.
The point was: the database name was quoted. I didn't think to quote it
a second time. (single quoting for the create was sufficient, and the export
from access didn't mind about the case)
Cheers,
Patrick
From bouncefilter Fri Jan 21 14:51:47 2000
Received: from relay.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA33590
for <pgsql-hackers@postgresql.org>;
Fri, 21 Jan 2000 14:51:38 -0500 (EST) (envelope-from dms@wplus.net)
X-Real-To: pgsql-hackers@postgresql.org
Received: from wplus.net (ppdms.dialup.wplus.net [195.131.52.71])
by relay.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id WAA89451;
Fri, 21 Jan 2000 22:46:19 +0300 (MSK)
Message-ID: <3888B822.28F79A1F@wplus.net>
Date: Fri, 21 Jan 2000 22:48:50 +0300
From: Dmitry Samersoff <dms@wplus.net>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: ru,en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: vacuum timings
References: <200001211751.MAA12106@candle.pha.pa.us>
<16498.948481591@sss.pgh.pa.us>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Conclusions:
o indexes never get smallerWhich we knew...
o drop/recreate index is slower than vacuum of indexes
Quite a few people have reported finding the opposite in practice.
I'm one of them. On 1,5 GB table with three indices it about twice
slowly.
Probably becouse vacuuming indices brakes system cache policy.
(FreeBSD 3.3)
--
Dmitry Samersoff, DM\S
dms@wplus.net http://devnull.wplus.net
* there will come soft rains
From bouncefilter Fri Jan 21 14:56:47 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA34255
for <pgsql-hackers@postgresql.org>;
Fri, 21 Jan 2000 14:56:18 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA15772;
Fri, 21 Jan 2000 14:54:22 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001211954.OAA15772@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: vacuum timings
In-Reply-To: <3888B822.28F79A1F@wplus.net> from Dmitry Samersoff at "Jan 21,
2000 10:48:50 pm"
To: Dmitry Samersoff <dms@wplus.net>
Date: Fri, 21 Jan 2000 14:54:21 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset koi8-r unsupported, filtering to ASCII...]
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Conclusions:
o indexes never get smallerWhich we knew...
o drop/recreate index is slower than vacuum of indexes
Quite a few people have reported finding the opposite in practice.
I'm one of them. On 1,5 GB table with three indices it about twice
slowly.
Probably becouse vacuuming indices brakes system cache policy.
(FreeBSD 3.3)
OK, we are researching what things can be done to improve this. We are
toying with:
lock table for less duration, or read lock
creating another copy of heap/indexes, and rename() over old files
improving heap vacuum speed
improving index vacuum speed
moving analyze out of vacuum
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 21 15:14:48 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA41105
for <pgsql-hackers@postgresql.org>;
Fri, 21 Jan 2000 15:14:17 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA69039;
Fri, 21 Jan 2000 16:12:25 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 21 Jan 2000 16:12:25 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Dmitry Samersoff <dms@wplus.net>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: vacuum timings
In-Reply-To: <200001211954.OAA15772@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001211607080.23487-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 21 Jan 2000, Bruce Momjian wrote:
[Charset koi8-r unsupported, filtering to ASCII...]
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Conclusions:
o indexes never get smallerWhich we knew...
o drop/recreate index is slower than vacuum of indexes
Quite a few people have reported finding the opposite in practice.
I'm one of them. On 1,5 GB table with three indices it about twice
slowly.
Probably becouse vacuuming indices brakes system cache policy.
(FreeBSD 3.3)OK, we are researching what things can be done to improve this. We are
toying with:lock table for less duration, or read lock
if there is some way that we can work around the bug that I believe Tom
found with removing the lock altogether (ie. makig use of MVCC), I think
that would be the best option ... if not possible, at least get things
down to a table lock vs the whole database?
a good example is the udmsearch that we are using on the site ... it uses
multiple tables to store the dictionary, each representing words of X size
... if I'm searching on a 4 letter word, and the whole database is locked
while it is working on the dictionary with 8 letter words, I'm sitting
there idle ... at least if we only locked the 8 letter table, everyone not
doing 8 letter searches can go on their merry way ...
Slightly longer vacuum's, IMHO, are acceptable if, to the end users, its
as transparent as possible ... locking per table would be slightly slower,
I think, because once a table is finished, the next table would need to
have an exclusive lock put on it before starting, so you'd have to
possibly wait for that...?
creating another copy of heap/indexes, and rename() over old files
sounds to me like introducing a large potential for error here ...
moving analyze out of vacuum
I think that should be done anyway ... if we ever get to the point that
we're able to re-use rows in tables, then that would eliminate the
immediate requirement for vacuum, but still retain a requirement for a
periodic analyze ... no?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 21 15:12:48 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA40732
for <hackers@postgresql.org>; Fri, 21 Jan 2000 15:12:36 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12BkQI-00051d-00; Fri, 21 Jan 2000 20:12:46 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12BkQ5-0004j4-00; Fri, 21 Jan 2000 20:12:33 +0000
Date: Fri, 21 Jan 2000 20:12:33 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Date/time type
Message-ID: <20000121201233.E18047@quartz.newn.cam.ac.uk>
References: <38852FE3.1698BDA9@alumni.caltech.edu>
<Pine.LNX.4.21.0001201535470.349-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <Pine.LNX.4.21.0001201535470.349-100000@localhost.localdomain>;
from peter_e@gmx.net on Thu, Jan 20, 2000 at 06:55:18PM +0100
On Thu, Jan 20, 2000 at 06:55:18PM +0100, Peter Eisentraut wrote:
Appendix/Note:
To ensure compatibility to earlier versions of PostgreSQL we also continue
to provide datetime (equivalent to timestamp), timespan (equivalent to
interval).
BTW, it seems Insight's PostgreSQL ODBC 6.40.0006 driver converts
Date/Time -> datetime (rather than timestamp)
Cheers,
Patrick
From bouncefilter Fri Jan 21 15:16:48 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA41560
for <hackers@postgresql.org>; Fri, 21 Jan 2000 15:16:11 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12BkTq-00051r-00; Fri, 21 Jan 2000 20:16:26 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12BkTd-0004jn-00; Fri, 21 Jan 2000 20:16:13 +0000
Date: Fri, 21 Jan 2000 20:16:13 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Postgres Hackers List <hackers@postgresql.org>
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] Re: Date/time type
Message-ID: <20000121201613.G18047@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <38852FE3.1698BDA9@alumni.caltech.edu>
<Pine.LNX.4.21.0001201535470.349-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <Pine.LNX.4.21.0001201535470.349-100000@localhost.localdomain>;
from peter_e@gmx.net on Thu, Jan 20, 2000 at 06:55:18PM +0100
On Thu, Jan 20, 2000 at 06:55:18PM +0100, Peter Eisentraut wrote:
Appendix/Note:
To ensure compatibility to earlier versions of PostgreSQL we also continue
to provide datetime (equivalent to timestamp), timespan (equivalent to
interval).
BTW, it seems Insight's PostgreSQL ODBC 6.40.0006 driver converts
Date/Time -> datetime (rather than timestamp)
Cheers,
Patrick
From bouncefilter Fri Jan 21 15:35:48 2000
Received: from corvette.mascari.com (dhcp26142035.columbus.rr.com
[24.26.142.35]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA48709
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 15:35:09 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.9.3/8.9.3) with ESMTP id PAA03312;
Fri, 21 Jan 2000 15:30:00 -0500
Message-ID: <3888C1AE.8EB2FC27@mascari.com>
Date: Fri, 21 Jan 2000 15:29:34 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Dmitry Samersoff <dms@wplus.net>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: vacuum timings
References: <200001211751.MAA12106@candle.pha.pa.us>
<16498.948481591@sss.pgh.pa.us> <3888B822.28F79A1F@wplus.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dmitry Samersoff wrote:
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Conclusions:
o indexes never get smallerWhich we knew...
o drop/recreate index is slower than vacuum of indexes
Quite a few people have reported finding the opposite in practice.
I'm one of them. On 1,5 GB table with three indices it about twice
slowly.
Probably becouse vacuuming indices brakes system cache policy.
I'm another. Do the times increase linearly with each index
added? Do the times increase linearly for each index for each
field in a composite index? Does the field type being indexed
have any affect (varchar vs int)?
Mike Mascari
From bouncefilter Fri Jan 21 16:24:48 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA59849
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 16:24:20 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id NAA18001;
Fri, 21 Jan 2000 13:46:39 -0800 (PST)
Date: Fri, 21 Jan 2000 13:46:38 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, prlw1@cam.ac.uk,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump disaster
Message-ID: <20000121134638.U14030@fw.wintelcom.net>
References: <3456.948431421@sss.pgh.pa.us>
<200001210549.AAA13736@candle.pha.pa.us>
<20000121010305.K14030@fw.wintelcom.net>
<4769.948469442@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <4769.948469442@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Fri, Jan 21, 2000 at 10:44:02AM -0500
* Tom Lane <tgl@sss.pgh.pa.us> [000121 08:14] wrote:
Alfred Perlstein <bright@wintelcom.net> writes:
The answer appears to be that Perlstein's "nonblocking mode" patches
have broken psql copy, and doubtless a lot of other applications as
well, because pqPutBytes no longer feels any particular compulsion
to actually send the data it's been handed. (Moreover, if it does
do only a partial send, there is no way to discover how much it sent;
while its callers might be blamed for not having checked for an error
return, they'd have no way to recover anyhow.)pqPutBytes _never_ felt any compulsion to flush the buffer to the backend,
or at least not since I started using it.Sorry, I was insufficiently careful about my wording. It's true that
pqPutBytes doesn't worry about actually flushing the data out to the
backend. (It shouldn't, either, since it is typically called with small
fragments of a message rather than complete messages.) It did, however,
take care to *accept* all the data it was given and ensure that the data
was queued in the output buffer. As the code now stands, it's
impossible to tell whether all the passed data was queued or not, or how
much of it was queued. This is a fundamental design error, because the
caller has no way to discover what to do after a failure return (nor
even a way to tell if it was a hard failure or just I-won't-block).
Moreover, no existing caller of PQputline thinks it should have to worry
about looping around the call, so even if you put in a usable return
convention, existing apps would still be broken.Similarly, PQendcopy is now willing to return without having gotten
the library out of the COPY state, but the caller can't easily tell
what to do about it --- nor do existing callers believe that they
should have to do anything about it.The implications of this is trully annoying, exporting the socket to
the backend to the client application causes all sorts of problems because
the person select()'ing on the socket sees that it's 'clear' but yet
all thier data has not been sent...Yeah, the original set of exported routines was designed without any
thought of handling a nonblock mode. But you aren't going to be able
to fix them this way. There will need to be a new set of entry points
that add a concept of "operation not complete" to their API, and apps
that want to avoid blocking will need to call those instead. Compare
what's been done for connecting (PQconnectPoll) and COPY TO STDOUT
(PQgetlineAsync).It's possible that things were broken before you got to them --- there
have been several sets of not-very-carefully-reviewed patches to libpq
during the current development cycle, so someone else may have created
the seeds of the problem. However, we weren't seeing failures in psql
before this week...
We both missed it, and yes it was my fault. All connections are
behaving as if PQsetnonblocking(conn, TRUE) have been called on them.
The original non-blocking patches did something weird, they seemed
to _always_ stick the socket into non-blocking mode. This would
activate my non-blocking stuff for all connections.
I assumed the only code that called the old makenonblocking function
was setup to handle this, unfortunatly it's not and you know what they
say about assumptions. :(
I should have a fix tonight.
sorry,
-Alfred
From bouncefilter Fri Jan 21 17:02:49 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA72711
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 17:02:17 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA09697;
Fri, 21 Jan 2000 17:02:06 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: vacuum timings
In-reply-to: <Pine.BSF.4.21.0001211607080.23487-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001211607080.23487-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Fri, 21 Jan 2000 16:12:25 -0400"
Date: Fri, 21 Jan 2000 17:02:06 -0500
Message-ID: <9694.948492126@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
lock table for less duration, or read lock
if there is some way that we can work around the bug that I believe Tom
found with removing the lock altogether (ie. makig use of MVCC), I think
that would be the best option ... if not possible, at least get things
down to a table lock vs the whole database?
Huh? VACUUM only requires an exclusive lock on the table it is
currently vacuuming; there's no database-wide lock.
Even a single-table exclusive lock is bad, of course, if it's a large
table that's critical to a 24x7 application. Bruce was talking about
the possibility of having VACUUM get just a write lock on the table;
other backends could still read it, but not write it, during the vacuum
process. That'd be a considerable step forward for 24x7 applications,
I think.
It looks like that could be done if we rewrote the table as a new file
(instead of compacting-in-place), but there's a problem when it comes
time to rename the new files into place. At that point you'd need to
get an exclusive lock to ensure all the readers are out of the table too
--- and upgrading from a plain lock to an exclusive lock is a well-known
recipe for deadlocks. Not sure if this can be solved.regards, tom lane
From bouncefilter Fri Jan 21 17:06:53 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA74015
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 17:05:52 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA09728;
Fri, 21 Jan 2000 17:05:43 -0500 (EST)
To: Alfred Perlstein <bright@wintelcom.net>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, prlw1@cam.ac.uk,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump disaster
In-reply-to: <20000121134638.U14030@fw.wintelcom.net>
References: <3456.948431421@sss.pgh.pa.us>
<200001210549.AAA13736@candle.pha.pa.us>
<20000121010305.K14030@fw.wintelcom.net>
<4769.948469442@sss.pgh.pa.us>
<20000121134638.U14030@fw.wintelcom.net>
Comments: In-reply-to Alfred Perlstein <bright@wintelcom.net>
message dated "Fri, 21 Jan 2000 13:46:38 -0800"
Date: Fri, 21 Jan 2000 17:05:43 -0500
Message-ID: <9725.948492343@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Alfred Perlstein <bright@wintelcom.net> writes:
We both missed it, and yes it was my fault. All connections are
behaving as if PQsetnonblocking(conn, TRUE) have been called on them.
The original non-blocking patches did something weird, they seemed
to _always_ stick the socket into non-blocking mode. This would
activate my non-blocking stuff for all connections.
Yes, the present state of the code seems to activate nonblocking socket
mode all the time; possibly we could band-aid our way back to a working
psql by turning off nonblock mode by default. But this doesn't address
the fact that the API of these routines cannot support nonblock mode
without being redesigned.
regards, tom lane
From bouncefilter Fri Jan 21 23:11:53 2000
Received: from pcr.ca (www.pcr.ca [207.139.158.13] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id XAA71351
for <pgsql-general@postgresql.org>;
Fri, 21 Jan 2000 23:11:30 -0500 (EST)
(envelope-from admin@wtbwts.com)
Received: by pcr.ca (Postfix, from userid 1000)
id 8A60F1FEE; Fri, 21 Jan 2000 23:10:46 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1])
by pcr.ca (Postfix) with ESMTP id 67B171FEC
for <pgsql-general@postgresql.org>;
Fri, 21 Jan 2000 23:10:46 +0000 (GMT)
Date: Fri, 21 Jan 2000 23:10:46 +0000 (GMT)
From: Marc Tardif <admin@wtbwts.com>
X-Sender: admin@server.b0x.com
To: pgsql-general@postgresql.org
Subject: max(oid)
Message-ID: <Pine.BSF.4.10.10001212308020.19731-100000@server.b0x.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Is there a way to use the max aggregate on an oid field? When I try on
6.5.3, I get the following error message:
test=> select max(uid) from user_base;
ERROR: Unable to select an aggregate function max(oid)
If there's any work-around, please let me know.
Marc
From bouncefilter Fri Jan 21 19:12:50 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA13415
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 19:12:49 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id UAA70725;
Fri, 21 Jan 2000 20:11:28 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 21 Jan 2000 20:11:27 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: vacuum timings
In-Reply-To: <9694.948492126@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001211957590.23487-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 21 Jan 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
lock table for less duration, or read lock
if there is some way that we can work around the bug that I believe Tom
found with removing the lock altogether (ie. makig use of MVCC), I think
that would be the best option ... if not possible, at least get things
down to a table lock vs the whole database?Huh? VACUUM only requires an exclusive lock on the table it is
currently vacuuming; there's no database-wide lock.Even a single-table exclusive lock is bad, of course, if it's a large
table that's critical to a 24x7 application. Bruce was talking about
the possibility of having VACUUM get just a write lock on the table;
other backends could still read it, but not write it, during the vacuum
process. That'd be a considerable step forward for 24x7 applications,
I think.It looks like that could be done if we rewrote the table as a new file (instead of compacting-in-place), but there's a problem when it comes time to rename the new files into place. At that point you'd need to get an exclusive lock to ensure all the readers are out of the table too --- and upgrading from a plain lock to an exclusive lock is a well-known recipe for deadlocks. Not sure if this can be solved.
What would it take to re-use space vs compacting/truncating the file?
Right now, ppl vacuum the database to clear out old, deleted records, and
truncate the tables ... if we were to change things so that an
insert/update were to find the next largest contiguous free block in the
table and re-used it, then, theoretically, you would eventually hit a
fixed table size assuming no new inserts, and only updates/deletes, right?
Eventually, you'd have "holes" in the table, where an inserted record was
smaller then the "next largest contiguous free block", but what's left
over is too small for any further additions ... but I would think that
that would greatly reduce how often you'd have to do a vacuum, and, if we
split out ANALYZE, you could use that to update statistics ...
To speed up the search for the "next largest contiguous free block", a
special table.FAT could be used similar to an index?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Fri Jan 21 21:41:52 2000
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA51276
for <docs@postgresql.org>; Fri, 21 Jan 2000 21:41:16 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id CAA32427;
Sat, 22 Jan 2000 02:49:20 GMT
Sender: lockhart@hub.org
Message-ID: <38891AB0.E2499525@alumni.caltech.edu>
Date: Sat, 22 Jan 2000 02:49: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: Mark Hollomon <mhh@nortelnetworks.com>
CC: Michael Alan Dorman <mdorman@debian.org>,
Postgres Documentation List <docs@postgresql.org>
Subject: Re: [HACKERS] Building Documentation under Debian
References: <38885FB2.5F1385E6@americasm01.nt.com>
<8766wnieob.fsf@kate.private.net>
<3888A5D2.539D5F6@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
2. grab the DSSSL stuff from http://www.nwalsh.com/docbook/dsssl
and unzip it somewhere (I chose /usr/share).FWIW, this stuff is available in a package as as docbook-stylesheets.
Ah - that's what they named it. I looked for a package called dsssl.
Where does the package install the files /usr/share, /usr/lib,
something else?
Thomas, change step 2 to:
2. install the docbook-stylesheets package
apt-get install docbook-stylesheets
drop the unzip package from step 1.
Actually, unless there is an objection I'll add the
docbook-stylesheets package but will retain mention of the Norm Walsh
zip files since these are usually a bit more up to date than those in
a packaged distro. I use them on my Linux box even though there are
rpms available...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Jan 21 23:29:53 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA73377
for <pgsql-general@postgreSQL.org>;
Fri, 21 Jan 2000 23:29:24 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA28444;
Fri, 21 Jan 2000 23:29:10 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001220429.XAA28444@candle.pha.pa.us>
Subject: Re: [GENERAL] max(oid)
In-Reply-To: <Pine.BSF.4.10.10001212308020.19731-100000@server.b0x.com> from
Marc Tardif at "Jan 21, 2000 11:10:46 pm"
To: Marc Tardif <admin@wtbwts.com>
Date: Fri, 21 Jan 2000 23:29:09 -0500 (EST)
CC: pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Is there a way to use the max aggregate on an oid field? When I try on
6.5.3, I get the following error message:test=> select max(uid) from user_base;
ERROR: Unable to select an aggregate function max(oid)If there's any work-around, please let me know.
Marc
Added to TODO:
* allow aggregates on oid
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Jan 21 23:50:54 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA79081
for <pgsql-hackers@postgreSQL.org>;
Fri, 21 Jan 2000 23:50:46 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA19681;
Fri, 21 Jan 2000 23:50:13 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: vacuum timings
In-reply-to: <200001211751.MAA12106@candle.pha.pa.us>
References: <200001211751.MAA12106@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Fri, 21 Jan 2000 12:51:53 -0500"
Date: Fri, 21 Jan 2000 23:50:13 -0500
Message-ID: <19678.948516613@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Conclusions:
o drop/recreate index is slower than vacuum of indexes
BTW, I did some profiling of CREATE INDEX this evening (quite
unintentionally actually; I was interested in COPY IN, but the pg_dump
script I used as driver happened to create some indexes too). I was
startled to discover that 60% of the runtime of CREATE INDEX is spent in
_bt_invokestrat (which is called from tuplesort.c's comparetup_index,
and exists only to figure out which specific comparison routine to call).
Of this, a whopping 4% was spent in the useful subroutine, int4gt. All
the rest went into lookup and validation checks that by rights should be
done once per index creation, not once per comparison.
In short: a fairly straightforward bit of optimization will eliminate
circa 50% of the CPU time consumed by CREATE INDEX. All we need is to
figure out where to cache the lookup results. The optimization would
improve insertions and lookups in indexes, as well, if we can cache
the lookup results in those scenarios.
This was for a table small enough that tuplesort.c could do the sort
entirely in memory, so I'm sure the gains would be smaller for a large
table that requires a disk-based sort. Still, it seems worth looking
into...
regards, tom lane
From bouncefilter Sat Jan 22 00:17:54 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA86170
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 00:17:52 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA03032;
Sat, 22 Jan 2000 00:17:36 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001220517.AAA03032@candle.pha.pa.us>
Subject: Re: vacuum timings
In-Reply-To: <19678.948516613@sss.pgh.pa.us> from Tom Lane at "Jan 21,
2000 11:50:13 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 22 Jan 2000 00:17:36 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Conclusions:
o drop/recreate index is slower than vacuum of indexesBTW, I did some profiling of CREATE INDEX this evening (quite
unintentionally actually; I was interested in COPY IN, but the pg_dump
script I used as driver happened to create some indexes too). I was
startled to discover that 60% of the runtime of CREATE INDEX is spent in
_bt_invokestrat (which is called from tuplesort.c's comparetup_index,
and exists only to figure out which specific comparison routine to call).
Of this, a whopping 4% was spent in the useful subroutine, int4gt. All
the rest went into lookup and validation checks that by rights should be
done once per index creation, not once per comparison.
Good job, Tom. Clearly a huge win.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 22 02:23:55 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA15668
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 02:23:35 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id BAA78349
for pgsql-hackers@postgresql.org; Sat, 22 Jan 2000 01:55:10 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: mr_hopkins@earthlink.net (Micheal H.)
X-Newsgroups: comp.databases.postgresql.hackers
Subject: No suitable driver problem
Message-ID: <38893f4d.7230471@news.earthlink.net>
X-Newsreader: Forte Free Agent 1.11/32.235
Lines: 12
X-Complaints-To: abuse@earthlink.net
X-Trace: newsread1.prod.itd.earthlink.net 948524074 209.179.131.187 (Fri,
21 Jan 2000 22:54:34 PST)
Organization: EarthLink Network, Inc.
X-ELN-Date: Fri Jan 21 22:54:34 2000
Date: Sat, 22 Jan 2000 06:54:34 GMT
To: pgsql-hackers@postgresql.org
I've checked the format of the postgresql jdbc url I'm using for my
getConnection call, it acctually works when used for programs run from
the command line. It's only when I run an applet in a browser do I
get the error "No suitable driver". I believe the jar is being loaded
because until I added the statement "archive=postgresql.jar" to my
applet statement, the Class.forName("postgresql.Driver"); statement
was producing an error.
Thanks for the help, past and future.
From bouncefilter Sat Jan 22 01:57:55 2000
Received: from munn.com (kmunn.munn.com [209.123.248.252])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA10037
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 01:57:12 -0500 (EST) (envelope-from kmunn@munn.com)
Received: from localhost (kmunn@localhost)
by munn.com (8.9.1/8.9.1) with ESMTP id BAA12023
for <pgsql-hackers@postgresql.org>; Sat, 22 Jan 2000 01:57:07 -0500
Date: Sat, 22 Jan 2000 01:57:07 -0500 (EST)
From: Kristofer Munn <kmunn@munn.com>
To: pgsql-hackers@postgresql.org
Subject: Patch for elog(FATAL)/elog(ERROR) infinite loop?
Message-ID: <Pine.LNX.4.04.10001220153550.10641-100000@munn.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi everyone. Awhile back I reported the elog(FATAL)/elog(ERROR) infinite
loop and I see it marked in the TODO as done for 7.0. Is there a patch
for this problem for 6.5.3?
Thanks...
- K
Kristofer Munn * KMI * 973-509-9414 * AIM KrMunn * http://www.munn.com/
From bouncefilter Sat Jan 22 03:16:56 2000
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 DAA31647
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 03:16:26 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm114.noc.fukui.nsk.ne.jp [210.161.188.33])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id RAA04754; Sat, 22 Jan 2000 17:14:43 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] Re: vacuum timings
Date: Sat, 22 Jan 2000 17:15:37 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFIEEACCAA.Inoue@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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <16498.948481591@sss.pgh.pa.us>
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgresql.org
[mailto:owner-pgsql-hackers@postgresql.org]On Behalf Of Tom LaneBruce Momjian <pgman@candle.pha.pa.us> writes:
Conclusions:
o indexes never get smallerWhich we knew...
o drop/recreate index is slower than vacuum of indexes
Quite a few people have reported finding the opposite in practice.
You should probably try vacuuming after deleting or updating some
fraction of the rows, rather than just the all or none cases.
Vacuum after delelting all rows isn't a worst case.
There's no moving in that case and vacuum doesn't need to call
index_insert() corresponding to the moving of heap tuples.
Vacuum after deleting half of rows may be one of the worst case.
In this case,index_delete() is called as many times as 'delete all'
case and expensive index_insert() is called for moved_in tuples.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Sat Jan 22 03:29:56 2000
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA32730
for <hackers@postgreSQL.org>; Sat, 22 Jan 2000 03:29:47 -0500 (EST)
(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 PAA17302;
Sat, 22 Jan 2000 15:29:40 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <38896A74.5C1D455B@krs.ru>
Date: Sat, 22 Jan 2000 15:29:40 +0700
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: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] Well...
References: <38854432.54EE2F01@krs.ru> <20000122002543Q.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tatsuo Ishii wrote:
I hope to get H1B visa Feb 4 and leave for
San-Francisco on Feb 6...
I'll be in Krasnoyarsk till Feb 2.That means you are going to spend 2 or 3 months in US, then come back
I'm going to spend ~3 years in USA -:)
in April or May? I just think it would be really nice if you could
stop over Japan...
Thanks! I would be glad to visit Japan sometime.
Vadim
From bouncefilter Sat Jan 22 05:57:58 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA65253
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 05:57:28 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max03-075.enterprise.net
[194.72.196.75])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id KAA09723
for <pgsql-hackers@postgresql.org>; Sat, 22 Jan 2000 10:57:10 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id KAA10118
for <pgsql-hackers@postgresql.org>; Sat, 22 Jan 2000 10:56:19 GMT
Message-Id: <200001221056.KAA10118@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Types
In-Reply-To: Message from Michael Meskes <meskes@postgreSQL.org> of "Fri,
21 Jan 2000 15:11:32 +0100." <20000121151132.A372@fam-meskes.de>
References: <20000121151132.A372@fam-meskes.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 22 Jan 2000 10:56:19 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
Michael Meskes wrote:
libpq gives back the internal typenumbers of the attributes. How do I know
which number means which type? I need to find out if the type is an array.
If the type is 1007, then:
template1=> select typname from pg_type where oid = 1007;
typname
-------
_int4
(1 row)
If the typename begins with an underscore, it is an array type.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"He that giveth unto the poor shall not lack..."
Proverbs 28:27
From bouncefilter Sat Jan 22 13:19:03 2000
Received: from pcr.ca (www.pcr.ca [207.139.158.13] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id NAA76754
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 13:18:10 -0500 (EST)
(envelope-from admin@wtbwts.com)
Received: by pcr.ca (Postfix, from userid 1000)
id 6E26E1FEE; Sat, 22 Jan 2000 13:17:31 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1])
by pcr.ca (Postfix) with ESMTP id 5F2851FEC
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 13:17:31 +0000 (GMT)
Date: Sat, 22 Jan 2000 13:17:26 +0000 (GMT)
From: Marc Tardif <admin@wtbwts.com>
X-Sender: admin@server.b0x.com
To: pgsql-hackers@postgresql.org
Subject: pglib and long queries
Message-ID: <Pine.BSF.4.10.10001221305580.22701-100000@server.b0x.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I am using a c program to insert the contents of mail messages into
postgresql. First, I copy the message from stdin into a char pointer which
I malloc at every line, then I use the following code to insert into a
table:
char query[1024];
PGresult *res;
...
sprint(query, "insert into mail_msg values ('%s'), message);
res = PQexec(conn, query);
...
There is obviously more than one problem here, the most important being
I'm inserting a message of undetermined length into a char array of 1024
bytes. Second, I'm not parsing the message for apostrophes or other
characters which would mess-up my query.
I'd appreciate if someone could suggest a solution to either problem, or
point me towards sample source code I could learn from. Please do not
suggest using Perl, I enjoy c even though I am still not very proficient
at it and this is a good opportunity to practice.
Thanks again,
Marc
From bouncefilter Sat Jan 22 09:00:00 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id IAA00613
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 08:59:43 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 13793 invoked from network); 22 Jan 2000 13:59:38 -0000
Received: from h-62.96.160.112.host.de.colt.net (root@62.96.160.112)
by pille.addcom.de with SMTP; 22 Jan 2000 13:59:38 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id OAA01464
for pgsql-hackers@postgresql.org; Sat, 22 Jan 2000 14:52:55 +0100
Date: Sat, 22 Jan 2000 14:52:55 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] off topic
Message-ID: <20000122145255.A1455@fam-meskes.de>
Mail-Followup-To: PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <Pine.LNX.4.21.0001201910480.349-100000@localhost.localdomain>
<388872B7.EE46009A@lillysoftware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <388872B7.EE46009A@lillysoftware.com>;
from rdavis@lillysoftware.com on Fri, Jan 21, 2000 at 09:52:39AM
-0500
On Fri, Jan 21, 2000 at 09:52:39AM -0500, Robert Davis wrote:
I really have the heart of doing this all the time but I dont have the
will. I have 3 kids and a wife and I enjoy boating, hiking etc. I just
Me too. I have wife plus three sons between 2 and 9 years old.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Sat Jan 22 09:00:00 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id IAA00590
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 08:59:31 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 13749 invoked from network); 22 Jan 2000 13:59:28 -0000
Received: from h-62.96.160.112.host.de.colt.net (root@62.96.160.112)
by pille.addcom.de with SMTP; 22 Jan 2000 13:59:28 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id OAA01468
for pgsql-hackers@postgresql.org; Sat, 22 Jan 2000 14:53:09 +0100
Date: Sat, 22 Jan 2000 14:53:09 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Types
Message-ID: <20000122145309.B1455@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
References: <20000121151132.A372@fam-meskes.de> <meskes@postgreSQL.org>
<200001221056.KAA10118@linda.lfix.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <200001221056.KAA10118@linda.lfix.co.uk>;
from olly@lfix.co.uk on Sat, Jan 22, 2000 at 10:56:19AM +0000
On Sat, Jan 22, 2000 at 10:56:19AM +0000, Oliver Elphick wrote:
If the type is 1007, then:
template1=> select typname from pg_type where oid = 1007;
typname
-------
_int4
(1 row)If the typename begins with an underscore, it is an array type.
Thanks.
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Sat Jan 22 09:00:06 2000
Received: from pille.addcom.de (qmailr@h-62.96.128.34.host.de.colt.net
[62.96.128.34]) by hub.org (8.9.3/8.9.3) with SMTP id IAA00608
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 08:59:36 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: (qmail 13773 invoked from network); 22 Jan 2000 13:59:34 -0000
Received: from h-62.96.160.112.host.de.colt.net (root@62.96.160.112)
by pille.addcom.de with SMTP; 22 Jan 2000 13:59:34 -0000
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id OAA01479
for pgsql-hackers@postgreSQL.org; Sat, 22 Jan 2000 14:54:10 +0100
Date: Sat, 22 Jan 2000 14:54:09 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] off topic
Message-ID: <20000122145409.A1471@fam-meskes.de>
Mail-Followup-To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
References: <20000121083507.A426@fam-meskes.de>
<200001211503.KAA01869@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <200001211503.KAA01869@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Fri, Jan 21, 2000 at 10:03:07AM
-0500
On Fri, Jan 21, 2000 at 10:03:07AM -0500, Bruce Momjian wrote:
The book helped my wife see some value in this. "Gee, I don't know
anyone who wrote a book", she said.
Good idea, but you have to find time for writing a book too. Also I already
did this with my Ph.D. thesis so I'm afraid it won't count. :-)
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
From bouncefilter Sat Jan 22 09:18:00 2000
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 JAA06191
for <hackers@postgresql.org>; Sat, 22 Jan 2000 09:17:26 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61199 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S366594AbQAVOQs>;
Sat, 22 Jan 2000 15:16:48 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12C1SP-0001O9-00; Sat, 22 Jan 2000 15:24:05 +0100
Date: Sat, 22 Jan 2000 15:24:05 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] initdb problems on Solaris
In-Reply-To: <20000120142800.C32049@rice.edu>
Message-ID: <Pine.LNX.4.21.0001202302520.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-20, Ross J. Reedstrom mentioned:
Peter -
If you're going to look at the id for initdb, please consider the
NT port as well. This may be more of a problem with cygwin than pgsql,
but pg_id didn't work correctly, and I had to hack on the initdb script
to get it to to run, with a 6.5.3 install, recently.
Oh dear, I just wrote a new pg_id thingy that fulfills all my initdb
wishes (no id, not whoami vs 'who am i', no Solaris stupidities), but
what's now? How does NT/Cygwin handle it? Don't they have a geteuid()
function? Feel free to hack up pg_id to always return 42 in that case.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Jan 22 09:19:00 2000
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 JAA06259
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 09:18:04 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61349 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S366597AbQAVORR>;
Sat, 22 Jan 2000 15:17:17 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12C1Su-0001PA-00; Sat, 22 Jan 2000 15:24:36 +0100
Date: Sat, 22 Jan 2000 15:24:36 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Status on 7.0
In-Reply-To: <200001201811.NAA09507@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0001202307410.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-20, Bruce Momjian mentioned:
Are we going to yank DISTINCT ON?
I don't show DISTINCT ON as being worked on by anyone.
I think Tom mentioned several times that he would like to yank it because
a) it's non-standard
b) it's conceptually flawed
c) there's a standard alternative
d) it doesn't work too well
e) people keep trying to use it
Just making sure no one forgets ...
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Jan 22 11:10:01 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA30307;
Sat, 22 Jan 2000 11:10:00 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA20548;
Sat, 22 Jan 2000 11:09:36 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: Michael Meskes <meskes@postgreSQL.org>,
PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Types
In-reply-to: <200001221056.KAA10118@linda.lfix.co.uk>
References: <20000121151132.A372@fam-meskes.de>
<200001221056.KAA10118@linda.lfix.co.uk>
Comments: In-reply-to "Oliver Elphick" <olly@lfix.co.uk>
message dated "Sat, 22 Jan 2000 10:56:19 +0000"
Date: Sat, 22 Jan 2000 11:09:36 -0500
Message-ID: <20545.948557376@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Oliver Elphick" <olly@lfix.co.uk> writes:
Michael Meskes wrote:
libpq gives back the internal typenumbers of the attributes. How do I know
which number means which type? I need to find out if the type is an array.
If the type is 1007, then:
template1=> select typname from pg_type where oid = 1007;
typname
-------
_int4
(1 row)
Right...
If the typename begins with an underscore, it is an array type.
If you are going to the trouble of looking in pg_type, then you
shouldn't rely on the convention that array type names begin with
underscores. What you *should* do is look at the typelem field.
If that's zero, it's not an array; if nonzero, it is an array type
(and typelem gives the OID of the array elements' type).
regards, tom lane
From bouncefilter Sat Jan 22 11:13:01 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA30564
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 11:12:46 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA20569;
Sat, 22 Jan 2000 11:11:26 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Bruce Momjian" <pgman@candle.pha.pa.us>,
"PostgreSQL-development" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: vacuum timings
In-reply-to: <NDBBIJLOILGIKBGDINDFIEEACCAA.Inoue@tpf.co.jp>
References: <NDBBIJLOILGIKBGDINDFIEEACCAA.Inoue@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Sat, 22 Jan 2000 17:15:37 +0900"
Date: Sat, 22 Jan 2000 11:11:25 -0500
Message-ID: <20566.948557485@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
Vacuum after deleting half of rows may be one of the worst case.
Or equivalently, vacuum after updating all the rows.
regards, tom lane
From bouncefilter Sat Jan 22 11:38:02 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA36582
for <hackers@postgreSQL.org>; Sat, 22 Jan 2000 11:37:37 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA20707;
Sat, 22 Jan 2000 11:37:34 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] psql updates
In-reply-to: <Pine.LNX.4.21.0001122022550.1646-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001122022550.1646-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Wed, 12 Jan 2000 20:44:25 +0100"
Date: Sat, 22 Jan 2000 11:37:34 -0500
Message-ID: <20704.948559054@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
... I'd particularly be interested whether the readline related
compilation problem is gone, since by readline's CHANGELOG I cannot
decode when or where the problem was introduced or removed.
It was still there, but I fixed it. Given the lack of any clear version
info for libreadline, adding a configure-time test seems to be the
way to go.
The particular problem I saw was that the exported variable
rl_completion_append_character doesn't exist in old versions of
libreadline. (How old? I dunno, but a RedHat 4.2 box I have access to
has a libreadline that's like that.) I arranged to #ifdef out psql's
attempt to set the variable unless configure sees that the variable
is declared in <libreadline.h>. With that change, psql builds
successfully against that libreadline version. The tab-completion
behavior seems a little flaky (if you press tab when you don't have
a partial keyword typed, it wipes out whatever word you do have typed)
but I doubt it is worth trying to fix that. I'm satisfied if psql
builds and is usable --- anyone who complains about the tab behavior
can be told they need a newer libreadline.
regards, tom lane
From bouncefilter Sat Jan 22 11:41:02 2000
Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA36881;
Sat, 22 Jan 2000 11:40:45 -0500 (EST)
(envelope-from byron.nikolaidis@home.com)
Received: from home.com ([24.4.141.52]) by mail.rdc1.md.home.com
(InterMail v4.01.01.00 201-229-111) with ESMTP
id <20000122164044.GBWB21783.mail.rdc1.md.home.com@home.com>;
Sat, 22 Jan 2000 08:40:44 -0800
Message-ID: <3889DD8D.32ACABD8@home.com>
Date: Sat, 22 Jan 2000 11:40:46 -0500
From: Byron Nikolaidis <byron.nikolaidis@home.com>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405 (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jose Soares <jose@sferacarta.com>
CC: interfaces <pgsql-interfaces@postgreSQL.org>,
hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [INTERFACES] Re: ODBC drive strange behavior
References: <38881F35.CAA49A56@sferacarta.com>
<38881FC3.D34B1BEC@sferacarta.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Jose Soares wrote:
Sorry I forgot to send the attachement :)
Jose Soares wrote:
Please help!
The PSQLODBC aborts a transaction with a strange error while execute a
legal query.
The message is:"Could not begin a transaction; unexpected protocol character from
backend (sen_query) (#1)"I tried the same query with psql client and it works with no problems.
Does anyone know what this message means ?
My configuration:
Data base server: PostgreSQL v6.5.2
OS server: Linux 2.0.37 (Debian)
Win Client: M$_Access95
PsqlODBC v6.40.0006
log file attached.Any help would be very apreciated.
Jos���
------------------------------------------------------------------------
Name: LOG_ERROR.log
LOG_ERROR.log Type: Text Document (application/x-unknown-content-type-txtfile)
Encoding: base64
The error means the driver didn't receive the expected response
character from the backend. For queries, the expected response would be
something like:
'T': results are coming (this one is the most likely expected)
'C': no tuples produced
'Z': ready for new query (in >= postgres 6.4 only).
'I': empty query produces this response
'N': notice
'E': error
In your case, the query begins: (SELECT "figure"."azienda"
It might be the extra parenthesis around the query ? Try removing
them. If that's not it, try making the query really short, just as an
experiment. Also, using the wrong protocol with the backend can make
this happen.
Byron
From bouncefilter Sat Jan 22 12:41:02 2000
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 MAA67345
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 12:40:37 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA21558;
Sat, 22 Jan 2000 12:33:29 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001221733.MAA21558@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: vacuum timings
In-Reply-To: <NDBBIJLOILGIKBGDINDFIEEACCAA.Inoue@tpf.co.jp> from Hiroshi Inoue
at "Jan 22, 2000 05:15:37 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Sat, 22 Jan 2000 12:33:29 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Quite a few people have reported finding the opposite in practice.
You should probably try vacuuming after deleting or updating some
fraction of the rows, rather than just the all or none cases.Vacuum after delelting all rows isn't a worst case.
There's no moving in that case and vacuum doesn't need to call
index_insert() corresponding to the moving of heap tuples.Vacuum after deleting half of rows may be one of the worst case.
In this case,index_delete() is called as many times as 'delete all'
case and expensive index_insert() is called for moved_in tuples.
I will test that.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 22 12:42:02 2000
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 MAA67393;
Sat, 22 Jan 2000 12:41:02 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA21661;
Sat, 22 Jan 2000 12:36:16 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001221736.MAA21661@candle.pha.pa.us>
Subject: Re: [HACKERS] off topic
In-Reply-To: <20000122145409.A1471@fam-meskes.de> from Michael Meskes at "Jan
22, 2000 02:54:09 pm"
To: Michael Meskes <meskes@postgresql.org>
Date: Sat, 22 Jan 2000 12:36:16 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Fri, Jan 21, 2000 at 10:03:07AM -0500, Bruce Momjian wrote:
The book helped my wife see some value in this. "Gee, I don't know
anyone who wrote a book", she said.Good idea, but you have to find time for writing a book too. Also I already
did this with my Ph.D. thesis so I'm afraid it won't count. :-)
Yes, you lose even more time with the book, which is added to the
PostgreSQL time.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 22 16:37:05 2000
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 QAA34410
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 16:36:51 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <D3KATKTH>; Sat, 22 Jan 2000 23:33:20 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C47A@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: Explain output
Date: Sat, 22 Jan 2000 23:29:16 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Hi, all
Is it possible to get an explain to return a rowset? I've added a PERSIST
option, and need to return the plan id as a row (if anybody thinks there are
better ways, I'm open to ideas). elogging doesn't help, because with some
client interfaces, it's very difficult to get to an elog result. So, I
thought that return a single row, with a single column might do the trick.
Ideas...
MikeA
From bouncefilter Sat Jan 22 19:04:07 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA74460
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 19:03:08 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA02074;
Sat, 22 Jan 2000 19:02:44 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Doc updates for index cost estimator change
Date: Sat, 22 Jan 2000 19:02:43 -0500
Message-ID: <2071.948585763@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I have written the attached bit of doco about the new index cost
estimator procedure definition, but I am not sure where to put it.
There isn't (AFAICT) any existing documentation about how to make
a new kind of index, which would be the proper place for it.
May I impose on you to find/make a place for this and mark it up
properly?
Also, doc/src/graphics/catalogs.ag needs to be updated, but I have
no idea how. (The amopselect and amopnpages fields of pg_amop
are gone; pg_am has a new field amcostestimate.)
regards, tom lane
Index cost estimation functions
-------------------------------
Every index access method must provide a cost estimation function for
use by the planner/optimizer. The procedure OID of this function is
given in the 'amcostestimate' field of the access method's pg_am entry.
(Note: prior to Postgres 7.0, a different scheme was used for registering
index-specific cost estimation functions.)
The amcostestimate function is given a list of WHERE clauses that have
been determined to be usable with the index. It must return estimates
of the cost of accessing the index and the selectivity of the WHERE
clauses (that is, the fraction of main-table tuples that will be
retrieved during the index scan). For simple cases, nearly all the
work of the cost estimator can be done by calling standard routines
in the optimizer --- the point of having an amcostestimate function is
to allow index access methods to provide index-type-specific knowledge,
in case it is possible to improve on the standard estimates.
Each amcostestimate function must have the signature
void
amcostestimate (Query *root,
RelOptInfo *rel,
IndexOptInfo *index,
List *indexQuals,
Cost *indexAccessCost,
Selectivity *indexSelectivity);
The first four parameters are inputs:
root The query being processed
rel The relation the index is on
index The index itself
indexQuals List of index qual clauses (implicitly ANDed);
NIL list indicates no qualifiers are available
The last two parameters are pass-by-reference outputs:
*indexAccessCost Set to cost of index processing
*indexSelectivity Set to index selectivity
Note that cost estimate functions must be written in C, not in SQL or
any available procedural language, because they must access internal
data structures of the planner/optimizer.
The indexAccessCost should be computed in the units used by
src/backend/optimizer/path/costsize.c: a disk block fetch has cost 1.0,
and the cost of processing one index tuple should usually be taken as
cpu_index_page_weight (which is a user-adjustable optimizer parameter).
The access cost should include all disk and CPU costs associated with
scanning the index itself, but NOT the cost of retrieving or processing
the main-table tuples that are identified by the index.
The indexSelectivity should be set to the estimated fraction of the main
table tuples that will be retrieved during the index scan. In the case
of a lossy index, this will typically be higher than the fraction of
tuples that actually pass the given qual conditions.
A typical cost estimator will proceed as follows:
1. Estimate and return the fraction of main-table tuples that will be visited
based on the given qual conditions. In the absence of any index-type-specific
knowledge, use the standard optimizer function clauselist_selec():
*indexSelectivity = clauselist_selec(root, indexQuals);
2. Estimate the number of index tuples that will be visited during the
scan. For many index types this is the same as indexSelectivity times
the number of tuples in the index, but it might be more. (Note that the
index's size in pages and tuples is available from the IndexOptInfo struct.)
3. Estimate the number of index pages that will be retrieved during the scan.
This might be just indexSelectivity times the index's size in pages.
4. Compute the index access cost as
*indexAccessCost = numIndexPages + cpu_index_page_weight * numIndexTuples;
Examples of cost estimator functions can be found in
src/backend/utils/adt/selfuncs.c.
By convention, the pg_proc entry for an amcostestimate function should show
prorettype = 0
pronargs = 6
proargtypes = 0 0 0 0 0 0
We use zero ("opaque") for all the arguments since none of them have types
that are known in pg_type.
From bouncefilter Sat Jan 22 20:23:08 2000
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 UAA36102
for <pgsql-general@postgresql.org>;
Sat, 22 Jan 2000 20:22:15 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64887 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S391203AbQAWBVp>;
Sun, 23 Jan 2000 02:21:45 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CBpr-0003vN-00; Sun, 23 Jan 2000 02:28:59 +0100
Date: Sun, 23 Jan 2000 02:28:59 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Marc Tardif <admin@wtbwts.com>, pgsql-general@postgresql.org
Subject: Re: [GENERAL] max(oid)
In-Reply-To: <200001220429.XAA28444@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0001221730360.3007-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-21, Bruce Momjian mentioned:
Is there a way to use the max aggregate on an oid field? When I try on
6.5.3, I get the following error message:test=> select max(uid) from user_base;
ERROR: Unable to select an aggregate function max(oid)If there's any work-around, please let me know.
MarcAdded to TODO:
* allow aggregates on oid
We already had a TODO item for this and came to the conclusion that
* Make type equivalency apply to aggregates
will solve this.
For right now the user could do the following:
INSERT INTO pg_aggregate VALUES ('max', <your user id>, 'int4larger', '-',
'-', 26, 26, 0, 26, NULL, NULL);
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Jan 22 20:23:13 2000
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 UAA36114
for <docs@postgresql.org>; Sat, 22 Jan 2000 20:22:34 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:65063 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S372752AbQAWBV7>;
Sun, 23 Jan 2000 02:21:59 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CBq8-0003wU-00; Sun, 23 Jan 2000 02:29:16 +0100
Date: Sun, 23 Jan 2000 02:29:16 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Mark Hollomon <mhh@nortelnetworks.com>,
Michael Alan Dorman <mdorman@debian.org>,
Postgres Documentation List <docs@postgresql.org>
Subject: Re: [DOCS] Re: [HACKERS] Building Documentation under Debian
In-Reply-To: <38891AB0.E2499525@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0001221742020.3007-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-22, Thomas Lockhart mentioned:
2. grab the DSSSL stuff from http://www.nwalsh.com/docbook/dsssl
and unzip it somewhere (I chose /usr/share).FWIW, this stuff is available in a package as as docbook-stylesheets.
Ah - that's what they named it. I looked for a package called dsssl.
Where does the package install the files /usr/share, /usr/lib,
something else?
Thomas, change step 2 to:
2. install the docbook-stylesheets package
apt-get install docbook-stylesheets
drop the unzip package from step 1.Actually, unless there is an objection I'll add the
docbook-stylesheets package but will retain mention of the Norm Walsh
zip files since these are usually a bit more up to date than those in
a packaged distro. I use them on my Linux box even though there are
rpms available...
I think a lot of people found sgmltools to work for them (and perhaps a
lot more would, if they knew about it). That way you don't have to get
five different things and tune them to each other.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Jan 22 20:23:13 2000
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 UAA36164
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 20:22:44 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61130 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S372752AbQAWBWL>;
Sun, 23 Jan 2000 02:22:11 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CBqY-0003wm-00
for pgsql-hackers@postgresql.org; Sun, 23 Jan 2000 02:29:42 +0100
Date: Sun, 23 Jan 2000 02:29:42 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Happy column dropping
Message-ID: <Pine.LNX.4.21.0001221454130.3007-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
With caveats, it is now possible to drop columns from tables.
The implementation is based on copying the old table to a new one minus
the specified column. This procedure changes the oids of everyone
involved, so I was wondering if
a) this is a good reason to tell people to stop using oids as keys, or
b) if there is some way to keep the oids on both the records and the
pg_class entry.
Is it possible/safe to specify an oid to heap_insert (like tuple->...->oid
= x) if the oid is still in use (in the old table), or would a
heap_delete({from old table}) plus heap_insert({into new table}) work.
Is it possible/safe to change to oid of the new pg_class entry back to the
old one? In that case the trouble of moving over all the constraints, etc.
would be half the work.
Speaking of which, the current implementation loses all constraints,
triggers, rules, comments, etc. (not defaults and notnulls
though). Therefore
1) did I forget anything in the above list
2) how do I find out if the dropped column is referenced in a constraint,
trigger, rule (this is necessary for a correct RESTRICT/CASCADE
implementation)
3) once again, is it possible/safe to do the equivalent of update pg_class
set oid=old where oid=new to save this work?
Oh, btw., heaven help you if you try this on tables that are inherited
from.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Jan 22 20:23:18 2000
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 UAA36176
for <hackers@postgresql.org>; Sat, 22 Jan 2000 20:23:06 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61421 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S393222AbQAWBW3>;
Sun, 23 Jan 2000 02:22:29 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CBqk-0003wo-00; Sun, 23 Jan 2000 02:29:54 +0100
Date: Sun, 23 Jan 2000 02:29:54 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Vince Vielhaber <vev@michvhf.com>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] New install doc
In-Reply-To: <XFMail.000120181641.vev@michvhf.com>
Message-ID: <Pine.LNX.4.21.0001221804120.3007-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-20, Vince Vielhaber mentioned:
2. If you are not upgrading an existing system then skip to .
skip to 4.
6. Install the program. Type
$ gmake install
The installer needs to have write access to the install directory.
Presumably the installer would only try to install to a directory that he
has access to. With the new installation instructions you will end up
installing the program files as root, which is a) the normal thing to do,
b) less confusing, and c) more secure, since an astray trigger function
can't fry your installation proper. You can of course install it under
whatever user you want, but then you ought to be experienced enough to
figure it out yourself.
I remember my first installation and the juggling with su in and su out
and, darn, now I installed this as the wrong user, chown -R, etc. only to
find out that this was completely unnecessary. Consider Apache (my
rolemodel :), you don't install that as 'nobody' either.
8. Create the database installation. To do this you must log in to your
PostgreSQL superuser account. It will not work as root.$ mkdir /usr/local/pgsql/data
$ chown postgres /usr/local/pgsql/dataI thought the data directory was created either in the gmake install step
or initdb. Either way the chown might be better as:
No, it never was. Not sure if initdb used to create the data directory
itself, at least now it does try to do so if it doesn't exist. But if you
are going to put your data into a root-owned dir (such as
/usr/local/pgsql/data) you must create it first and change the ownership.
# chown -R postgres:postgres /usr/local/pgsql
that should be the same on most systems with perhaps the exception of the
colon. Anyway it'll make sure that all the files have the correct owners.
No. See above.
9. The previous step should have told you how to start up the database
server. Do so now.$ /usr/local/pgsql/initdb/postmaster -D /usr/local/pgsql/data
Shouldn't that be /usr/local/pgsql/bin/postmaster ??
Oops.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Jan 22 20:24:11 2000
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 UAA36227
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 20:23:15 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61536 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S393239AbQAWBWh>;
Sun, 23 Jan 2000 02:22:37 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CBqq-0003wq-00; Sun, 23 Jan 2000 02:30:00 +0100
Date: Sun, 23 Jan 2000 02:30:00 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Mike Mascari <mascarm@mascari.com>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] New INSTALL text file
In-Reply-To: <388792EF.A714B1DF@mascari.com>
Message-ID: <Pine.LNX.4.21.0001221828060.3007-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-20, Mike Mascari mentioned:
There are only two things I would want to see different. The
first is the example of running configure. Even though it is
beyond silly to think that people will interpret step 4
literally, I guarantee you some will, and will try to enter:"./configure [ options ]"
Good point.
The only other thing is if somewhere there is a mention of the -o
-F options for the backend, suggesting its possible use. Since
fsync() is on by default, many people who don't dig into the docs
and are just trying PostgreSQL to see if its a plausible solution
may dismiss it out-of-hand for performance reasons. Even though I
know robustness is the #1 criteria for a RDBMS, I personally
believe fsync() should be *off* by default, but I know I'm in the
minority.
This sounds like solicitation to bait-and-switch. As I understand it, the
official (at least as official as it gets around here) recommendation is
to leave fsynch on. Otherwise this would have to be discussed. I
furthermore believe that read only commands (SELECT) will no longer do an
fsynch in 7.0., so the incentive to turn it off is not so big anymore. ???
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Jan 22 20:24:08 2000
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 UAA36221
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 20:23:14 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61605 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S393221AbQAWBWm>;
Sun, 23 Jan 2000 02:22:42 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CBqx-0003ws-00; Sun, 23 Jan 2000 02:30:07 +0100
Date: Sun, 23 Jan 2000 02:30:07 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: prlw1@cam.ac.uk, PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [GENERAL] Variable case database names
In-Reply-To: <25186.948408703@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001230145500.3007-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-20, Tom Lane mentioned:
Peter Eisentraut <peter_e@gmx.net> writes:
There is some code in libpq which converts all database names to
lower-case, unless it's double quoted. That seems a little ill-conceived
to me,I think you are probably right. The backend might try to lowercase the
name when it gets it, but it seems like libpq shouldn't be doing so
(any more than it's responsible for downcasing identifiers used in
SQL commands).If the backend *does* lowercase the DB name used in a connect command,
is there any way to use a mixed-case DB name? I'm not sure there is...
The backend doesn't lower case it. I removed that part in libpq and now
it works fine.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Jan 22 20:24:12 2000
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 UAA36360
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 20:24:05 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62054 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S393218AbQAWBXU>;
Sun, 23 Jan 2000 02:23:20 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CBrX-0003x3-00; Sun, 23 Jan 2000 02:30:43 +0100
Date: Sun, 23 Jan 2000 02:30:43 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Status on 7.0
In-Reply-To: <3887D440.27781C9E@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.21.0001230158300.3007-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-21, Thomas Lockhart mentioned:
What I'd suggest -- and the 7.0 release is certainly one of the better
times to do this -- is to change the catalog entries to "integer",
"bigint", etc. and instead do the translation of the "deprecated" (or
"traditional", if you like) types "int4", "int8", etc. into the standard
ones.
I've also thought that we might implement some "by reference" types to
replace the "by value" types we have now (and use the SQL92 names for
them). But Tom Lane has talked about fixing up the internal problems
we have with passing info about NULLs with "by value" types, so that
might be a bad way to head. However, the downside to eliminating "by
value"s (extra footprint?) might be offset by being able to remove
code which has to handle both cases (extra speed?).
Well, rather than creating a huge potential hazard for everyone two weeks
before beta I'm going to settle for a cheaper solution (for now). There
are just too many subtleties that one would have to address early in a
devel cycle, so I'll put that on the the Forget-me-not list for 7.1.
Instead I'd suggest extending the idea of gram.y's xlateSqlType to two
functions provided by the backend
type_sql_to_internal
type_internal_to_sql
which psql and pg_dump could use. Once we switch some or all datatypes
over, this would be the only place we'd need to change -- until it's an
empty function at the end.
Comments? Better ideas?
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Jan 22 20:24:08 2000
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 UAA36358
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 20:24:04 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62208 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S372752AbQAWBX2>;
Sun, 23 Jan 2000 02:23:28 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CBrn-0003x5-00
for pgsql-hackers@postgresql.org; Sun, 23 Jan 2000 02:30:59 +0100
Date: Sun, 23 Jan 2000 02:30:59 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Not a number
Message-ID: <Pine.LNX.4.21.0001230224220.3007-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Does anyone know to what extent we do/should support Not-a-number,
Infinity, and the like for our floating point types? Are we at the mercy
of the operating system? If so, how could we ever offer this functionality
across the board on the backend level?
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Jan 22 20:37:08 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id UAA42092
for <hackers@postgreSQL.org>; Sat, 22 Jan 2000 20:36:53 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 810 invoked by uid 1001); 23 Jan 2000 01:36:52 -0000
Message-ID: <XFMail.000122203652.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 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.21.0001221804120.3007-100000@localhost.localdomain>
Date: Sat, 22 Jan 2000 20:36:52 -0500 (EST)
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: [HACKERS] New install doc
Cc: hackers@postgreSQL.org
On 23-Jan-00 Peter Eisentraut wrote:
On 2000-01-20, Vince Vielhaber mentioned:
I thought the data directory was created either in the gmake install step
or initdb. Either way the chown might be better as:No, it never was. Not sure if initdb used to create the data directory
itself, at least now it does try to do so if it doesn't exist. But if you
are going to put your data into a root-owned dir (such as
/usr/local/pgsql/data) you must create it first and change the ownership.# chown -R postgres:postgres /usr/local/pgsql
that should be the same on most systems with perhaps the exception of the
colon. Anyway it'll make sure that all the files have the correct owners.No. See above.
The reason I mentioned it is on one install where I used:
install -u postgres -g postgres
all of the directories were created ug root:wheel and the files in them
were ug postgres:postgres so I had to go back one and do the above chown.
PostgreSQL couldn't create databases.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Sat Jan 22 21:01:08 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA47894
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 21:00:58 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA83367;
Sat, 22 Jan 2000 22:01:06 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 22 Jan 2000 22:01:02 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <Pine.LNX.4.21.0001221454130.3007-100000@localhost.localdomain>
Message-ID: <Pine.BSF.4.21.0001222157570.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8BIT
Did I miss a discussion here on implementing this, and how? Sounds to me
like a week and a bit before planned beta, an *incomplete* feature has
been shoved into the source tree with zero forewarning or discussion ...
Okay, my turn here ... I vote for this to be *reverted*!!
On Sun, 23 Jan 2000, Peter Eisentraut wrote:
With caveats, it is now possible to drop columns from tables.
The implementation is based on copying the old table to a new one minus
the specified column. This procedure changes the oids of everyone
involved, so I was wondering if
a) this is a good reason to tell people to stop using oids as keys, or
b) if there is some way to keep the oids on both the records and the
pg_class entry.Is it possible/safe to specify an oid to heap_insert (like tuple->...->oid
= x) if the oid is still in use (in the old table), or would a
heap_delete({from old table}) plus heap_insert({into new table}) work.Is it possible/safe to change to oid of the new pg_class entry back to the
old one? In that case the trouble of moving over all the constraints, etc.
would be half the work.Speaking of which, the current implementation loses all constraints,
triggers, rules, comments, etc. (not defaults and notnulls
though). Therefore
1) did I forget anything in the above list
2) how do I find out if the dropped column is referenced in a constraint,
trigger, rule (this is necessary for a correct RESTRICT/CASCADE
implementation)
3) once again, is it possible/safe to do the equivalent of update pg_class
set oid=old where oid=new to save this work?Oh, btw., heaven help you if you try this on tables that are inherited
from.--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sat Jan 22 21:07:08 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA50343
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 21:06:57 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id SAA27441
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 18:06:32 -0800 (PST)
Message-Id: <3.0.1.32.20000122180428.01049040@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sat, 22 Jan 2000 18:04:28 -0800
To: pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: foreign keys?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
I've built current sources on my brand new linux box,
thought I'd try foreign key constraints since the datamodel for
the ArsDigita Community System contains hundreds of them.
Figured this might provide a bit of a stress test for the
implementation.
So...what's wrong with the following?
donb=> create table foo(i integer);
CREATE
donb=> create table bar(i integer references foo);
ERROR: FOREIGN KEY match type UNSPECIFIED not implemented yet
donb=>
This is how I'm used to doing it in Oracle. I've tried a few
permutations, what am I missing? My copy of Date is still in
Boston...
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sat Jan 22 21:09:08 2000
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 VAA50723
for <hackers@postgreSQL.org>; Sat, 22 Jan 2000 21:08:56 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id LAA23993;
Sun, 23 Jan 2000 11:08:54 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-19 [133.137.84.19])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id LAA26104;
Sun, 23 Jan 2000 11:08:52 +0900
To: vadim@krs.ru
Cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Well...
In-Reply-To: <38896A74.5C1D455B@krs.ru>
References: <38854432.54EE2F01@krs.ru> <20000122002543Q.t-ishii@sra.co.jp>
<38896A74.5C1D455B@krs.ru>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000123111103T.t-ishii@sra.co.jp>
Date: Sun, 23 Jan 2000 11:11:03 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 14
That means you are going to spend 2 or 3 months in US, then come back
I'm going to spend ~3 years in USA -:)
Oh, I didn't know that.
in April or May? I just think it would be really nice if you could
stop over Japan...Thanks! I would be glad to visit Japan sometime.
Please let me know if you would have such a chance...
--
Tatsuo Ishii
From bouncefilter Sat Jan 22 21:24:08 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA52548
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 21:23:24 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id SAA01217
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 18:23:01 -0800 (PST)
Message-Id: <3.0.1.32.20000122182057.0103fa00@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sat, 22 Jan 2000 18:20:57 -0800
To: pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: FWIW department - select avg(numeric_value)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
You might recall that I reported that this failed in
6.5.3 on RH 5.2. Tom Lane indicated that it rang a bell, possibly
being due to an endian error and asked if Jan remembered.
I don't recall Jan answering (though I might've missed an
answer).
Whatever.
I've tried this with the current sources and it works fine.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sat Jan 22 22:19:09 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA64564
for <pgsql-general@postgreSQL.org>;
Sat, 22 Jan 2000 22:19:04 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA02830;
Sat, 22 Jan 2000 22:18:13 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001230318.WAA02830@candle.pha.pa.us>
Subject: Re: [GENERAL] max(oid)
In-Reply-To: <Pine.LNX.4.21.0001221730360.3007-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 23, 2000 02:28:59 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sat, 22 Jan 2000 22:18:13 -0500 (EST)
CC: Marc Tardif <admin@wtbwts.com>, pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Got it. TODO updated.
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-01-21, Bruce Momjian mentioned:
Is there a way to use the max aggregate on an oid field? When I try on
6.5.3, I get the following error message:test=> select max(uid) from user_base;
ERROR: Unable to select an aggregate function max(oid)If there's any work-around, please let me know.
MarcAdded to TODO:
* allow aggregates on oid
We already had a TODO item for this and came to the conclusion that
* Make type equivalency apply to aggregates
will solve this.For right now the user could do the following:
INSERT INTO pg_aggregate VALUES ('max', <your user id>, 'int4larger', '-',
'-', 26, 26, 0, 26, NULL, NULL);--
Peter Eisentraut Sernanders v_g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 22 22:28:09 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA65633
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 22:28:06 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA04199;
Sat, 22 Jan 2000 22:27:11 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001230327.WAA04199@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <Pine.BSF.4.21.0001222157570.79710-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 22, 2000 10:01:02 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Sat, 22 Jan 2000 22:27:11 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Did I miss a discussion here on implementing this, and how? Sounds to me
like a week and a bit before planned beta, an *incomplete* feature has
been shoved into the source tree with zero forewarning or discussion ...Okay, my turn here ... I vote for this to be *reverted*!!
I disagree. First, it is on the TODO list, so it is open game. Second
it is not throughout all the code, it only gets activated if someone
executes the command. Third, I don't know of any time limit that
features have to be implemented a certain number of weeks _before_ beta
starts.
Everyone asks for this, and if it does only %70 of the job, that is fine
as long as the manual page says so.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 22 22:54:09 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA72461;
Sat, 22 Jan 2000 22:53:38 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id WAA66781;
Sat, 22 Jan 2000 22:33:29 -0500 (EST) (envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
Message-ID: <388A771B.FC374194@namsi.com>
From: D Herssein <denny@namsi.com>
Reply-To: denny@namsi.com
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
X-Newsgroups: comp.databases.postgresql.questions,
comp.databases.postgresql.hackers
Subject: [HELP] - Installing Postgres
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 31
Date: Sat, 22 Jan 2000 22:35:55 -0500
X-Trace: news3.mia 948598397 208.61.25.12 (Sat, 22 Jan 2000 22:33:17 EST)
To: pgsql-hackers@postgresql.org.pgsql-questions@postgresql.org
Installed the binaries with pkgadd -d <...>
When I try to run I get:
$ bin/pg_version
ld.so.1: bin/pg_version: fatal: libgen.so.1: open failed: No such file
or directory
Killed
$ uname -a
SunOS namsb 5.6 Generic_105181-16 sun4u sparc SUNW,Ultra-4
$ env
HOME=/usr/local/pgsql
HZ=100
LOGNAME=pgsql
PATH=/usr/bin::/usr/local/bin:/usr/opt/SUNWmd/sbin
SHELL=/bin/sh
TERM=vt100
TZ=US/Eastern
What am I missing?
--
Privileged/Confidential Information may be contained in this message.
If you are not the addressee indicated in this message
(or responsible for delivery of the message to such person),
you may not copy or deliver this message to anyone.
In such case, you should destroy this message and kindly notify the
sender by reply email.
Please advise immediately if you or your employer does not consent to
email
for messages of this kind. Opinions, conclusions and other information
in this message
that do not relate to the official business of New Age Media Systems
shall be understood
as neither given nor endorsed by it.
From bouncefilter Sat Jan 22 22:43:09 2000
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 WAA70743
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 22:42:12 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id WAA04981
for pgsql-hackers@postgreSQL.org; Sat, 22 Jan 2000 22:41:15 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001230341.WAA04981@candle.pha.pa.us>
Subject: Refusing patches
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Sat, 22 Jan 2000 22:41:15 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have noticed some people are complaining about patches being applied.
I feel this is very discouraging to the people who submit them.
I apply patches as soon as I seem them, assuming they look OK. We
always have the ability to back them out later.
What I am seeing is people voting for people to reverse out patches
without giving the patch submitter a chance to address any concerns. I
think we owe our patch submitters the dignity of having a chance to
respond to criticism of the patches before anyone suggests yanking a
patch.
I have rejected patches in the past, but I usually tell the person what
I don't like about the patch, and encourage them to resubmit the patch
with the suggested changes.
Sometime, I even apply the patch, but tell the submitter they have to
give me the fixes I requested. If they don't arrive in a few days, then
I reverse out the patch. Sometimes it is easier for people to fix what
they have already done than to submit a totally new patch.
Of course, this is all my personal opinion.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 22 22:46:09 2000
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 WAA71188
for <pgsql-hackers@postgresql.org>;
Sat, 22 Jan 2000 22:45:38 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id MAA25459
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 12:45:37 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-23 [133.137.84.23])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id MAA26418
for <pgsql-hackers@postgresql.org>; Sun, 23 Jan 2000 12:45:36 +0900
To: pgsql-hackers@postgresql.org
Subject: char_length()?
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000123124747W.t-ishii@sra.co.jp>
Date: Sun, 23 Jan 2000 12:47:47 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 27
char_length()/octet_length() for char() datatype returns a character
length *except* the trailing blanks. Is this what the standard
expects? Oracle's length() returns 3 in the case below.
test=> create table t2 (c char(3));
CREATE
test=> insert into t2 values('c');
INSERT 277385 1
test=> select * from t2;
c
-----
c
(1 row)
test=> select char_length(c) from t2;
length
--------
1
(1 row)
test=> select octet_length(c) from t2;
octet_length
--------------
1
(1 row)
--
Tatsuo Ishii
From bouncefilter Sat Jan 22 22:50:10 2000
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 WAA71712
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 22:49:34 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA05444;
Sat, 22 Jan 2000 22:48:15 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001230348.WAA05444@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <Pine.LNX.4.21.0001221454130.3007-100000@localhost.localdomain>
from Peter Eisentraut at "Jan 23, 2000 02:29:42 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sat, 22 Jan 2000 22:48:15 -0500 (EST)
CC: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
With caveats, it is now possible to drop columns from tables.
The implementation is based on copying the old table to a new one minus
the specified column. This procedure changes the oids of everyone
involved, so I was wondering if
a) this is a good reason to tell people to stop using oids as keys, or
b) if there is some way to keep the oids on both the records and the
pg_class entry.
Actually CLUSTER has the same problem, I think. It may be even worse
because it drops all indexes. Can you take a look at that code too.
Some people have reported problems with it, while others are OK. There
is a cluster TODO mail file in the source tree. It shows an actual bug
that still exists, plus some other issues with cluster.
Not sure how to deal with this. I think our whole OID system is messed
up because you can't update the OID column in a table. That is very
limiting, and some commands like cluster lose oids. I think we need a
full OID discussion on how to move forward with them.
Why not allow heap_insert to receive the oid as a parameter. It may
help with cluster too. Seems like a great idea!
Is it possible/safe to change to oid of the new pg_class entry back to the
old one? In that case the trouble of moving over all the constraints, etc.
would be half the work.
I don't know. I don't see any reason we can't handle that.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 22 22:50:09 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA71829
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 22:50:07 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA04677;
Sat, 22 Jan 2000 22:49:42 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-reply-to: <200001230327.WAA04199@candle.pha.pa.us>
References: <200001230327.WAA04199@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sat, 22 Jan 2000 22:27:11 -0500"
Date: Sat, 22 Jan 2000 22:49:42 -0500
Message-ID: <4674.948599382@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Okay, my turn here ... I vote for this to be *reverted*!!
I disagree. First, it is on the TODO list, so it is open game. Second
it is not throughout all the code, it only gets activated if someone
executes the command. Third, I don't know of any time limit that
features have to be implemented a certain number of weeks _before_ beta
starts.
I agree with Bruce. There's no risk of this breaking anything else,
AFAICT, so if it doesn't work there's no harm done. I hope Peter is
going to clean it up more before beta, but why shouldn't he push out
what he has for review and criticism?
I'm busy committing changes in areas that are considerably more critical
than this is, so if the rule is going to be "no risk taken for N weeks
*before* beta", better tell me about it...
regards, tom lane
From bouncefilter Sat Jan 22 23:17:09 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA78989
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 23:16:50 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA04744;
Sat, 22 Jan 2000 23:16:18 -0500 (EST)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] char_length()?
In-reply-to: <20000123124747W.t-ishii@sra.co.jp>
References: <20000123124747W.t-ishii@sra.co.jp>
Comments: In-reply-to Tatsuo Ishii <t-ishii@sra.co.jp>
message dated "Sun, 23 Jan 2000 12:47:47 +0900"
Date: Sat, 22 Jan 2000 23:16:17 -0500
Message-ID: <4741.948600977@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
char_length()/octet_length() for char() datatype returns a character
length *except* the trailing blanks. Is this what the standard
expects? Oracle's length() returns 3 in the case below.
AFAICT Oracle is right --- the spec just says
i) If the data type of S is a character data type, then the
result is the number of characters in the value of S.
and I can't see anything there about stripping pad characters. You
could ask for length(trim(S)) if you don't want to count blanks.
regards, tom lane
From bouncefilter Sat Jan 22 23:25:10 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA79918
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 23:24:48 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id AAA84407;
Sun, 23 Jan 2000 00:23:16 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 23 Jan 2000 00:23:16 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <4674.948599382@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001230017180.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 22 Jan 2000, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Okay, my turn here ... I vote for this to be *reverted*!!
I disagree. First, it is on the TODO list, so it is open game. Second
it is not throughout all the code, it only gets activated if someone
executes the command. Third, I don't know of any time limit that
features have to be implemented a certain number of weeks _before_ beta
starts.I agree with Bruce. There's no risk of this breaking anything else,
AFAICT, so if it doesn't work there's no harm done. I hope Peter is
going to clean it up more before beta, but why shouldn't he push out
what he has for review and criticism?
Why didn't I just take Alfred's stuff and shove it into the source tree
and let the bricks fall where they may? As far as I am/was concerned, the
ramifications of the changes were so great that *some* discussion should
have happened before hand ...
I'm one of those that would love to have an ALTER TABLE ... DROP COLUMN
implementation, but how many applications will get broken because OID are
no longer retained? If it had been brought up and discussed before being
thrown in, like everyone else has done in the past, maybe a better
solution could have presented itself ...
I'm busy committing changes in areas that are considerably more critical
than this is, so if the rule is going to be "no risk taken for N weeks
*before* beta", better tell me about it...
Its not the *risk* that bothers me, its the lack of discussions ... IMHO,
he should have brought up the "I'm in the process of toasting the reliance
on OIDs" topic *before* implementing it ... give other ppl a chance to
possibly present alternatives ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sat Jan 22 23:27:10 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA80218
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 23:26:51 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA06789;
Sat, 22 Jan 2000 23:26:32 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001230426.XAA06789@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <200001230348.WAA05444@candle.pha.pa.us> from Bruce Momjian at
"Jan 22, 2000 10:48:15 pm"
To: Bruce Momjian <pgman@candle.pha.pa.us>
Date: Sat, 22 Jan 2000 23:26:32 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
With caveats, it is now possible to drop columns from tables.
The implementation is based on copying the old table to a new one minus
the specified column. This procedure changes the oids of everyone
involved, so I was wondering if
a) this is a good reason to tell people to stop using oids as keys, or
b) if there is some way to keep the oids on both the records and the
pg_class entry.Actually CLUSTER has the same problem, I think. It may be even worse
because it drops all indexes. Can you take a look at that code too.
Some people have reported problems with it, while others are OK. There
is a cluster TODO mail file in the source tree. It shows an actual bug
that still exists, plus some other issues with cluster.
I wonder if we should throw out a NOTICE when we drop some
characteristic of a table?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Jan 22 23:39:10 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA85429
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 23:38:32 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA04779;
Sat, 22 Jan 2000 23:38:11 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-reply-to: <Pine.LNX.4.21.0001221454130.3007-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001221454130.3007-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Sun, 23 Jan 2000 02:29:42 +0100"
Date: Sat, 22 Jan 2000 23:38:11 -0500
Message-ID: <4776.948602291@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
With caveats, it is now possible to drop columns from tables.
The implementation is based on copying the old table to a new one minus
the specified column. This procedure changes the oids of everyone
involved, so I was wondering if
a) this is a good reason to tell people to stop using oids as keys,
AFAIK there is nothing particularly magic about OIDs. You could
perfectly well create the new table with the same OIDs as are in the
old table (see COPY WITH OIDS if you are wondering how).
User-level stuff like referential integrity triggers might get unhappy,
but you're not going to let triggers see what you're doing, right ;-) ?
Is it possible/safe to change to oid of the new pg_class entry back to the
old one? In that case the trouble of moving over all the constraints, etc.
would be half the work.
Wrong way to think about it. You should be doing a heap_update of the
catalog tuples that need to change, ISTM.
You could almost get away with doing it like you describe, except that
there is a unique index on pg_class OIDs these days (right, Bruce?)
and that index will kick out an error. But heap_update on the original
table tuple will work.
I think what we may want here is something comparable to what's been
discussed recently for VACUUM: build the new table as a new heap file
and then rename the physical file into place, without really doing
anything to the pg_class tuple --- except of course you'd need to
heap_update it to adjust the number-of-attributes field.
2) how do I find out if the dropped column is referenced in a constraint,
trigger, rule (this is necessary for a correct RESTRICT/CASCADE
implementation)
Actually it's worse than that: you need to be prepared to renumber the
columns after the dropped one, too. Probably what you will need to do
is read in and deparse all the relevant rules and triggers, then reparse
them against the updated table schema. Ugly. And no, I have no idea
how you even *find* all the relevant rules. (Jan?)
Oh, btw., heaven help you if you try this on tables that are inherited
from.
The whole thing should be done inside a recursive routine that applies
the same change to all children of the target table. See ALTER TABLE
ADD COLUMN for an example. (ADD COLUMN is pretty broken too, since it
doesn't preserve consistency of column numbering across child tables ---
want to reimplement it in this same style?)
regards, tom lane
From bouncefilter Sat Jan 22 23:46:10 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA89204
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 23:46:03 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id UAA06058;
Sat, 22 Jan 2000 20:45:19 -0800 (PST)
Message-Id: <3.0.1.32.20000122203914.01053db0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sat, 22 Jan 2000 20:39:14 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>,
The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Happy column dropping
Cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <200001230327.WAA04199@candle.pha.pa.us>
References: <Pine.BSF.4.21.0001222157570.79710-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 10:27 PM 1/22/00 -0500, Bruce Momjian wrote:
Did I miss a discussion here on implementing this, and how? Sounds to me
like a week and a bit before planned beta, an *incomplete* feature has
been shoved into the source tree with zero forewarning or discussion ...Okay, my turn here ... I vote for this to be *reverted*!!
I disagree. First, it is on the TODO list, so it is open game. Second
it is not throughout all the code, it only gets activated if someone
executes the command. Third, I don't know of any time limit that
features have to be implemented a certain number of weeks _before_ beta
starts.Everyone asks for this, and if it does only %70 of the job, that is fine
as long as the manual page says so.
I'm sorry, but his current hack results in silent failures.
Personally, I think he should've asked for answers to his questions
first - i.e., how do you find out which relations are subject to
foreign key restraints (implemented via triggers)?
Allowing one to drop columns with silent failure is hardly the
hallmark of a professional piece of software. What has impressed me
about the Postgres effort in the year that I've been tracking it (though
sadly not contributing to it), has been the concentration on professional
implementation of features, and the concentration on improving stability
and reliability.
"copy to a table, drop the column, copy back" - heck, I could do that
with a script file to be fed into psql. An internal implementation has
to be far better to be considered a piece of a professional RDBMS, I'm
afraid.
I'm not saying that this isn't the proper basis for the feature, only
that sure, that's easy to do internally or externally, and that isn't
the problem.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sat Jan 22 23:51:12 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA89906
for <pgsql-hackers@postgreSQL.org>;
Sat, 22 Jan 2000 23:50:44 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id VAA10180;
Sat, 22 Jan 2000 21:14:27 -0800 (PST)
Date: Sat, 22 Jan 2000 21:14:27 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, prlw1@cam.ac.uk,
pgsql-hackers@postgreSQL.org
Subject: pg_dump possible fix,
need testers. (was: Re: [HACKERS] pg_dump disaster)
Message-ID: <20000122211427.C26520@fw.wintelcom.net>
References: <3456.948431421@sss.pgh.pa.us>
<200001210549.AAA13736@candle.pha.pa.us>
<20000121010305.K14030@fw.wintelcom.net>
<4769.948469442@sss.pgh.pa.us>
<20000121134638.U14030@fw.wintelcom.net>
<9725.948492343@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <9725.948492343@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Fri, Jan 21, 2000 at 05:05:43PM -0500
* Tom Lane <tgl@sss.pgh.pa.us> [000121 14:35] wrote:
Alfred Perlstein <bright@wintelcom.net> writes:
We both missed it, and yes it was my fault. All connections are
behaving as if PQsetnonblocking(conn, TRUE) have been called on them.
The original non-blocking patches did something weird, they seemed
to _always_ stick the socket into non-blocking mode. This would
activate my non-blocking stuff for all connections.Yes, the present state of the code seems to activate nonblocking socket
mode all the time; possibly we could band-aid our way back to a working
psql by turning off nonblock mode by default. But this doesn't address
the fact that the API of these routines cannot support nonblock mode
without being redesigned.
These patches revert the default setting of the non-block flag back
to the old way connections were done. Since i'm unable to reproduce
this bug I'm hoping people can _please_ give me feedback.
This is just a first shot at fixing the issue, I'll supply changes
to the docs if this all goes well (that you must explicitly set the
blocking status after a connect/disconnect)
I'm a bit concerned about busy looping because the connection is
left in a non-blocking state after the connect, however most of
the code performs select() and checks for EWOULDBLOCK/EAGAIN so it
might not be an issue.
Thanks for holding off on backing out the changes.
Summary:
don't set the nonblock flag during connections
PQsetnonblocking doesn't fiddle with socket flags anymore as the library
seems to be setup to deal with the socket being in non-block mode at
all times
turn off the nonblock flag if/when the connection is torn down to ensure
that a reconnect behaves like it used to.
Index: fe-connect.c
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.114
diff -u -c -I$Header: -r1.114 fe-connect.c
cvs diff: conflicting specifications of output style
*** fe-connect.c 2000/01/23 01:27:39 1.114
--- fe-connect.c 2000/01/23 08:56:17
***************
*** 391,397 ****
PGconn *conn;
char *tmp; /* An error message from some service we call. */
bool error = FALSE; /* We encountered an error. */
- int i; conn = makeEmptyPGconn();
if (conn == NULL)
--- 391,396 ----
***************
*** 586,591 ****
--- 585,614 ----
} /* ----------
+ * connectMakeNonblocking -
+ * Make a connection non-blocking.
+ * Returns 1 if successful, 0 if not.
+ * ----------
+ */
+ static int
+ connectMakeNonblocking(PGconn *conn)
+ {
+ #ifndef WIN32
+ if (fcntl(conn->sock, F_SETFL, O_NONBLOCK) < 0)
+ #else
+ if (ioctlsocket(conn->sock, FIONBIO, &on) != 0)
+ #endif
+ {
+ printfPQExpBuffer(&conn->errorMessage,
+ "connectMakeNonblocking -- fcntl() failed: errno=%d\n%s\n",
+ errno, strerror(errno));
+ return 0;
+ }
+
+ return 1;
+ }
+
+ /* ----------
* connectNoDelay -
* Sets the TCP_NODELAY socket option.
* Returns 1 if successful, 0 if not.
***************
*** 755,761 ****
* Ewan Mellor <eem21@cam.ac.uk>.
* ---------- */
#if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL)
! if (PQsetnonblocking(conn, TRUE) != 0)
goto connect_errReturn;
#endif --- 778,784 ----
* Ewan Mellor <eem21@cam.ac.uk>.
* ---------- */
#if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL)
! if (connectMakeNonblocking(conn) == 0)
goto connect_errReturn;
#endif ***************
*** 868,874 ****
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (PQsetnonblocking(conn, TRUE) != 0)
goto connect_errReturn;
#endif
--- 891,897 ----
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (connectMakeNonblocking(conn) == 0)
goto connect_errReturn;
#endif ***************
*** 1785,1790 ****
--- 1808,1820 ----
(void) pqPuts("X", conn);
(void) pqFlush(conn);
}
+
+ /*
+ * must reset the blocking status so a possible reconnect will work
+ * don't call PQsetnonblocking() because it will fail if it's unable
+ * to flush the connection.
+ */
+ conn->nonblocking = FALSE; /*
* Close the connection, reset all transient state, flush I/O buffers.
Index: fe-exec.c
===================================================================
RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-exec.c,v
retrieving revision 1.87
diff -u -c -I$Header: -r1.87 fe-exec.c
cvs diff: conflicting specifications of output style
*** fe-exec.c 2000/01/18 06:09:24 1.87
--- fe-exec.c 2000/01/23 08:56:29
***************
*** 2116,2122 ****
int
PQsetnonblocking(PGconn *conn, int arg)
{
- int fcntlarg; arg = (arg == TRUE) ? 1 : 0;
/* early out if the socket is already in the state requested */
--- 2116,2121 ----
***************
*** 2131,2174 ****
* _from_ or _to_ blocking mode, either way we can block them.
*/
/* if we are going from blocking to non-blocking flush here */
! if (!pqIsnonblocking(conn) && pqFlush(conn))
! return (-1);
!
!
! #ifdef USE_SSL
! if (conn->ssl)
! {
! printfPQExpBuffer(&conn->errorMessage,
! "PQsetnonblocking() -- not supported when using SSL\n");
! return (-1);
! }
! #endif /* USE_SSL */
!
! #ifndef WIN32
! fcntlarg = fcntl(conn->sock, F_GETFL, 0);
! if (fcntlarg == -1)
! return (-1);
!
! if ((arg == TRUE &&
! fcntl(conn->sock, F_SETFL, fcntlarg | O_NONBLOCK) == -1) ||
! (arg == FALSE &&
! fcntl(conn->sock, F_SETFL, fcntlarg & ~O_NONBLOCK) == -1))
! #else
! fcntlarg = arg;
! if (ioctlsocket(conn->sock, FIONBIO, &fcntlarg) != 0)
! #endif
! {
! printfPQExpBuffer(&conn->errorMessage,
! "PQsetblocking() -- unable to set nonblocking status to %s\n",
! arg == TRUE ? "TRUE" : "FALSE");
return (-1);
- } conn->nonblocking = arg;
-
- /* if we are going from non-blocking to blocking flush here */
- if (pqIsnonblocking(conn) && pqFlush(conn))
- return (-1);
return (0);
}
--- 2130,2139 ----
* _from_ or _to_ blocking mode, either way we can block them.
*/
/* if we are going from blocking to non-blocking flush here */
! if (pqFlush(conn))
return (-1);conn->nonblocking = arg;
return (0);
}
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
From bouncefilter Sun Jan 23 00:28:11 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA97313
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 00:27:08 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA08020;
Sun, 23 Jan 2000 00:25:57 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001230525.AAA08020@candle.pha.pa.us>
Subject: Re: pg_dump possible fix, need testers. (was: Re: [HACKERS] pg_dump
disaster)
In-Reply-To: <20000122211427.C26520@fw.wintelcom.net> from Alfred Perlstein at
"Jan 22, 2000 09:14:27 pm"
To: Alfred Perlstein <bright@wintelcom.net>
Date: Sun, 23 Jan 2000 00:25:57 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, prlw1@cam.ac.uk,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Patch appled. And thanks very much for the patch. I am sorry you were
given a bad time about your previous patch. We will try to not let it
happen again.
These patches revert the default setting of the non-block flag back
to the old way connections were done. Since i'm unable to reproduce
this bug I'm hoping people can _please_ give me feedback.This is just a first shot at fixing the issue, I'll supply changes
to the docs if this all goes well (that you must explicitly set the
blocking status after a connect/disconnect)I'm a bit concerned about busy looping because the connection is
left in a non-blocking state after the connect, however most of
the code performs select() and checks for EWOULDBLOCK/EAGAIN so it
might not be an issue.Thanks for holding off on backing out the changes.
Summary:
don't set the nonblock flag during connections
PQsetnonblocking doesn't fiddle with socket flags anymore as the library
seems to be setup to deal with the socket being in non-block mode at
all times
turn off the nonblock flag if/when the connection is torn down to ensure
that a reconnect behaves like it used to.Index: fe-connect.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-connect.c,v retrieving revision 1.114 diff -u -c -I$Header: -r1.114 fe-connect.c cvs diff: conflicting specifications of output style *** fe-connect.c 2000/01/23 01:27:39 1.114 --- fe-connect.c 2000/01/23 08:56:17 *************** *** 391,397 **** PGconn *conn; char *tmp; /* An error message from some service we call. */ bool error = FALSE; /* We encountered an error. */ - int i;conn = makeEmptyPGconn(); if (conn == NULL) --- 391,396 ---- *************** *** 586,591 **** --- 585,614 ---- }/* ---------- + * connectMakeNonblocking - + * Make a connection non-blocking. + * Returns 1 if successful, 0 if not. + * ---------- + */ + static int + connectMakeNonblocking(PGconn *conn) + { + #ifndef WIN32 + if (fcntl(conn->sock, F_SETFL, O_NONBLOCK) < 0) + #else + if (ioctlsocket(conn->sock, FIONBIO, &on) != 0) + #endif + { + printfPQExpBuffer(&conn->errorMessage, + "connectMakeNonblocking -- fcntl() failed: errno=%d\n%s\n", + errno, strerror(errno)); + return 0; + } + + return 1; + } + + /* ---------- * connectNoDelay - * Sets the TCP_NODELAY socket option. * Returns 1 if successful, 0 if not. *************** *** 755,761 **** * Ewan Mellor <eem21@cam.ac.uk>. * ---------- */ #if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL) ! if (PQsetnonblocking(conn, TRUE) != 0) goto connect_errReturn; #endif--- 778,784 ---- * Ewan Mellor <eem21@cam.ac.uk>. * ---------- */ #if (!defined(WIN32) || defined(WIN32_NON_BLOCKING_CONNECTIONS)) && !defined(USE_SSL) ! if (connectMakeNonblocking(conn) == 0) goto connect_errReturn; #endif***************
*** 868,874 ****
/* This makes the connection non-blocking, for all those cases which forced us
not to do it above. */
#if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL)
! if (PQsetnonblocking(conn, TRUE) != 0)
goto connect_errReturn;
#endif--- 891,897 ---- /* This makes the connection non-blocking, for all those cases which forced us not to do it above. */ #if (defined(WIN32) && !defined(WIN32_NON_BLOCKING_CONNECTIONS)) || defined(USE_SSL) ! if (connectMakeNonblocking(conn) == 0) goto connect_errReturn; #endif*************** *** 1785,1790 **** --- 1808,1820 ---- (void) pqPuts("X", conn); (void) pqFlush(conn); } + + /* + * must reset the blocking status so a possible reconnect will work + * don't call PQsetnonblocking() because it will fail if it's unable + * to flush the connection. + */ + conn->nonblocking = FALSE;/* * Close the connection, reset all transient state, flush I/O buffers. Index: fe-exec.c =================================================================== RCS file: /home/pgcvs/pgsql/src/interfaces/libpq/fe-exec.c,v retrieving revision 1.87 diff -u -c -I$Header: -r1.87 fe-exec.c cvs diff: conflicting specifications of output style *** fe-exec.c 2000/01/18 06:09:24 1.87 --- fe-exec.c 2000/01/23 08:56:29 *************** *** 2116,2122 **** int PQsetnonblocking(PGconn *conn, int arg) { - int fcntlarg;arg = (arg == TRUE) ? 1 : 0; /* early out if the socket is already in the state requested */ --- 2116,2121 ---- *************** *** 2131,2174 **** * _from_ or _to_ blocking mode, either way we can block them. */ /* if we are going from blocking to non-blocking flush here */ ! if (!pqIsnonblocking(conn) && pqFlush(conn)) ! return (-1); ! ! ! #ifdef USE_SSL ! if (conn->ssl) ! { ! printfPQExpBuffer(&conn->errorMessage, ! "PQsetnonblocking() -- not supported when using SSL\n"); ! return (-1); ! } ! #endif /* USE_SSL */ ! ! #ifndef WIN32 ! fcntlarg = fcntl(conn->sock, F_GETFL, 0); ! if (fcntlarg == -1) ! return (-1); ! ! if ((arg == TRUE && ! fcntl(conn->sock, F_SETFL, fcntlarg | O_NONBLOCK) == -1) || ! (arg == FALSE && ! fcntl(conn->sock, F_SETFL, fcntlarg & ~O_NONBLOCK) == -1)) ! #else ! fcntlarg = arg; ! if (ioctlsocket(conn->sock, FIONBIO, &fcntlarg) != 0) ! #endif ! { ! printfPQExpBuffer(&conn->errorMessage, ! "PQsetblocking() -- unable to set nonblocking status to %s\n", ! arg == TRUE ? "TRUE" : "FALSE"); return (-1); - }conn->nonblocking = arg;
-
- /* if we are going from non-blocking to blocking flush here */
- if (pqIsnonblocking(conn) && pqFlush(conn))
- return (-1);return (0); } --- 2130,2139 ---- * _from_ or _to_ blocking mode, either way we can block them. */ /* if we are going from blocking to non-blocking flush here */ ! if (pqFlush(conn)) return (-1);conn->nonblocking = arg;
return (0);
}--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 00:28:10 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA97353
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 00:27:39 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA04955;
Sun, 23 Jan 2000 00:27:32 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-reply-to: <200001230426.XAA06789@candle.pha.pa.us>
References: <200001230426.XAA06789@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sat, 22 Jan 2000 23:26:32 -0500"
Date: Sun, 23 Jan 2000 00:27:32 -0500
Message-ID: <4952.948605252@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I wonder if we should throw out a NOTICE when we drop some
characteristic of a table?
The problem is mostly that the code doesn't even *know* that it's
dropping data. If we add code to find the info that's getting lost,
it's probably little more work to add code to copy it.
I'm of two minds about this. Peter is an energetic new contributor
and we'd be really foolish to discourage him (I was there not very
long ago myself). And a limited DROP COLUMN capability is better
than none at all, so long as its limitations are well-documented.
OTOH, I understand Don Baccus' concern: Postgres is on the cusp of
being considered professional-grade software --- we are competing
against multi-K-dollar commercial offerings --- and we jeopardize
that perception if we add features that are less than fully baked.
This is definitely in the 50%-baked category...
regards, tom lane
From bouncefilter Sun Jan 23 00:43:11 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id AAA02835
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 00:42:47 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 1319 invoked by uid 1001); 23 Jan 2000 05:42:45 -0000
Message-ID: <XFMail.000123004245.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <4952.948605252@sss.pgh.pa.us>
Date: Sun, 23 Jan 2000 00:42:45 -0500 (EST)
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: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] Happy column dropping
Cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>,
Bruce Momjian <pgman@candle.pha.pa.us>
On 23-Jan-00 Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I wonder if we should throw out a NOTICE when we drop some
characteristic of a table?The problem is mostly that the code doesn't even *know* that it's
dropping data. If we add code to find the info that's getting lost,
it's probably little more work to add code to copy it.I'm of two minds about this. Peter is an energetic new contributor
and we'd be really foolish to discourage him (I was there not very
long ago myself). And a limited DROP COLUMN capability is better
than none at all, so long as its limitations are well-documented.OTOH, I understand Don Baccus' concern: Postgres is on the cusp of
being considered professional-grade software --- we are competing
against multi-K-dollar commercial offerings --- and we jeopardize
that perception if we add features that are less than fully baked.
This is definitely in the 50%-baked category...
So why not ./configure --enable-experimental
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Sun Jan 23 00:54:11 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA04476
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 00:54:09 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA05123;
Sun, 23 Jan 2000 00:53:58 -0500 (EST)
To: Alfred Perlstein <bright@wintelcom.net>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, prlw1@cam.ac.uk,
pgsql-hackers@postgreSQL.org
Subject: Re: pg_dump possible fix,
need testers. (was: Re: [HACKERS] pg_dump disaster)
In-reply-to: <20000122220256.H26520@fw.wintelcom.net>
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
Comments: In-reply-to Alfred Perlstein <bright@wintelcom.net>
message dated "Sat, 22 Jan 2000 22:02:56 -0800"
Date: Sun, 23 Jan 2000 00:53:57 -0500
Message-ID: <5120.948606837@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Alfred Perlstein <bright@wintelcom.net> writes:
I really hope the originator of the problem report will get back to
us to make sure it's settled.
*poking Patrick Welche*
Um, I didn't have any trouble at all reproducing Patrick's complaint.
pg_dump any moderately large table (I used tenk1 from the regress
database) and try to load the script with psql. Kaboom.
Also, I still say that turning off nonblock mode by default is only
a band-aid: this code *will fail* whenever nonblock mode is enabled,
because it does not return enough info to the caller to allow the
caller to do the right thing. If you haven't seen it fail, that
only proves that you haven't actually stressed it to the point of
exercising the buffer-overrun code paths.
regards, tom lane
From bouncefilter Sun Jan 23 00:59:11 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA05045
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 00:58:34 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id BAA84935;
Sun, 23 Jan 2000 01:58:30 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 23 Jan 2000 01:58:30 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <4952.948605252@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001230153250.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 23 Jan 2000, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I wonder if we should throw out a NOTICE when we drop some
characteristic of a table?The problem is mostly that the code doesn't even *know* that it's
dropping data. If we add code to find the info that's getting lost,
it's probably little more work to add code to copy it.I'm of two minds about this. Peter is an energetic new contributor
and we'd be really foolish to discourage him (I was there not very
long ago myself). And a limited DROP COLUMN capability is better
than none at all, so long as its limitations are well-documented.
IMHO, put out a BIG NOTICE if someone issues the DROP COLUMN command:
Do not expect your table to look like what you used to have!!
This has nothing to do with discouraging a contributor ... this has to do
with maintaining QA through peer-review ... it would have taken Peter *as
long* to send his note out 24hrs *before* commiting the changes and would
have at least spur'd on a possible discussion of a better way of dealign
with the whole OID situation ...
Look at the last major patch we threw in from Alfred ... he posted and
asked for comments ... Tom, I believe it was you that send back a few
concerns ... he addressed them and posted for review a *second* time
before we committed it. After committing, we found a bug ... someone else
wanted to revert that patch, but *at that point* it would have been
inappropriate to do, since it had been reviewed twice and considered good
for inclusion ... if Alfred couldn't have fixed the problem adequately
after a few days, okay, then revert it, but at least give him a chance to
fix that which he wrought ...
In Peter's case, there was no review ... just slap it in and pray ;(
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 23 00:39:11 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA02376
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 00:39:08 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id WAA11360;
Sat, 22 Jan 2000 22:02:56 -0800 (PST)
Date: Sat, 22 Jan 2000 22:02:56 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, prlw1@cam.ac.uk,
pgsql-hackers@postgreSQL.org
Subject: Re: pg_dump possible fix,
need testers. (was: Re: [HACKERS] pg_dump disaster)
Message-ID: <20000122220256.H26520@fw.wintelcom.net>
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200001230525.AAA08020@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Sun, Jan 23, 2000 at 12:25:57AM
-0500
* Bruce Momjian <pgman@candle.pha.pa.us> [000122 21:50] wrote:
These patches revert the default setting of the non-block flag back
to the old way connections were done. Since i'm unable to reproduce
this bug I'm hoping people can _please_ give me feedback.Patch appled. And thanks very much for the patch. I am sorry you were
given a bad time about your previous patch. We will try to not let it
happen again.
I really hope the originator of the problem report will get back to
us to make sure it's settled.
*poking Patrick Welche*
:)
thanks,
-Alfred
From bouncefilter Sun Jan 23 01:43:11 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA20836
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 01:42:40 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id XAA12949;
Sat, 22 Jan 2000 23:05:11 -0800 (PST)
Date: Sat, 22 Jan 2000 23:05:11 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, prlw1@cam.ac.uk,
pgsql-hackers@postgreSQL.org
Subject: Re: pg_dump possible fix,
need testers. (was: Re: [HACKERS] pg_dump disaster)
Message-ID: <20000122230510.I26520@fw.wintelcom.net>
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
<5120.948606837@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <5120.948606837@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Sun, Jan 23, 2000 at 12:53:57AM -0500
* Tom Lane <tgl@sss.pgh.pa.us> [000122 22:17] wrote:
Alfred Perlstein <bright@wintelcom.net> writes:
I really hope the originator of the problem report will get back to
us to make sure it's settled.*poking Patrick Welche*
Um, I didn't have any trouble at all reproducing Patrick's complaint.
pg_dump any moderately large table (I used tenk1 from the regress
database) and try to load the script with psql. Kaboom.
Can you try it on sources from before my initial patches were
applied, and from before the initial non-blocking connections
patches from Ewan Mellor were applied?
From my point of view none of my code should be affecting those that
don't explicitly use PQsetnonblocking(), which is nothing besides
the application i'm developing in-house.
I'm currently investigating that possibility.
thanks,
-Alfred
From bouncefilter Sun Jan 23 03:15:12 2000
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 DAA44718
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 03:14:27 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id RAA29997;
Sun, 23 Jan 2000 17:14:26 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-2 [133.137.84.2])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id RAA27493;
Sun, 23 Jan 2000 17:14:24 +0900
To: tgl@sss.pgh.pa.us
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] char_length()?
In-Reply-To: <4741.948600977@sss.pgh.pa.us>
References: <20000123124747W.t-ishii@sra.co.jp> <4741.948600977@sss.pgh.pa.us>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000123171635Q.t-ishii@sra.co.jp>
Date: Sun, 23 Jan 2000 17:16:35 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 20
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
char_length()/octet_length() for char() datatype returns a character
length *except* the trailing blanks. Is this what the standard
expects? Oracle's length() returns 3 in the case below.AFAICT Oracle is right --- the spec just says
i) If the data type of S is a character data type, then the
result is the number of characters in the value of S.and I can't see anything there about stripping pad characters. You
could ask for length(trim(S)) if you don't want to count blanks.
Ok, I have committed fixes for this. Maybe we should add this
incompatible changes to the release note:
char_length()/octet_length() for the char() datatype now returns a
character length (or byte length) including the trailing blanks.
--
Tatsuo Ishii
From bouncefilter Sun Jan 23 03:19:12 2000
Received: from homeworld.bigpanda.org
(IDENT:root@client-151-198-27-104.bellatlantic.net [151.198.27.104])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA45155
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 03:18:49 -0500 (EST)
(envelope-from acroyear@homeworld.bigpanda.org)
Received: from homeworld.bigpanda.org (IDENT:acroyear@localhost.awc.net
[127.0.0.1])
by homeworld.bigpanda.org (8.9.3/8.9.3) with ESMTP id DAA19404;
Sun, 23 Jan 2000 03:17:03 -0500
Message-Id: <200001230817.DAA19404@homeworld.bigpanda.org>
To: Don Baccus <dhogaza@pacifier.com>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] foreign keys?
In-Reply-To: Your message of "Sat, 22 Jan 2000 18:04:28 PST."
<3.0.1.32.20000122180428.01049040@mail.pacifier.com>
Date: Sun, 23 Jan 2000 03:17:03 -0500
From: acroyear@bigpanda.com
I've built current sources on my brand new linux box,
thought I'd try foreign key constraints since the datamodel for
the ArsDigita Community System contains hundreds of them.
Figured this might provide a bit of a stress test for the
implementation.So...what's wrong with the following?
donb=> create table foo(i integer);
CREATE
donb=> create table bar(i integer references foo);
ERROR: FOREIGN KEY match type UNSPECIFIED not implemented yet
donb=>This is how I'm used to doing it in Oracle. I've tried a few
permutations, what am I missing? My copy of Date is still in
Boston...
As of the last snapshot I downloaded, only MATCH FULL was
implemented fully and I think postgres will only be happy
if you specify the column list or table foo has a primary key.
create table bar(i integer references foo(i) match full);
That seems to work, although by the way I read the spec, I'm
not sure that it should since there is no unique constraint
specified on foo(i).
From bouncefilter Sun Jan 23 04:34:13 2000
Received: from flex.flex.ro (IDENT:root@[193.230.255.4])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA60583
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 04:33:26 -0500 (EST) (envelope-from teo@flex.ro)
Received: from flex.ro (IDENT:teo@teo.flex.ro [193.230.255.3])
by flex.flex.ro (8.9.3/8.9.3) with ESMTP id MAA01751
for <pgsql-hackers@postgreSQL.org>; Sun, 23 Jan 2000 12:36:59 +0200
Sender: teo@flex.flex.ro
Message-ID: <388ACAFF.5BF4EB6E@flex.ro>
Date: Sun, 23 Jan 2000 11:33:51 +0200
From: Constantin Teodorescu <teo@flex.ro>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Unique constraint for inherited tables?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I am defining a table t1 with a NOT NULL field f1 and UNIQUE field f2.
(it automatically defines t1_f2_key unique index)
I am defining now a new table t2 that inherits t1 table and add some
columns.
The NOT NULL constraint is preserved for f1 field, the UNIQUE for f2 not
(the index t2_f2_key) is not defined.
Wouldn't be normal that the unique constraint to be inherited also in
t2?
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA
From bouncefilter Sun Jan 23 04:56:13 2000
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 EAA62120
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 04:55:18 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id EAA15266
for pgsql-hackers@postgreSQL.org; Sun, 23 Jan 2000 04:40:18 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001230940.EAA15266@candle.pha.pa.us>
Subject: column aliases
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Sun, 23 Jan 2000 04:40:17 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Can someone explain this to me? When I use the alias p, should a
reference to pg_language.oid create a new instance of pg_language in the
range table. Seems it does not. Does the standard say the first query
is legal?
---------------------------------------------------------------------------
test=> select * from pg_language p where p.oid = pg_language.oid;
lanname | lanispl | lanpltrusted | lanplcallfoid | lancompiler
----------+---------+--------------+---------------+-------------
internal | f | f | 0 | n/a
C | f | f | 0 | /bin/cc
sql | f | f | 0 | postgres
(3 rows)
test=> select * from pg_language p, pg_language q where p.oid = q.oid;
lanname | lanispl | lanpltrusted | lanplcallfoid | lancompiler | lanname | lanispl | lanpltrusted | lanplcallfoid | lancompiler
----------+---------+--------------+---------------+-------------+----------+---------+--------------+---------------+-------------
internal | f | f | 0 | n/a | internal | f | f | 0 | n/a
C | f | f | 0 | /bin/cc | C | f | f | 0 | /bin/cc
sql | f | f | 0 | postgres | sql | f | f | 0 | postgres
(3 rows)
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 05:06:13 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA67879
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 05:05:37 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
FAA22692;
Sun, 23 Jan 2000 05:04:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001231004.FAA22692@candle.pha.pa.us>
Subject: Re: [HACKERS] Unique constraint for inherited tables?
In-Reply-To: <388ACAFF.5BF4EB6E@flex.ro> from Constantin Teodorescu at "Jan
23,
2000 11:33:51 am"
To: Constantin Teodorescu <teo@flex.ro>
Date: Sun, 23 Jan 2000 05:04:37 -0500 (EST)
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I am defining a table t1 with a NOT NULL field f1 and UNIQUE field f2.
(it automatically defines t1_f2_key unique index)I am defining now a new table t2 that inherits t1 table and add some
columns.The NOT NULL constraint is preserved for f1 field, the UNIQUE for f2 not
(the index t2_f2_key) is not defined.Wouldn't be normal that the unique constraint to be inherited also in
t2?
This is on the TODO list:
* Unique index on base column not honored on inserts from inherited
table
INSERT INTO inherit_table (unique_index_col) VALUES (dup) should fail
[inherit]
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 07:39:16 2000
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 HAA98669
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 07:39:14 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm141.noc.fukui.nsk.ne.jp [210.161.188.60])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id VAA05052; Sun, 23 Jan 2000 21:38:10 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "The Hermit Hacker" <scrappy@hub.org>,
"Peter Eisentraut" <peter_e@gmx.net>,
"PostgreSQL Development" <pgsql-hackers@postgreSQL.org>,
"Bruce Momjian" <pgman@candle.pha.pa.us>
Subject: RE: [HACKERS] Happy column dropping
Date: Sun, 23 Jan 2000 21:38:49 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFIEELCCAA.Inoue@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 IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <4674.948599382@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom LaneBruce Momjian <pgman@candle.pha.pa.us> writes:
Okay, my turn here ... I vote for this to be *reverted*!!
I disagree. First, it is on the TODO list, so it is open game. Second
it is not throughout all the code, it only gets activated if someone
executes the command. Third, I don't know of any time limit that
features have to be implemented a certain number of weeks _before_ beta
starts.I agree with Bruce. There's no risk of this breaking anything else,
AFAICT, so if it doesn't work there's no harm done. I hope Peter is
going to clean it up more before beta, but why shouldn't he push out
what he has for review and criticism?
I agree with Marc.
DROP COLUMN feature should be discussed before implementing it.
We can live without DROP COLUMN feature.
All we have to do is to ignore the column.
Why should we have a complicated implementation for the feature
without any discussion ?
Anyway I have 2 basic questions.
1) Is the * 2x disk usage * implementation really needed ?
2) Why rename() ?
I don't trust rename() at all in transaction control.
The first thing we should do it to change relname -> relation file
name mapping in order to avoid calling rename().
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Sun Jan 23 10:45:17 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA36360
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 10:45:00 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA23478;
Sun, 23 Jan 2000 07:43:24 -0800 (PST)
Message-Id: <3.0.1.32.20000123072658.01040560@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 23 Jan 2000 07:26:58 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Happy column dropping
Cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <4952.948605252@sss.pgh.pa.us>
References: <200001230426.XAA06789@candle.pha.pa.us>
<200001230426.XAA06789@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:27 AM 1/23/00 -0500, Tom Lane wrote:
I'm of two minds about this. Peter is an energetic new contributor
and we'd be really foolish to discourage him (I was there not very
long ago myself). And a limited DROP COLUMN capability is better
than none at all, so long as its limitations are well-documented.OTOH, I understand Don Baccus' concern: Postgres is on the cusp of
being considered professional-grade software --- we are competing
against multi-K-dollar commercial offerings --- and we jeopardize
that perception if we add features that are less than fully baked.
This is definitely in the 50%-baked category...
I certainly don't want to discourage Peter, either, and perhaps
was a bit too harsh. But release of a feature this half-baked
would fit the stereotype many people have held towards free,
open source software, and postgres in particular.
IMHO, of course.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sun Jan 23 10:44:17 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA36240
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 10:43:54 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA23484;
Sun, 23 Jan 2000 07:43:26 -0800 (PST)
Message-Id: <3.0.1.32.20000123073559.0105c3f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 23 Jan 2000 07:35:59 -0800
To: acroyear@bigpanda.com
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] foreign keys?
Cc: pgsql-hackers@postgresql.org
In-Reply-To: <200001230817.DAA19404@homeworld.bigpanda.org>
References: <Your message of "Sat, 22 Jan 2000 18:04:28 PST."
<3.0.1.32.20000122180428.01049040@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 03:17 AM 1/23/00 -0500, acroyear@bigpanda.com wrote:
As of the last snapshot I downloaded, only MATCH FULL was
implemented fully and I think postgres will only be happy
if you specify the column list or table foo has a primary key.
I actually tried creating table foo with and without a primary
key, with no effect.
create table bar(i integer references foo(i) match full);
That seems to work, although by the way I read the spec, I'm
not sure that it should since there is no unique constraint
specified on foo(i).
Good point, I wonder? Maybe I should get my girlfriend to
snail-mail me my copy of Date, since I won't be back to Boston
until March.
Anyway, the following works:
create table foo(i integer primary key);
create table bar(i integer references foo match full);
It finds the primary key within foo to match upon.
Thanks for the help.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sun Jan 23 11:12:19 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA44163
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 11:12:13 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA06024;
Sun, 23 Jan 2000 11:12:09 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] column aliases
In-reply-to: <200001230940.EAA15266@candle.pha.pa.us>
References: <200001230940.EAA15266@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sun, 23 Jan 2000 04:40:17 -0500"
Date: Sun, 23 Jan 2000 11:12:09 -0500
Message-ID: <6021.948643929@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
test=> select * from pg_language p where p.oid = pg_language.oid;
lanname | lanispl | lanpltrusted | lanplcallfoid | lancompiler
----------+---------+--------------+---------------+-------------
internal | f | f | 0 | n/a
C | f | f | 0 | /bin/cc
sql | f | f | 0 | postgres
(3 rows)
Oh, this is interesting! According to Postgres' view of the world,
you have written a join between "pg_language p" and
"pg_language pg_language", where the latter is an implicitly added
FROM clause. If you do an EXPLAIN you can see that a join is indeed
being done:
regression=# explain
regression-# select * from pg_language p where p.oid = pg_language.oid;
NOTICE: QUERY PLAN:
Hash Join (cost=2.60 rows=4 width=58)
-> Seq Scan on pg_language p (cost=1.13 rows=4 width=54)
-> Hash (cost=1.13 rows=4 width=4)
-> Seq Scan on pg_language (cost=1.13 rows=4 width=4)
EXPLAIN
and a more graphic demonstration is had by using a WHERE clause that
can produce multiple matches:
regression=# select * from pg_language p where p.oid < pg_language.oid;
lanname | lanispl | lanpltrusted | lanplcallfoid | lancompiler
----------+---------+--------------+---------------+-------------
internal | f | f | 0 | n/a
internal | f | f | 0 | n/a
C | f | f | 0 | /bin/cc
internal | f | f | 0 | n/a
C | f | f | 0 | /bin/cc
sql | f | f | 0 | postgres
(6 rows)
What it looks like to me is that we have a bug in the expansion of '*'.
It should be generating columns for both the explicit and the implicit
FROM clause, but it's evidently deciding that it should only produce
output columns for the first one.
This may go a long way towards explaining why people have been so
readily confused by the implicit-FROM-clause business! If they saw
two sets of columns coming out, it'd be more obvious that they were
getting a join.
Does the standard say the first query is legal?
I believe it is not strict SQL92 --- we've been around on that question
before.
regards, tom lane
From bouncefilter Sun Jan 23 11:56:18 2000
Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net
[194.159.73.21]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA52950
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 11:56:00 -0500 (EST)
(envelope-from jeroen@design.nl)
Received: from [212.238.131.55] (helo=manderijn)
by post.mail.nl.demon.net with esmtp (Exim 2.12 #1)
id 12CQIv-000EH9-00
for pgsql-hackers@postgresql.org; Sun, 23 Jan 2000 16:55:57 +0000
Message-Id: <4.2.0.58.20000123170505.00954560@mail.design.nl>
X-Sender: jeroenv@mail.design.nl
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Sun, 23 Jan 2000 17:56:12 +0100
To: pgsql-hackers@postgresql.org
From: Jeroen van Vianen <jeroen@design.nl>
Subject: Implementing STDDEV and VARIANCE
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
I'd like to implement stddev and variance aggregates in Postgres. This is a
long standing TODO item.
There already has been some discussion on implementing this, see
http://www.postgresql.org/mhonarc/pgsql-hackers/1998-06/msg00175.html
There are two definitions for standard deviation and variance:
_
population variance = sigma^2 = SUM(X - X)^2 / N
population stddev = sqrt(population variance)
_
sample variance = s^2 = SUM(X - X)^2 / (N-1)
sample stddev = sqrt(sample variance)
These statistics can be calculated in one pass when three variables are
kept when scanning through the rows, n, sum(x), sum(x^2). Currently, only
two variables are kept.
E.g. avg() is calculated as follows:
sx = 0
n = 0
for every row {
sx = sx + value in row // transition function 1
n = n+1 // transition function 2
}
avg = sum(x) / n
stddev / variance might be calculated as follows:
sx = 0
n = 0
sx2 = 0
for every row {
sx = sx + value in row // transition function 1
n = n+1 // transition function 2
sx2 = sx2 + value in row^2 // transition function 3
}
var = (1/n) * (sx2 - (1/n) * sx^2) // Population
or
var = (1/(n-1)) * (sx2 - (1/n) * sx^2) // Sample
and
stddev = sqrt(var)
I've looked through the code and the following things need to be implemented:
1. Add three columns to pg_aggregate for the additional third transition
function.
Tom Lane wrote at Fri, 05 Jun 1998 11:24:04 -0400:
All that you need to implement this is room to keep two running
sums instead of one. I haven't looked at pgsql's aggregate functions,
but I'd hope that the working state can be a struct not just a
single number.
I saw no other way than adding another transition function and logic, as
this might break user-defined aggregates (are there any around?).
2. Add logic to nodeAgg.c to execute the third transition function and
finalize function with three rather than two parameters
3. Add functions f(a,b) that returns a + b^2 for selected types
4. Add four finalize functions to calculate the variance / stddev
5. Update the code for create aggregate, to include the definition of the
third transition function
6. Update the documentation
My questions are:
1. Is this the correct way to continue? What am I missing? Any errors in my
reasoning?
2. I am proposing the names stddev(x) and variance(x) for population and
samplestddev(x) and
samplevariance(x) for sample statistics. Any comments?
3. I'm planning to implement this for types float4, float8 and numeric. Any
other types also? int[2,4,8] don't seem logical, as these would introduce
serious rounding errors.
Let me know what you think,
Jeroen
From bouncefilter Sun Jan 23 13:00:19 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA65931
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 12:59:52 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id JAA18395;
Sun, 23 Jan 2000 09:58:55 -0800 (PST)
Message-Id: <3.0.1.32.20000123094507.01053430@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 23 Jan 2000 09:45:07 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] column aliases
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <6021.948643929@sss.pgh.pa.us>
References: <200001230940.EAA15266@candle.pha.pa.us>
<200001230940.EAA15266@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:12 AM 1/23/00 -0500, Tom Lane wrote:
What it looks like to me is that we have a bug in the expansion of '*'.
It should be generating columns for both the explicit and the implicit
FROM clause, but it's evidently deciding that it should only produce
output columns for the first one.
Yes, since it is joining the two tables it should be returning all
columns of the join.
This may go a long way towards explaining why people have been so
readily confused by the implicit-FROM-clause business!
It *is* confusing, that's for sure!
If they saw
two sets of columns coming out, it'd be more obvious that they were
getting a join.Does the standard say the first query is legal?
I believe it is not strict SQL92 --- we've been around on that question
before.
Is this feature something many folks depend upon? It appears that at
least some of the folks who hang out on this list aren't entirely
clear on this implicit "from" clause thing - if that's true, how
many users who are out of the loop understand it?
It isn't that burdensome to explictly list a table again in the from
list. The query's certainly more readable and portable for folks who
are (say) trying to port PostgreSQL-based stuff to (say) Oracle.
On the other hand, if a lot of folks depend on this (somewhat dubious,
IMHO) feature then I suppose it should be preserved - with "*" expansion
fixed, presumably!
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sun Jan 23 12:56:19 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA65492
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 12:55:41 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA06211;
Sun, 23 Jan 2000 12:55:36 -0500 (EST)
To: Alfred Perlstein <bright@wintelcom.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: pg_dump possible fix,
need testers. (was: Re: [HACKERS] pg_dump disaster)
In-reply-to: <20000123022341.J26520@fw.wintelcom.net>
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
<5120.948606837@sss.pgh.pa.us>
<20000123022341.J26520@fw.wintelcom.net>
Comments: In-reply-to Alfred Perlstein <bright@wintelcom.net>
message dated "Sun, 23 Jan 2000 02:23:41 -0800"
Date: Sun, 23 Jan 2000 12:55:36 -0500
Message-ID: <6208.948650136@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Um, I didn't have any trouble at all reproducing Patrick's complaint.
pg_dump any moderately large table (I used tenk1 from the regress
database) and try to load the script with psql. Kaboom.
This is after or before my latest patch?
Before. I haven't updated since yesterday...
I can't seem to reproduce this problem,
Odd. Maybe there is something different about the kernel's timing of
message sending on your platform. I see it very easily on HPUX 10.20,
and Patrick sees it very easily on whatever he's using (netbsd I think).
You might try varying the situation a little, say
psql mydb <dumpfile
psql -f dumpfile mydb
psql mydb
\i dumpfile
and the same with -h localhost (to get a TCP/IP connection instead of
Unix domain). At the moment (pre-patch) I see failures with the
first two of these, but not with the \i method. -h doesn't seem to
matter for me, but it might for you.
Telling me something is wrong without giving suggestions on how
to fix it, nor direct pointers to where it fails doesn't help me
one bit. You're not offering constructive critism, you're not
even offering valid critism, you're just waving your finger at
"problems" that you say exist but don't pin down to anything specific.
I have been explaining it as clearly as I could. Let's try it
one more time.
I spent hours looking over what I did to pqFlush and pqPutnBytes
because of what you said earlier when all the bug seems to have
come down to is that I missed that the socket is set to non-blocking
in all cases now.
Letting the socket mode default to blocking will hide the problems from
existing clients that don't care about non-block mode. But people who
try to actually use the nonblock mode are going to see the same kinds of
problems that psql is exhibiting.
The old sequence of events that happened was as follows:
user sends data almost filling the output buffer...
user sends another line of text overflowing the buffer...
pqFlush is invoked blocking the user until the output pipe clears...
and repeat.
Right.
The nonblocking code allows sends to fail so the user can abort
sending stuff to the backend in order to process other work:
user sends data almost filling the output buffer...
user sends another line of text that may overflow the buffer...
pqFlush is invoked,
if the pipe can't be cleared an error is returned allowing the user to
retry the send later.
if the flush succeeds then more data is queued and success is returned
But you haven't thought through the mechanics of the "error is returned
allowing the user to retry" code path clearly enough. Let's take
pqPutBytes for an example. If it returns EOF, is that a hard error or
does it just mean that the application needs to wait a while? The
application *must* distinguish these cases, or it will do the wrong
thing: for example, if it mistakes a hard error for "wait a while",
then it will wait forever without making any progress or producing
an error report.
You need to provide a different return convention that indicates
what happened, say
EOF (-1) => hard error (same as old code)
0 => OK
1 => no data was queued due to risk of blocking
And you need to guarantee that the application knows what the state is
when the can't-do-it-yet return is made; note that I specified "no data
was queued" above. If pqPutBytes might queue some of the data before
returning 1, the application is in trouble again. While you apparently
foresaw that in recoding pqPutBytes, your code doesn't actually work.
There is the minor code bug that you fail to update "avail" after the
first pqFlush call, and the much more fundamental problem that you
cannot guarantee to have queued all or none of the data. Think about
what happens if the passed nbytes is larger than the output buffer size.
You may pass the first pqFlush successfully, then get into the loop and
get a won't-block return from pqFlush in the loop. What then?
You can't simply refuse to support the case nbytes > bufsize at all,
because that will cause application failures as well (too long query
sends it into an infinite loop trying to queue data, most likely).
A possible answer is to specify that a return of +N means "N bytes
remain unqueued due to risk of blocking" (after having queued as much
as you could). This would put the onus on the caller to update his
pointers/counts properly; propagating that into all the internal uses
of pqPutBytes would be no fun. (Of course, so far you haven't updated
*any* of the internal callers to behave reasonably in case of a
won't-block return; PQfn is just one example.)
Another possible answer is to preserve pqPutBytes' old API, "queue or
bust", by the expedient of enlarging the output buffer to hold whatever
we can't send immediately. This is probably more attractive, even
though a long query might suck up a lot of space that won't get
reclaimed as long as the connection lives. If you don't do this then
you are going to have to make a lot of ugly changes in the internal
callers to deal with won't-block returns. Actually, a bulk COPY IN
would probably be the worst case --- the app could easily load data into
the buffer far faster than it could be sent. It might be best to extend
PQputline to have a three-way return and add code there to limit the
growth of the output buffer, while allowing all internal callers to
assume that the buffer is expanded when they need it.
pqFlush has the same kind of interface design problem: the same EOF code
is returned for either a hard error or can't-flush-yet, but it would be
disastrous to treat those cases alike. You must provide a 3-way return
code.
Furthermore, the same sort of 3-way return code convention will have to
propagate out through anything that calls pqFlush (with corresponding
documentation updates). pqPutBytes can be made to hide a pqFlush won't-
block return by trying to enlarge the output buffer, but in most other
places you won't have a choice except to punt it back to the caller.
PQendcopy has the same interface design problem. It used to be that
(unless you passed a null pointer) PQendcopy would *guarantee* that
the connection was no longer in COPY state on return --- by resetting
it, if necessary. So the return code was mainly informative; the
application didn't have to do anything different if PQendcopy reported
failure. But now, a nonblocking application does need to pay attention
to whether PQendcopy completed or not --- and you haven't provided a way
for it to tell. If 1 is returned, the connection might still be in
COPY state, or it might not (PQendcopy might have reset it). If the
application doesn't distinguish these cases then it will fail.
I also think that you want to take a hard look at the automatic "reset"
behavior upon COPY failure, since a PQreset call will block the
application until it finishes. Really, what is needed to close down a
COPY safely in nonblock mode is a pair of entry points along the line of
"PQendcopyStart" and "PQendcopyPoll", with API conventions similar to
PQresetStart/PQresetPoll. This gives you the ability to do the reset
(if one is necessary) without blocking the application. PQendcopy
itself will only be useful to blocking applications.
I'm sorry if they don't work for some situations other than COPY IN,
but it's functionality that I needed and I expect to be expanded on
by myself and others that take interest in nonblocking operation.
I don't think that the nonblock code is anywhere near production quality
at this point. It may work for you, if you don't stress it too hard and
never have a communications failure; but I don't want to see us ship it
as part of Postgres unless these issues get addressed.
regards, tom lane
From bouncefilter Sun Jan 23 13:28:19 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA72457
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 13:27:42 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA06273;
Sun, 23 Jan 2000 13:27:01 -0500 (EST)
To: Jeroen van Vianen <jeroen@design.nl>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Implementing STDDEV and VARIANCE
In-reply-to: <4.2.0.58.20000123170505.00954560@mail.design.nl>
References: <4.2.0.58.20000123170505.00954560@mail.design.nl>
Comments: In-reply-to Jeroen van Vianen <jeroen@design.nl>
message dated "Sun, 23 Jan 2000 17:56:12 +0100"
Date: Sun, 23 Jan 2000 13:27:01 -0500
Message-ID: <6270.948652021@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Jeroen van Vianen <jeroen@design.nl> writes:
I'd like to implement stddev and variance aggregates in Postgres. This is a
long standing TODO item.
1. Add three columns to pg_aggregate for the additional third transition
function.
Tom Lane wrote at Fri, 05 Jun 1998 11:24:04 -0400:
All that you need to implement this is room to keep two running
sums instead of one. I haven't looked at pgsql's aggregate functions,
but I'd hope that the working state can be a struct not just a
single number.
I saw no other way than adding another transition function and logic, as
this might break user-defined aggregates (are there any around?).
Yes, there are some, and no you do not need a third transition
function. What you do need is a datatype holding two values that
you can use as the transition datatype, plus appropriate functions
for the transition functions.
The reason there are two transition functions at all is that it allows
some of the standard aggregate functions to be built using arithmetic
functions that exist anyway --- for example, float8 AVG is built from
float8 addition, float8 increment, and float8 divide, with only float8
increment being a function you wouldn't have anyway. However, the
whole thing is really a kluge; nodeAvg.c has all sorts of weird little
hacks that are necessary to make AVG have the right behavior in boundary
conditions such as no-tuples-in. (A blind application of float8 divide
would lead to a divide-by-zero exception in that case.) These hacks
limit the ability of user-defined aggregates to control their behavior
at the boundary conditions. Nor can an aggregate control its response
to NULL data values; that's hardwired into nodeAvg.c as well.
A cleaner solution would have just one transition function and one
transition data value, plus an optional finalization function that takes
only the one data value. For AVG the transition data type would be a
two-field struct and the transition function would update both fields.
This would halve the function-call overhead per tuple. We'd have to
provide specialized transition and finalization functions for AVG and
probably a couple of the other standard aggregates, but that would allow
us to rely on those functions to do the right things at the boundary
conditions; nodeAvg.c could stop foreclosing the choices.
I have been thinking about proposing such a change along with the
function manager rewrite that is now planned for 7.1. That would be
a good time because user-defined aggregates would need to be revisited
anyway. Also, if the transition functions are to determine the behavior
for no-tuples and for NULL data values, they had better be able to pass
and return NULLs cleanly; which depends on the function manager rewrite.
In short, I'd suggest thinking about implementing STDDEV with a
single transition function and transition data value. You'll need
specialized functions for it anyway, so I don't see that you're saving
any work by proposing a third transition function. What you will need
instead is a pg_type entry for the transition data type, but since that
data type needn't have any operators, there's not much work needed.
3. I'm planning to implement this for types float4, float8 and numeric. Any
other types also? int[2,4,8] don't seem logical, as these would introduce
serious rounding errors.
I'd suggest just two basic implementations, with float8 and numeric
internal calculations respectively. Data of other numeric types can
be type-coerced to one of these (that might even happen automatically),
but the output would always be either float8 or numeric. (I don't think
float4 has enough precision to generate reliable stddev numbers except
in very narrow conditions...)
regards, tom lane
From bouncefilter Sun Jan 23 13:48:20 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA77899
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 13:47:56 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA06320;
Sun, 23 Jan 2000 13:46:29 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] column aliases
In-reply-to: <3.0.1.32.20000123094507.01053430@mail.pacifier.com>
References: <200001230940.EAA15266@candle.pha.pa.us>
<200001230940.EAA15266@candle.pha.pa.us>
<3.0.1.32.20000123094507.01053430@mail.pacifier.com>
Comments: In-reply-to Don Baccus <dhogaza@pacifier.com>
message dated "Sun, 23 Jan 2000 09:45:07 -0800"
Date: Sun, 23 Jan 2000 13:46:29 -0500
Message-ID: <6317.948653189@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
What it looks like to me is that we have a bug in the expansion of '*'.
It should be generating columns for both the explicit and the implicit
FROM clause, but it's evidently deciding that it should only produce
output columns for the first one.
I thought that the behavior had something to do with the fact that
the underlying table was the same for both the explicit and the implicit
rangetable entry, but not so. In fact, ExpandAllTables() deliberately
refrains from expanding implicit entries, and always has AFAICT:
/*
* we only expand those listed in the from clause. (This will
* also prevent us from using the wrong table in inserts: eg.
* tenk2 in "insert into tenk2 select * from tenk1;")
*/
if (!rte->inFromCl)
continue;
I think the comment in parentheses is no longer applicable, but there
are other sources of implicit rangetable entries besides this particular
feature --- rules and set functions both seem to add them. So I'm not
sure what we might break by changing it.
I'm inclined to leave this behavior alone, and go back to the idea of
emitting warning notices when an implicit FROM clause is added.
regards, tom lane
From bouncefilter Sun Jan 23 13:48:22 2000
Received: from hu.tm.ee (ppp884.tele2.ee [212.107.37.184])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA77866
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 13:47:22 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 114B813350; Sun, 23 Jan 2000 20:53:18 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <388B4E1E.12E3123B@tm.ee>
Date: Sun, 23 Jan 2000 20:53:18 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
References: <200001230426.XAA06789@candle.pha.pa.us>
<200001230426.XAA06789@candle.pha.pa.us>
<3.0.1.32.20000123072658.01040560@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 12:27 AM 1/23/00 -0500, Tom Lane wrote:
I'm of two minds about this. Peter is an energetic new contributor
and we'd be really foolish to discourage him (I was there not very
long ago myself). And a limited DROP COLUMN capability is better
than none at all, so long as its limitations are well-documented.OTOH, I understand Don Baccus' concern: Postgres is on the cusp of
being considered professional-grade software --- we are competing
against multi-K-dollar commercial offerings --- and we jeopardize
that perception if we add features that are less than fully baked.
This is definitely in the 50%-baked category...I certainly don't want to discourage Peter, either, and perhaps
was a bit too harsh. But release of a feature this half-baked
Putting something in a development tree can hardly be called a "release"
I'm sure many people would appreciate it even without "preserving oid-s"
as OID's are declared deprecated for (AFAIK) >2 years, and they don't give
any real advantage over primary key with default nextval, as there are
currently no means for reasonably getting from oid to record.
I agree that it could be #ifedef'ed or usable only when you do:
set TerribleDropColumnCludge to 'ON';
would fit the stereotype many people have held towards free,
open source software, and postgres in particular.
What keeps us from discussing the implementation _now_ that we have something
to discuss. Much of the success of open source software comes from the
"show me the code" mentality - you discuss what you have, not what you might
do.
The current "(UN)Happy column dropping" discussion, frankly seems to stem much
from jealousy - hands off my tree, we allow only _purfect_ contributions.
OTOH there are several existing features in postgresql you would not
expect, unless you have worked with postgresql for many years and read
most of traffic on hackers list (like running out of almost all resources
doing a seemingly innocent query (or having it done for you by a "smart"
application), or lack of most common-sense "convenience" optimisations,
like using index for max(), or being able to _partially_ rollback DDL
statements.
Nobody has demanded removing ORs (or even the optimiser ;)) from postgres
because they can explode the backend.
So IMHO discouraging small usability improvements is wrong.
IMHO, of course.
Sure
--------------------
Hannu
From bouncefilter Sun Jan 23 13:57:19 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA79194
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 13:56:36 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA06356;
Sun, 23 Jan 2000 13:55:53 -0500 (EST)
To: Jeroen van Vianen <jeroen@design.nl>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Implementing STDDEV and VARIANCE
In-reply-to: <6270.948652021@sss.pgh.pa.us>
References: <4.2.0.58.20000123170505.00954560@mail.design.nl>
<6270.948652021@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
message dated "Sun, 23 Jan 2000 13:27:01 -0500"
Date: Sun, 23 Jan 2000 13:55:52 -0500
Message-ID: <6353.948653752@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I wrote:
whole thing is really a kluge; nodeAvg.c has all sorts of weird little
For "nodeAvg.c" read "nodeAgg.c"; sorry for the momentary brain fade...
regards, tom lane
From bouncefilter Sun Jan 23 14:05:20 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA84284
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 14:05:06 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA03825;
Sun, 23 Jan 2000 11:03:48 -0800 (PST)
Message-Id: <3.0.1.32.20000123110141.01061b90@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 23 Jan 2000 11:01:41 -0800
To: Hannu Krosing <hannu@tm.ee>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Happy column dropping
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <388B4E1E.12E3123B@tm.ee>
References: <200001230426.XAA06789@candle.pha.pa.us>
<200001230426.XAA06789@candle.pha.pa.us>
<3.0.1.32.20000123072658.01040560@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 08:53 PM 1/23/00 +0200, Hannu Krosing wrote:
What keeps us from discussing the implementation _now_ that we have
something
to discuss.
Nothing. The argument is simply that perhaps discussion should come FIRST.
Much of the success of open source software comes from the
"show me the code" mentality - you discuss what you have, not what you might
do.
I see a lot of pre-implementation discussion on this group. For instance,
recently there was public discussion of "TOAST" large data types. Details
were ironed out, now Jan will go implement it when he has time.
Likewise his approach to implementing referential integrity was discussed
here beforehand.
Just today, we're seeing discussion of the implementation of a new
stddev aggregate function.
I think this is a good process to follow.
The current "(UN)Happy column dropping" discussion, frankly seems to stem
much
from jealousy - hands off my tree, we allow only _purfect_ contributions.
Are you suggesting that the goal should be anything less than perfection?
I guess this goes to my argument that Postgres is starting to be regarded
as a potential competitor to expensive commercial DBs in certain application
environments. If the bar is lowered for contributions, Postgres will
quickly re-earn the image of flakiness that the current developers have
worked so hard to shed.
OTOH there are several existing features in postgresql you would not
expect, unless you have worked with postgresql for many years and read
most of traffic on hackers list (like running out of almost all resources
doing a seemingly innocent query (or having it done for you by a "smart"
application), or lack of most common-sense "convenience" optimisations,
like using index for max(), or being able to _partially_ rollback DDL
statements.Nobody has demanded removing ORs (or even the optimiser ;)) from postgres
because they can explode the backend.
No ... but fixing ORs seems to be on the list of things to be done.
Pointing to the fact that the inherited code still needs a lot of work
before it's really a solid, commercial-quality database engine in all
regards doesn't convince me that weak implementations of new features
should be added.
My impression is that the current crop of developers are aiming higher...
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sun Jan 23 14:15:20 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA85523
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 14:15:08 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id OAA06409;
Sun, 23 Jan 2000 14:14:30 -0500 (EST)
To: Hannu Krosing <hannu@tm.ee>
cc: Don Baccus <dhogaza@pacifier.com>, Bruce Momjian <pgman@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-reply-to: <388B4E1E.12E3123B@tm.ee>
References: <200001230426.XAA06789@candle.pha.pa.us>
<200001230426.XAA06789@candle.pha.pa.us>
<3.0.1.32.20000123072658.01040560@mail.pacifier.com>
<388B4E1E.12E3123B@tm.ee>
Comments: In-reply-to Hannu Krosing <hannu@tm.ee>
message dated "Sun, 23 Jan 2000 20:53:18 +0200"
Date: Sun, 23 Jan 2000 14:14:30 -0500
Message-ID: <6406.948654870@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Hannu Krosing <hannu@tm.ee> writes:
The current "(UN)Happy column dropping" discussion, frankly seems to
stem much from jealousy - hands off my tree, we allow only _purfect_
contributions.
I think this discussion could do without personal attacks, don't you?
OTOH there are several existing features in postgresql you would not
expect, unless you have worked with postgresql for many years and read
most of traffic on hackers list (like running out of almost all resources
doing a seemingly innocent query (or having it done for you by a "smart"
application), or lack of most common-sense "convenience" optimisations,
like using index for max(), or being able to _partially_ rollback DDL
statements.
I see it considerably differently. Quite a few of us have been sweating
blood for a long time to clean up those past half-baked implementation
decisions. We're all well aware that the list of those problems is
still very long. Should we be happy about the addition of another such
problem?
I've been generally in favor of letting Peter continue with this
process, but that's only because I expect him to be here for the long
haul and to work on refining his first cut into a robust feature.
If he stops here and leaves it for other folks to clean up, then I'd
vote to remove it as well.
regards, tom lane
From bouncefilter Sun Jan 23 14:47:20 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id OAA05010
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 14:46:34 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA00286;
Sun, 23 Jan 2000 14:43:23 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001231943.OAA00286@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <388B4E1E.12E3123B@tm.ee> from Hannu Krosing at "Jan 23,
2000 08:53:18 pm"
To: Hannu Krosing <hannu@tm.ee>
Date: Sun, 23 Jan 2000 14:43:23 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I certainly don't want to discourage Peter, either, and perhaps
was a bit too harsh. But release of a feature this half-baked
would fit the stereotype many people have held towards free,
open source software, and postgres in particular.
I again am totally confused by the reaction to this.
Peter has done a lot for 7.0. Only Tom Lane and Jan have done more work
on 7.0 than Peter. He has also fixed many TODO items from the list.
We is not releasing tomorrow. He is putting in what he has and asking
for advise. Yes, it would have been better if he would have discussed
this first. However, he is writing _huge_ amounts of PostgreSQL code.
Look at the new psql or initdb, or the other items he has done. Maybe
he is too busy coding to bring up issues on the list.
As long as he addresses concerns we have, I can live with some
non-perfect code. He is relatively new to this. Honestly, only Tom
Lane and Jan are as energetic about 7.0 as Peter, so why rock the boat.
That doesn't mean I accept bad code, only that I am patient with
people's styles.
I can't remember the last time we all were so harsh, and I am concerned.
Let me see if I can say something everyone will agree on:
---------------------------------------------------------------------------
First, Peter, I hope you have not gotten too upset while reading the
previous messages.
Second, I know you asked for suggestions while working on psql, and
really didn't get much feedback. You did a great job without much
direction. Let me suggest you not give up on us helping you in other
projects. If you get stuck or need a suggestion, just send a note to
hackers, and we can give you ideas. Often this will make your job
easier.
---------------------------------------------------------------------------
Actually, when I get stuck, I post to the list and put the project down
for a few hours. An answer to my question usually shows up very soon.
In the old days, I used to ask over and over again as I learned more
about the problem until someone figured it out. :-)
I am thinking of calling 7.0 the Lane/Wieck/Eisentraut release.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 15:06:21 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA11209
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 15:05:59 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA18604;
Sun, 23 Jan 2000 12:04:42 -0800 (PST)
Message-Id: <3.0.1.32.20000123120230.01064790@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 23 Jan 2000 12:02:30 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>, Hannu Krosing <hannu@tm.ee>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Happy column dropping
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <200001231943.OAA00286@candle.pha.pa.us>
References: <388B4E1E.12E3123B@tm.ee>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:43 PM 1/23/00 -0500, Bruce Momjian wrote:
I certainly don't want to discourage Peter, either, and perhaps
was a bit too harsh. But release of a feature this half-baked
would fit the stereotype many people have held towards free,
open source software, and postgres in particular.
I again am totally confused by the reaction to this.
Peter has done a lot for 7.0. Only Tom Lane and Jan have done more work
on 7.0 than Peter. He has also fixed many TODO items from the list.
Yes, and that's great. I'm not commenting about those things, though.
Though I have to say, having just finally built the pre-7.0 sources,
I like the new psql formatting.
That doesn't mean I have to like an "alter ... drop column" that doesn't
really implement "alter ... drop column", though, does it? :)
We is not releasing tomorrow. He is putting in what he has and asking
for advise.
Perhaps I'm suffering from a misperception, then...my understanding
was that his having committed the changes meant they would be showing
up in the upcoming V7.0 Beta release.
Yes, it would have been better if he would have discussed
this first. However, he is writing _huge_ amounts of PostgreSQL code.
Look at the new psql or initdb, or the other items he has done. Maybe
he is too busy coding to bring up issues on the list.
As long as he addresses concerns we have, I can live with some
non-perfect code. He is relatively new to this. Honestly, only Tom
Lane and Jan are as energetic about 7.0 as Peter, so why rock the boat.
This sounds a bit like the old management technique of measuring
productivity by counting lines of code! I should hope quality counts
for even more than quantity. Shouldn't it?
(and, no, I'm not implying that Peter's contributions are of poor
quality, I'm just reacting to your point)
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sun Jan 23 15:11:20 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA11799
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 15:10:52 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA88605;
Sun, 23 Jan 2000 16:08:47 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 23 Jan 2000 16:08:46 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Hannu Krosing <hannu@tm.ee>
cc: Don Baccus <dhogaza@pacifier.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Bruce Momjian <pgman@candle.pha.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <388B4E1E.12E3123B@tm.ee>
Message-ID: <Pine.BSF.4.21.0001231600550.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 23 Jan 2000, Hannu Krosing wrote:
The current "(UN)Happy column dropping" discussion, frankly seems to
stem much from jealousy - hands off my tree, we allow only _purfect_
contributions.
I don't expect any contribution to be perfect ... I do expect those that
are committing code directly to the source tree to take a few minutes and
think before they do so. Peter *knew* there were implementation flaws to
what he added, yet he implemented it anyway, without asking anyone else
for comments and/or suggestions on how those flaws could be avoided ... if
Peter didn't have commit access, he would have had to submit those patches
for review before having them applied, just like Alfred recently went
through with his libpq changes ...
OTOH there are several existing features in postgresql you would not
expect, unless you have worked with postgresql for many years and read
most of traffic on hackers list (like running out of almost all
resources doing a seemingly innocent query (or having it done for you
by a "smart" application), or lack of most common-sense "convenience"
optimisations, like using index for max(), or being able to
_partially_ rollback DDL statements.
Ah, but, in these cases, they lack of don't break existing applications
*and* the running out of all resources definitely isn't "hidden" in the
background, you find out about it quick ...
The beef I have with how Peter went about implementing this was that the
biggest flaw that he lists is *hidden* in the background ...
Nobody has demanded removing ORs (or even the optimiser ;)) from
postgres because they can explode the backend.
It is because they explode the backend that we don't ... what Peter
implemented silently tromps on the OIDs ...
So IMHO discouraging small usability improvements is wrong.
Ppl are missing the whole point here ... it isn't the improvement that I
have a beef against, it is the fact that, unlike every other feature
addition (bug fixes are different), there was absolutely no discussion
before implementation ... hell, if the implementation didn't come with a
"caveat" afterwards, it wouldn't have been so bad, but Peter commit'd a
"small usability improvement" followed up by what *I* consider to be one
helluva caveat, without any discussion on how to get around that before
committing ... that, IMHO, is wrong ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 23 15:13:20 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA12103
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 15:12:31 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA88612;
Sun, 23 Jan 2000 16:11:04 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 23 Jan 2000 16:11:04 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Hannu Krosing <hannu@tm.ee>, Tom Lane <tgl@sss.pgh.pa.us>,
Bruce Momjian <pgman@candle.pha.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <3.0.1.32.20000123110141.01061b90@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0001231609270.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 23 Jan 2000, Don Baccus wrote:
I guess this goes to my argument that Postgres is starting to be
regarded as a potential competitor to expensive commercial DBs in
certain application environments. If the bar is lowered for
contributions, Postgres will quickly re-earn the image of flakiness
that the current developers have worked so hard to shed.
I'm not so much beef'd about 'lowering any bar', I'm beef'd that the bar
apparently is being set at different hits for contributors vs committers
...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 23 15:20:21 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id PAA13574
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 15:20:16 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA02474;
Sun, 23 Jan 2000 15:18:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001232018.PAA02474@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <3.0.1.32.20000123120230.01064790@mail.pacifier.com> from Don
Baccus at "Jan 23, 2000 12:02:30 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Sun, 23 Jan 2000 15:18:14 -0500 (EST)
CC: Hannu Krosing <hannu@tm.ee>, Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
At 02:43 PM 1/23/00 -0500, Bruce Momjian wrote:
I certainly don't want to discourage Peter, either, and perhaps
was a bit too harsh. But release of a feature this half-baked
would fit the stereotype many people have held towards free,
open source software, and postgres in particular.I again am totally confused by the reaction to this.
Peter has done a lot for 7.0. Only Tom Lane and Jan have done more work
on 7.0 than Peter. He has also fixed many TODO items from the list.Yes, and that's great. I'm not commenting about those things, though.
Though I have to say, having just finally built the pre-7.0 sources,
I like the new psql formatting.That doesn't mean I have to like an "alter ... drop column" that doesn't
really implement "alter ... drop column", though, does it? :)
But is this really a bad thing. I think it is acceptible as is. We
currently tell people in the FAQ that do drop a column, do a SELECT INTO
... ALTER RENAME. That loses more than Peter's version.
We is not releasing tomorrow. He is putting in what he has and asking
for advise.Perhaps I'm suffering from a misperception, then...my understanding
was that his having committed the changes meant they would be showing
up in the upcoming V7.0 Beta release.
Well, my assumption is that either Peter will add the missing
functionality, or we will vote on whether to enable/disable it in 7.0.
One line in gram.y and it is disabled.
I can tell you that I certainly will vote for it as enabled, even with
the limitations, because CLUSTER has a bigger problem. Maybe we just
add a NOTICE to CLUSTER and DROP COLUMN and be done with it.
I can also say I would never have thought about the items Peter asked
about. I would have just implemented it as he did and maybe never even
considered the limitations.
Yes, it would have been better if he would have discussed
this first. However, he is writing _huge_ amounts of PostgreSQL code.
Look at the new psql or initdb, or the other items he has done. Maybe
he is too busy coding to bring up issues on the list.As long as he addresses concerns we have, I can live with some
non-perfect code. He is relatively new to this. Honestly, only Tom
Lane and Jan are as energetic about 7.0 as Peter, so why rock the boat.This sounds a bit like the old management technique of measuring
productivity by counting lines of code! I should hope quality counts
for even more than quantity. Shouldn't it?(and, no, I'm not implying that Peter's contributions are of poor
quality, I'm just reacting to your point)
When I say huge amount of code, I mean huge rewrites of terriblily
unstuctured code into nice neat code. Look at the new psql vs. the old
code.
We can't expect people to just walk up and produce portable,
style-conforming, totally functional code from day 1 or even year 1.
We work with people and point them in the right direction.
You know why ANALYZE is part of VACUUM? Because at the time I didn't
know how to scan a table. Vacuum already did that, so I piggybacked on
that code.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 15:29:21 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id PAA15010
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 15:28:40 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA04529;
Sun, 23 Jan 2000 15:26:38 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001232026.PAA04529@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <Pine.BSF.4.21.0001231600550.79710-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 23, 2000 04:08:46 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Sun, 23 Jan 2000 15:26:38 -0500 (EST)
CC: Hannu Krosing <hannu@tm.ee>, Don Baccus <dhogaza@pacifier.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Sun, 23 Jan 2000, Hannu Krosing wrote:
The current "(UN)Happy column dropping" discussion, frankly seems to
stem much from jealousy - hands off my tree, we allow only _purfect_
contributions.I don't expect any contribution to be perfect ... I do expect those that
are committing code directly to the source tree to take a few minutes and
think before they do so. Peter *knew* there were implementation flaws to
what he added, yet he implemented it anyway, without asking anyone else
for comments and/or suggestions on how those flaws could be avoided ... if
Peter didn't have commit access, he would have had to submit those patches
for review before having them applied, just like Alfred recently went
through with his libpq changes ...
But he is not done. What does it matter if he does 1/2 now and 1/2 in a
week, as long as it is done before beta? As long as the tree still
compiles, does it matter?
Let him fix 50 TODO items 1/2 way. If he finishes them by beta, great.
If not, we can vote on a ripout/disable before beta begins.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 15:43:21 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA20453
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 15:42:30 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA88856;
Sun, 23 Jan 2000 16:41:03 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 23 Jan 2000 16:41:03 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, Hannu Krosing <hannu@tm.ee>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <200001232018.PAA02474@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001231638570.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 23 Jan 2000, Bruce Momjian wrote:
You know why ANALYZE is part of VACUUM? Because at the time I didn't
know how to scan a table. Vacuum already did that, so I piggybacked on
that code.
Big difference ... what you did didn't run the risk of breaking existing
applications ... *maybe* there is no choice in this, *maybe* the way that
Peter implemented is the only way it *could* be implemented ... all I'm
arguing is that there should have been a discussion *before* it was
implemented to hammer that point out ...
... just like we've done for the past 4 years now ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 23 14:42:21 2000
Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net
[194.159.73.20]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA04316
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 14:41:21 -0500 (EST)
(envelope-from jeroen@design.nl)
Received: from [212.238.131.55] (helo=design.nl)
by post.mail.nl.demon.net with esmtp (Exim 2.02 #1)
id 12CSsv-0003Hy-00; Sun, 23 Jan 2000 19:41:18 +0000
Sender: jeroenv
Message-ID: <388B677F.381B10E4@design.nl>
Date: Sun, 23 Jan 2000 20:41:35 +0000
From: Jeroen van Vianen <jeroen@design.nl>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Implementing STDDEV and VARIANCE
References: <4.2.0.58.20000123170505.00954560@mail.design.nl>
<6270.948652021@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Jeroen van Vianen <jeroen@design.nl> writes:
I'd like to implement stddev and variance aggregates in Postgres. This is a
long standing TODO item.1. Add three columns to pg_aggregate for the additional third transition
function.Tom Lane wrote at Fri, 05 Jun 1998 11:24:04 -0400:
All that you need to implement this is room to keep two running
sums instead of one. I haven't looked at pgsql's aggregate functions,
but I'd hope that the working state can be a struct not just a
single number.I saw no other way than adding another transition function and logic, as
this might break user-defined aggregates (are there any around?).Yes, there are some, and no you do not need a third transition
function. What you do need is a datatype holding two values that
you can use as the transition datatype, plus appropriate functions
for the transition functions.
So it might be better to have this type hold three values (n, sum(x) and
sum(x^2)) and only use one transition function to update all three
values at once and have the finalization function do the necessary
calculations.
The reason there are two transition functions at all is that it allows
some of the standard aggregate functions to be built using arithmetic
functions that exist anyway --- for example, float8 AVG is built from
float8 addition, float8 increment, and float8 divide, with only float8
increment being a function you wouldn't have anyway. However, the
whole thing is really a kluge; nodeAvg.c has all sorts of weird little
hacks that are necessary to make AVG have the right behavior in boundary
conditions such as no-tuples-in. (A blind application of float8 divide
would lead to a divide-by-zero exception in that case.) These hacks
limit the ability of user-defined aggregates to control their behavior
at the boundary conditions. Nor can an aggregate control its response
to NULL data values; that's hardwired into nodeAvg.c as well.
Yes, I saw these little hacks. And there are boundary conditions with
stddev and variance with no rows and one row (for sample stddev and
sample variance).
A cleaner solution would have just one transition function and one
transition data value, plus an optional finalization function that takes
only the one data value. For AVG the transition data type would be a
two-field struct and the transition function would update both fields.
This would halve the function-call overhead per tuple. We'd have to
provide specialized transition and finalization functions for AVG and
probably a couple of the other standard aggregates, but that would allow
us to rely on those functions to do the right things at the boundary
conditions; nodeAvg.c could stop foreclosing the choices.
So you suggest changing all transition functions for 7.1 to keep all the
state they need?
I have been thinking about proposing such a change along with the
function manager rewrite that is now planned for 7.1. That would be
a good time because user-defined aggregates would need to be revisited
anyway. Also, if the transition functions are to determine the behavior
for no-tuples and for NULL data values, they had better be able to pass
and return NULLs cleanly; which depends on the function manager rewrite.
Are you suggesting also to change the lay-out of pg_attribute in 7.1 to
something like this and do updates for all built-in types and
aggregates?
aggname
aggowner
aggtype
aggtranstype [ n, sx, sx2 ]
agginitfunction function that does ( n = 0, sx = 0.0, sx2 = 0.0 )
aggtransfunction function that does ( n = n + 1, sx = sx + x,
sx2 = sx2 + x * x )
aggfinalizefunction function that returns (sx2 - (1/n) * sx * sx ) /
n
Might it be better for me to wait for 7.1 before implementing stddev and
variance?
In short, I'd suggest thinking about implementing STDDEV with a
single transition function and transition data value. You'll need
specialized functions for it anyway, so I don't see that you're saving
any work by proposing a third transition function. What you will need
instead is a pg_type entry for the transition data type, but since that
data type needn't have any operators, there's not much work needed.
OK, clear.
3. I'm planning to implement this for types float4, float8 and numeric. Any
other types also? int[2,4,8] don't seem logical, as these would introduce
serious rounding errors.I'd suggest just two basic implementations, with float8 and numeric
internal calculations respectively. Data of other numeric types can
be type-coerced to one of these (that might even happen automatically),
but the output would always be either float8 or numeric. (I don't think
float4 has enough precision to generate reliable stddev numbers except
in very narrow conditions...)
OK, only float8 and numeric.
Jeroen
From bouncefilter Sun Jan 23 15:45:21 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA23585
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 15:44:46 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA88860;
Sun, 23 Jan 2000 16:43:22 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 23 Jan 2000 16:43:22 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hannu Krosing <hannu@tm.ee>, Don Baccus <dhogaza@pacifier.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <200001232026.PAA04529@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001231641400.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 23 Jan 2000, Bruce Momjian wrote:
On Sun, 23 Jan 2000, Hannu Krosing wrote:
The current "(UN)Happy column dropping" discussion, frankly seems to
stem much from jealousy - hands off my tree, we allow only _purfect_
contributions.I don't expect any contribution to be perfect ... I do expect those that
are committing code directly to the source tree to take a few minutes and
think before they do so. Peter *knew* there were implementation flaws to
what he added, yet he implemented it anyway, without asking anyone else
for comments and/or suggestions on how those flaws could be avoided ... if
Peter didn't have commit access, he would have had to submit those patches
for review before having them applied, just like Alfred recently went
through with his libpq changes ...But he is not done. What does it matter if he does 1/2 now and 1/2 in a
week, as long as it is done before beta? As long as the tree still
compiles, does it matter?Let him fix 50 TODO items 1/2 way. If he finishes them by beta, great.
If not, we can vote on a ripout/disable before beta begins.
And if 5 of those 50 that he does finish rely on 45 that he doesn't? I'm
just saying that 24hr of discussion before implementation might have come
up with a cleaner solution to the problem ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 23 15:49:22 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA31416
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 15:49:04 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA29469;
Sun, 23 Jan 2000 12:47:44 -0800 (PST)
Message-Id: <3.0.1.32.20000123124518.01065400@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 23 Jan 2000 12:45:18 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Happy column dropping
Cc: Hannu Krosing <hannu@tm.ee>, Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <200001232018.PAA02474@candle.pha.pa.us>
References: <3.0.1.32.20000123120230.01064790@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 03:18 PM 1/23/00 -0500, Bruce Momjian wrote:
That doesn't mean I have to like an "alter ... drop column" that doesn't
really implement "alter ... drop column", though, does it? :)But is this really a bad thing. I think it is acceptible as is. We
currently tell people in the FAQ that do drop a column, do a SELECT INTO
... ALTER RENAME. That loses more than Peter's version.
Again I'm missing not having Date here, I just called and it will
be mailed to me next week.
But I've been under the assumption that "alter table drop column" is
part of SQL 92.
If I'm wrong, then I suppose PostgreSQL can do whatever it wants.
If it is part of SQL 92, though, shouldn't there at least be discussion
of what's needed to actually implement the real, live standard semantics?
Isn't the user who picks up PostgreSQL from, say, a Red Hat distribution
going to be a bit surprised that "drop column" drops integrity constraints
for the whole table?
Assuming, of course, the feature as is were to go into release.
I can also say I would never have thought about the items Peter asked
about. I would have just implemented it as he did and maybe never even
considered the limitations.
Hmmm...if it's part of SQL 92 I certainly would've looked at the
defined semantics first. At least, that's what people pay me to do
when I hack compilers...
We can't expect people to just walk up and produce portable,
style-conforming, totally functional code from day 1 or even year 1.
We work with people and point them in the right direction.
And if I get organized to the point of being able to make contributions
I would hope for tough, objective criticism of my efforts.
You know why ANALYZE is part of VACUUM? Because at the time I didn't
know how to scan a table. Vacuum already did that, so I piggybacked on
that code.
This doesn't break standard semantics - again, if I'm wrong about
alter table ... drop column being part of SQL 92 then I'll back off
the suggestion that an implementation of standard semantics be
explored.
Maybe we should just drop this thread, I'm certainly not out to make
any enemies. I've become fond of Postgres, and I guess my expectations
and standards are just very high. Not that I'm always able to live
up to them! :)
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sun Jan 23 15:49:21 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id PAA30239
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 15:48:54 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA11062;
Sun, 23 Jan 2000 15:46:47 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001232046.PAA11062@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <Pine.BSF.4.21.0001231641400.79710-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 23, 2000 04:43:22 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Sun, 23 Jan 2000 15:46:47 -0500 (EST)
CC: Hannu Krosing <hannu@tm.ee>, Don Baccus <dhogaza@pacifier.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
But he is not done. What does it matter if he does 1/2 now and 1/2 in a
week, as long as it is done before beta? As long as the tree still
compiles, does it matter?Let him fix 50 TODO items 1/2 way. If he finishes them by beta, great.
If not, we can vote on a ripout/disable before beta begins.And if 5 of those 50 that he does finish rely on 45 that he doesn't? I'm
just saying that 24hr of discussion before implementation might have come
up with a cleaner solution to the problem ...
Sure, that is preferable.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 16:00:21 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA43414
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 15:59:45 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA88971;
Sun, 23 Jan 2000 16:58:20 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 23 Jan 2000 16:58:20 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Hannu Krosing <hannu@tm.ee>, Don Baccus <dhogaza@pacifier.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <200001232046.PAA11062@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001231658010.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 23 Jan 2000, Bruce Momjian wrote:
But he is not done. What does it matter if he does 1/2 now and 1/2 in a
week, as long as it is done before beta? As long as the tree still
compiles, does it matter?Let him fix 50 TODO items 1/2 way. If he finishes them by beta, great.
If not, we can vote on a ripout/disable before beta begins.And if 5 of those 50 that he does finish rely on 45 that he doesn't? I'm
just saying that 24hr of discussion before implementation might have come
up with a cleaner solution to the problem ...Sure, that is preferable.
*head pounding against a wall* that was my *whole* point :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 23 16:02:21 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id QAA45956
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 16:01:42 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA11321;
Sun, 23 Jan 2000 15:59:38 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001232059.PAA11321@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <3.0.1.32.20000123124518.01065400@mail.pacifier.com> from Don
Baccus at "Jan 23, 2000 12:45:18 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Sun, 23 Jan 2000 15:59:38 -0500 (EST)
CC: Hannu Krosing <hannu@tm.ee>, Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Maybe we should just drop this thread, I'm certainly not out to make
any enemies. I've become fond of Postgres, and I guess my expectations
and standards are just very high. Not that I'm always able to live
up to them! :)
It's like watching hot dogs or legislation being made. You don't want
to watch.
We get everything working in the end. It can be ugly getting there and
seeing all the warts along the way.
I think we are spoiled with Tom, Jan, and Vadim who just show up and
produce 100% functional patches the first time. Some people go at it in
different ways. Eventually it all gets working. I can't tell you how
many times I have added a feature or fixed something, and then had Tom
Lane or Vadim come along and fix my fixes.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 16:09:21 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id QAA48318
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 16:08:32 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA11430;
Sun, 23 Jan 2000 16:06:28 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001232106.QAA11430@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <Pine.BSF.4.21.0001231658010.79710-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 23, 2000 04:58:20 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Sun, 23 Jan 2000 16:06:28 -0500 (EST)
CC: Hannu Krosing <hannu@tm.ee>, Don Baccus <dhogaza@pacifier.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Sun, 23 Jan 2000, Bruce Momjian wrote:
But he is not done. What does it matter if he does 1/2 now and 1/2 in a
week, as long as it is done before beta? As long as the tree still
compiles, does it matter?Let him fix 50 TODO items 1/2 way. If he finishes them by beta, great.
If not, we can vote on a ripout/disable before beta begins.And if 5 of those 50 that he does finish rely on 45 that he doesn't? I'm
just saying that 24hr of discussion before implementation might have come
up with a cleaner solution to the problem ...Sure, that is preferable.
*head pounding against a wall* that was my *whole* point :)
Yes, but if wants to put what he has done so far, and then discuss it,
why give him grief about it? Maybe that's how he likes to do things.
I tried to get Jan to assist Vince in the way CVS is used for the web
pages. Vince was happy with his system and my interference in Vince's
system made for hurt feelings all around.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 16:19:21 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id QAA50228
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 16:19:20 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 3303 invoked by uid 1001); 23 Jan 2000 21:19:20 -0000
Message-ID: <XFMail.000123161920.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <200001232106.QAA11430@candle.pha.pa.us>
Date: Sun, 23 Jan 2000 16:19:20 -0500 (EST)
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: Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
Cc: Hannu Krosing <hannu@tm.ee>, Don Baccus <dhogaza@pacifier.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>,
The Hermit Hacker <scrappy@hub.org>
On 23-Jan-00 Bruce Momjian wrote:
On Sun, 23 Jan 2000, Bruce Momjian wrote:
I tried to get Jan to assist Vince in the way CVS is used for the web
pages. Vince was happy with his system and my interference in Vince's
system made for hurt feelings all around.
Water under the bridge. Jan and I have down and had a few beers
together.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Sun Jan 23 16:24:22 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id QAA50708
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 16:23:26 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA11685;
Sun, 23 Jan 2000 16:21:11 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001232121.QAA11685@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <XFMail.000123161920.vev@michvhf.com> from Vince Vielhaber at
"Jan
23, 2000 04:19:20 pm"
To: Vince Vielhaber <vev@michvhf.com>
Date: Sun, 23 Jan 2000 16:21:11 -0500 (EST)
CC: Hannu Krosing <hannu@tm.ee>, Don Baccus <dhogaza@pacifier.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>,
The Hermit Hacker <scrappy@hub.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On 23-Jan-00 Bruce Momjian wrote:
On Sun, 23 Jan 2000, Bruce Momjian wrote:
I tried to get Jan to assist Vince in the way CVS is used for the web
pages. Vince was happy with his system and my interference in Vince's
system made for hurt feelings all around.Water under the bridge. Jan and I have down and had a few beers
together.
Well, that's very good news.
Now, I guess I can ask abou the new developers page. It would be nice
to have that for the start of Beta.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 16:24:21 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA50795
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 16:24:14 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA89106;
Sun, 23 Jan 2000 17:22:47 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 23 Jan 2000 17:22:47 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, Hannu Krosing <hannu@tm.ee>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <200001232059.PAA11321@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001231722191.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 23 Jan 2000, Bruce Momjian wrote:
I think we are spoiled with Tom, Jan, and Vadim who just show up and
produce 100% functional patches the first time. Some people go at it in
different ways. Eventually it all gets working. I can't tell you how
many times I have added a feature or fixed something, and then had Tom
Lane or Vadim come along and fix my fixes.
2 points:
a) 100% functional patches *after* extensive discussion
b) Peter's change wasn't a fix
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 23 16:29:21 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id QAA51471
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 16:29:03 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA11739;
Sun, 23 Jan 2000 16:27:00 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001232127.QAA11739@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <Pine.BSF.4.21.0001231722191.79710-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 23, 2000 05:22:47 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Sun, 23 Jan 2000 16:27:00 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>, Hannu Krosing <hannu@tm.ee>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Sun, 23 Jan 2000, Bruce Momjian wrote:
I think we are spoiled with Tom, Jan, and Vadim who just show up and
produce 100% functional patches the first time. Some people go at it in
different ways. Eventually it all gets working. I can't tell you how
many times I have added a feature or fixed something, and then had Tom
Lane or Vadim come along and fix my fixes.2 points:
a) 100% functional patches *after* extensive discussion
b) Peter's change wasn't a fix
Usually some one cleans me up. :-) Even with discussion, my stuff is
not 100%.
I did code to extend the number of index columns >8, but broke the
system in several ways. Tom Lane fixed it for me. I think I even
committed it with a broken initdb, but figured out how to disable it
while Tom and I worked on it.
Yes, but even my feature additions have problems. :-)
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 16:44:22 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA56838
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 16:43:28 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA89248;
Sun, 23 Jan 2000 17:42:56 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 23 Jan 2000 17:42:56 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, Hannu Krosing <hannu@tm.ee>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <200001232127.QAA11739@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001231742160.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 23 Jan 2000, Bruce Momjian wrote:
On Sun, 23 Jan 2000, Bruce Momjian wrote:
I think we are spoiled with Tom, Jan, and Vadim who just show up and
produce 100% functional patches the first time. Some people go at it in
different ways. Eventually it all gets working. I can't tell you how
many times I have added a feature or fixed something, and then had Tom
Lane or Vadim come along and fix my fixes.2 points:
a) 100% functional patches *after* extensive discussion
b) Peter's change wasn't a fixUsually some one cleans me up. :-) Even with discussion, my stuff is
not 100%.I did code to extend the number of index columns >8, but broke the
system in several ways. Tom Lane fixed it for me. I think I even
committed it with a broken initdb, but figured out how to disable it
while Tom and I worked on it.Yes, but even my feature additions have problems. :-)
There is a key factor involved in all of this ... how many of these
"bugs" were things that ppl would think about before it is
implemented?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 23 16:49:21 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id QAA57461
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 16:49:00 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA12107;
Sun, 23 Jan 2000 16:48:10 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001232148.QAA12107@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <Pine.BSF.4.21.0001231742160.79710-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 23, 2000 05:42:56 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Sun, 23 Jan 2000 16:48:10 -0500 (EST)
CC: Don Baccus <dhogaza@pacifier.com>, Hannu Krosing <hannu@tm.ee>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Usually some one cleans me up. :-) Even with discussion, my stuff is
not 100%.I did code to extend the number of index columns >8, but broke the
system in several ways. Tom Lane fixed it for me. I think I even
committed it with a broken initdb, but figured out how to disable it
while Tom and I worked on it.Yes, but even my feature additions have problems. :-)
There is a key factor involved in all of this ... how many of these
"bugs" were things that ppl would think about before it is
implemented?
No idea. I just know I didn't think of them.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 17:07:22 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA63162
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 17:06:41 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id OAA18946;
Sun, 23 Jan 2000 14:06:04 -0800 (PST)
Message-Id: <3.0.1.32.20000123140355.0104dc60@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 23 Jan 2000 14:03:55 -0800
To: Hannu Krosing <hannu@tm.ee>, The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Happy column dropping
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
In-Reply-To: <388B7AF7.7AFBFFB7@tm.ee>
References: <Pine.BSF.4.21.0001231722191.79710-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:04 AM 1/24/00 +0200, Hannu Krosing wrote:
It could possibly be done by marking the column deleted and doing the
compression/renumbering during vacuum , or by locking the table and
compressing each page in-place if space is a concern or maybe several
other ways.
The existence of several ways to do it should not discourage people
from actually adding the drop column feature to postgres
It should provide even more encouragement to discuss the proposed
implementation *first*.
IMHO, again.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sun Jan 23 16:59:22 2000
Received: from hu.tm.ee (ppp884.tele2.ee [212.107.37.184])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA58675
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 16:58:37 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 915EE1313A; Mon, 24 Jan 2000 00:04:39 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <388B7AF7.7AFBFFB7@tm.ee>
Date: Mon, 24 Jan 2000 00:04:39 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Don Baccus <dhogaza@pacifier.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Happy column dropping
References: <Pine.BSF.4.21.0001231722191.79710-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
On Sun, 23 Jan 2000, Bruce Momjian wrote:
I think we are spoiled with Tom, Jan, and Vadim who just show up and
produce 100% functional patches the first time. Some people go at it in
different ways. Eventually it all gets working. I can't tell you how
many times I have added a feature or fixed something, and then had Tom
Lane or Vadim come along and fix my fixes.2 points:
a) 100% functional patches *after* extensive discussion
It assumes that you do all your actual coding and code reviewing yourself
while hiding the code, i.e. the (alledged) *BSD way.
The "release often, release early" school of OS tells people to show even
premature code in hope of getting more/faster eyballing.
He could have done it by posting patches for discussion, but I can't see
the real difference here.
What I think he is doing here is one-to-one move the FAQ recommendation
for drop column to backend. And then move on from that to cover the areas
of renumbering colums and keeping related constraints intact the FAQ
glossed over.
It could possibly be done by marking the column deleted and doing the
compression/renumbering during vacuum , or by locking the table and
compressing each page in-place if space is a concern or maybe several
other ways.
The existence of several ways to do it should not discourage people
from actually adding the drop column feature to postgres
b) Peter's change wasn't a fix
I was'nt a _bug_ fix, it was a usability fix and likely SQL 92
compatibility fix.
-------------
Hannu
From bouncefilter Sun Jan 23 17:20:22 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA65247
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 17:20:22 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id OAA22184;
Sun, 23 Jan 2000 14:19:46 -0800 (PST)
Message-Id: <3.0.1.32.20000123141739.010461d0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 23 Jan 2000 14:17:39 -0800
To: Hannu Krosing <hannu@tm.ee>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Happy column dropping
Cc: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
In-Reply-To: <388B7E6D.622A8C62@tm.ee>
References: <Pine.BSF.4.21.0001231722191.79710-100000@thelab.hub.org>
<3.0.1.32.20000123140355.0104dc60@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:19 AM 1/24/00 +0200, Hannu Krosing wrote:
Don Baccus wrote:
It should provide even more encouragement to discuss the proposed
implementation *first*.Judging from the length of this thread it is much more effective to get
a discussion *after* ;)
Not at all...thus far there's no discussion of HOW to implement the
correct semantics at all.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Sun Jan 23 17:14:22 2000
Received: from hu.tm.ee (ppp884.tele2.ee [212.107.37.184])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA64152
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 17:13:24 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 17B5E1313A; Mon, 24 Jan 2000 00:19:26 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <388B7E6D.622A8C62@tm.ee>
Date: Mon, 24 Jan 2000 00:19:25 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
Cc: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Happy column dropping
References: <Pine.BSF.4.21.0001231722191.79710-100000@thelab.hub.org>
<3.0.1.32.20000123140355.0104dc60@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 12:04 AM 1/24/00 +0200, Hannu Krosing wrote:
It could possibly be done by marking the column deleted and doing the
compression/renumbering during vacuum , or by locking the table and
compressing each page in-place if space is a concern or maybe several
other ways.
The existence of several ways to do it should not discourage people
from actually adding the drop column feature to postgresIt should provide even more encouragement to discuss the proposed
implementation *first*.
Judging from the length of this thread it is much more effective to get
a discussion *after* ;)
---------------
Hannu
From bouncefilter Sun Jan 23 17:21:22 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id RAA65314
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 17:20:52 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA24922;
Sun, 23 Jan 2000 17:20:04 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001232220.RAA24922@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <3.0.1.32.20000123140355.0104dc60@mail.pacifier.com> from Don
Baccus at "Jan 23, 2000 02:03:55 pm"
To: Don Baccus <dhogaza@pacifier.com>
Date: Sun, 23 Jan 2000 17:20:04 -0500 (EST)
CC: Hannu Krosing <hannu@tm.ee>, The Hermit Hacker <scrappy@hub.org>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Does anyone know why this thread is called, "Happy column dropping"?
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 17:21:23 2000
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id RAA65340
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 17:21:07 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 3506 invoked by uid 1001); 23 Jan 2000 22:21:07 -0000
Date: Sun, 23 Jan 2000 17:21:07 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <200001232121.QAA11685@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.05.10001231717510.3495-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 23 Jan 2000, Bruce Momjian wrote:
On 23-Jan-00 Bruce Momjian wrote:
On Sun, 23 Jan 2000, Bruce Momjian wrote:
I tried to get Jan to assist Vince in the way CVS is used for the web
pages. Vince was happy with his system and my interference in Vince's
system made for hurt feelings all around.Water under the bridge. Jan and I have down and had a few beers
together.Well, that's very good news.
Now, I guess I can ask abou the new developers page. It would be nice
to have that for the start of Beta.
You volunteering? :) When I said earlier that it was on the back
burner, it is because I'm extremely busy right now. If Jan wants to
do it or if you do, I have no problem with that - but I suspect Jan's
a little on the busy side right now as well. With luck perhaps I can
have it online by late spring.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From bouncefilter Sun Jan 23 17:28:22 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA66296
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 17:27:42 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA89623;
Sun, 23 Jan 2000 18:27:26 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 23 Jan 2000 18:27:26 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Hannu Krosing <hannu@tm.ee>, Bruce Momjian <pgman@candle.pha.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <3.0.1.32.20000123141739.010461d0@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0001231827030.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 23 Jan 2000, Don Baccus wrote:
At 12:19 AM 1/24/00 +0200, Hannu Krosing wrote:
Don Baccus wrote:
It should provide even more encouragement to discuss the proposed
implementation *first*.Judging from the length of this thread it is much more effective to get
a discussion *after* ;)Not at all...thus far there's no discussion of HOW to implement the
correct semantics at all.
Actually, I like the fact that Hannu suggested a way of implemented that
Bruce and I have been discussing in private :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 23 17:31:23 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id RAA67548
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 17:30:38 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA25785;
Sun, 23 Jan 2000 17:30:04 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001232230.RAA25785@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <Pine.BSF.4.05.10001231717510.3495-100000@paprika.michvhf.com>
from Vince Vielhaber at "Jan 23, 2000 05:21:07 pm"
To: Vince Vielhaber <vev@michvhf.com>
Date: Sun, 23 Jan 2000 17:30:04 -0500 (EST)
CC: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Now, I guess I can ask abou the new developers page. It would be nice
to have that for the start of Beta.You volunteering? :) When I said earlier that it was on the back
burner, it is because I'm extremely busy right now. If Jan wants to
do it or if you do, I have no problem with that - but I suspect Jan's
a little on the busy side right now as well. With luck perhaps I can
have it online by late spring.
Jan's version looked done to me. Can't we just put that up until we
have something better.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 17:32:23 2000
Received: from hu.tm.ee (ppp884.tele2.ee [212.107.37.184])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA68959
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 17:31:20 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 233F51313A; Mon, 24 Jan 2000 00:37:23 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <388B82A1.C401DBC@tm.ee>
Date: Mon, 24 Jan 2000 00:37:21 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
Cc: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Happy column dropping
References: <Pine.BSF.4.21.0001231722191.79710-100000@thelab.hub.org>
<3.0.1.32.20000123140355.0104dc60@mail.pacifier.com>
<3.0.1.32.20000123141739.010461d0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 12:19 AM 1/24/00 +0200, Hannu Krosing wrote:
Don Baccus wrote:
It should provide even more encouragement to discuss the proposed
implementation *first*.Judging from the length of this thread it is much more effective to get
a discussion *after* ;)Not at all...thus far there's no discussion of HOW to implement the
correct semantics at all.
Such is the human nature. Instead of discussing how to implement it we
discuss someone else not discussing it at proper time...
Seems to be much more important topic.
-----------
Hannu
From bouncefilter Sun Jan 23 19:56:24 2000
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 TAA00427
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 19:56:07 -0500 (EST) (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 JAA05287; Mon, 24 Jan 2000 09:55:54 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Kristofer Munn" <kmunn@munn.com>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Patch for elog(FATAL)/elog(ERROR) infinite loop?
Date: Mon, 24 Jan 2000 10:01:36 +0900
Message-ID: <001f01bf6606$904c0000$2801007e@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: <Pine.LNX.4.04.10001220153550.10641-100000@munn.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Kristofer MunnHi everyone. Awhile back I reported the elog(FATAL)/elog(ERROR) infinite
loop and I see it marked in the TODO as done for 7.0. Is there a patch
for this problem for 6.5.3?
Is your report [HACKERS] ERROR: infinite recursion in proc_exit ?
Is the TODO * -spinlock stuck problem when elog(FATAL) and elog(ERROR)
inside bufmgr ?
The TODO case is different from your problem.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Sun Jan 23 20:10:24 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA06773
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 20:10:08 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id RAA09657;
Sun, 23 Jan 2000 17:32:54 -0800 (PST)
Date: Sun, 23 Jan 2000 17:32:54 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: pg_dump possible fix,
need testers. (was: Re: [HACKERS] pg_dump disaster)
Message-ID: <20000123173254.T26520@fw.wintelcom.net>
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
<5120.948606837@sss.pgh.pa.us>
<20000123022341.J26520@fw.wintelcom.net>
<6208.948650136@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <6208.948650136@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Sun, Jan 23, 2000 at 12:55:36PM -0500
* Tom Lane <tgl@sss.pgh.pa.us> [000123 10:19] wrote:
Um, I didn't have any trouble at all reproducing Patrick's complaint.
pg_dump any moderately large table (I used tenk1 from the regress
database) and try to load the script with psql. Kaboom.This is after or before my latest patch?
Before. I haven't updated since yesterday...
I can't seem to reproduce this problem,
Odd. Maybe there is something different about the kernel's timing of
message sending on your platform. I see it very easily on HPUX 10.20,
and Patrick sees it very easily on whatever he's using (netbsd I think).
You might try varying the situation a little, say
psql mydb <dumpfile
psql -f dumpfile mydb
psql mydb
\i dumpfile
and the same with -h localhost (to get a TCP/IP connection instead of
Unix domain). At the moment (pre-patch) I see failures with the
first two of these, but not with the \i method. -h doesn't seem to
matter for me, but it might for you.
Ok, the latest patch I posted fixes that, with and without the -h
flag, at least for me.
Telling me something is wrong without giving suggestions on how
to fix it, nor direct pointers to where it fails doesn't help me
one bit. You're not offering constructive critism, you're not
even offering valid critism, you're just waving your finger at
"problems" that you say exist but don't pin down to anything specific.I have been explaining it as clearly as I could. Let's try it
one more time.
What I needed was the above steps to validate that the problem is fixed.
I spent hours looking over what I did to pqFlush and pqPutnBytes
because of what you said earlier when all the bug seems to have
come down to is that I missed that the socket is set to non-blocking
in all cases now.Letting the socket mode default to blocking will hide the problems from
existing clients that don't care about non-block mode. But people who
try to actually use the nonblock mode are going to see the same kinds of
problems that psql is exhibiting.
There is no non-block mode, there's the old mode, and the _real_
non-blocking mode that I'm trying to get working.
The old sequence of events that happened was as follows:
user sends data almost filling the output buffer...
user sends another line of text overflowing the buffer...
pqFlush is invoked blocking the user until the output pipe clears...
and repeat.Right.
You agree that it's somewhat broken to do that right?
The nonblocking code allows sends to fail so the user can abort
sending stuff to the backend in order to process other work:user sends data almost filling the output buffer...
user sends another line of text that may overflow the buffer...
pqFlush is invoked,
if the pipe can't be cleared an error is returned allowing the user to
retry the send later.
if the flush succeeds then more data is queued and success is returnedBut you haven't thought through the mechanics of the "error is returned
allowing the user to retry" code path clearly enough. Let's take
pqPutBytes for an example. If it returns EOF, is that a hard error or
does it just mean that the application needs to wait a while? The
application *must* distinguish these cases, or it will do the wrong
thing: for example, if it mistakes a hard error for "wait a while",
then it will wait forever without making any progress or producing
an error report.You need to provide a different return convention that indicates
what happened, say
EOF (-1) => hard error (same as old code)
0 => OK
1 => no data was queued due to risk of blocking
And you need to guarantee that the application knows what the state is
when the can't-do-it-yet return is made; note that I specified "no data
was queued" above. If pqPutBytes might queue some of the data before
returning 1, the application is in trouble again. While you apparently
foresaw that in recoding pqPutBytes, your code doesn't actually work.
There is the minor code bug that you fail to update "avail" after the
first pqFlush call, and the much more fundamental problem that you
cannot guarantee to have queued all or none of the data. Think about
what happens if the passed nbytes is larger than the output buffer size.
You may pass the first pqFlush successfully, then get into the loop and
get a won't-block return from pqFlush in the loop. What then?
You can't simply refuse to support the case nbytes > bufsize at all,
because that will cause application failures as well (too long query
sends it into an infinite loop trying to queue data, most likely).
I don't have to think about this too much (nbytes > conn->outBufSize),
see: http://www.postgresql.org/docs/programmer/libpq-chapter4142.htm
the Caveats section for libpq:
Caveats
The query buffer is 8192 bytes long, and queries over that length
will be rejected.
If I can enforce this limit then i'm fine, also there's nothing
stopping me from temporarily realloc()'ing the send buffer, or
chaining another sendbuffer if the first fills mid query, it would
be easy to restrict the application to only a single overcommit of
the send buffer, or a single circular buffer to avoid memory
copies.
A possible answer is to specify that a return of +N means "N bytes
remain unqueued due to risk of blocking" (after having queued as much
as you could). This would put the onus on the caller to update his
pointers/counts properly; propagating that into all the internal uses
of pqPutBytes would be no fun. (Of course, so far you haven't updated
*any* of the internal callers to behave reasonably in case of a
won't-block return; PQfn is just one example.)
No way dude. :) I would like to get started on a PQfnstart()/PQfnpoll
interface soon.
Another possible answer is to preserve pqPutBytes' old API, "queue or
bust", by the expedient of enlarging the output buffer to hold whatever
we can't send immediately. This is probably more attractive, even
though a long query might suck up a lot of space that won't get
reclaimed as long as the connection lives. If you don't do this then
you are going to have to make a lot of ugly changes in the internal
callers to deal with won't-block returns. Actually, a bulk COPY IN
would probably be the worst case --- the app could easily load data into
the buffer far faster than it could be sent. It might be best to extend
PQputline to have a three-way return and add code there to limit the
growth of the output buffer, while allowing all internal callers to
assume that the buffer is expanded when they need it.
It's not too difficult to only allow one over-commit into the buffer,
and enforcing the 8k limit, what do you think about that?
pqFlush has the same kind of interface design problem: the same EOF code
is returned for either a hard error or can't-flush-yet, but it would be
disastrous to treat those cases alike. You must provide a 3-way return
code.Furthermore, the same sort of 3-way return code convention will have to
propagate out through anything that calls pqFlush (with corresponding
documentation updates). pqPutBytes can be made to hide a pqFlush won't-
block return by trying to enlarge the output buffer, but in most other
places you won't have a choice except to punt it back to the caller.
I'm not sure about this, the old pqFlush would reset the connection
if it went bad, (I was suprised to see that it didn't) it doesn't do
this so it can read the dying words from the backend, imo all that's
needed is a:
conn->status = CONNECTION_BAD;
before returning EOF in pqFlush()
pqReadData will happily read from pgconn marked 'CONNECTION_BAD' and
user applications can then QPstatus() and reset the connection.
PQendcopy has the same interface design problem. It used to be that
(unless you passed a null pointer) PQendcopy would *guarantee* that
the connection was no longer in COPY state on return --- by resetting
it, if necessary. So the return code was mainly informative; the
application didn't have to do anything different if PQendcopy reported
failure. But now, a nonblocking application does need to pay attention
to whether PQendcopy completed or not --- and you haven't provided a way
for it to tell. If 1 is returned, the connection might still be in
COPY state, or it might not (PQendcopy might have reset it). If the
application doesn't distinguish these cases then it will fail.
PQstatus will allow you to determine if the connection has gone to
CONNECTION_BAD.
I also think that you want to take a hard look at the automatic "reset"
behavior upon COPY failure, since a PQreset call will block the
application until it finishes. Really, what is needed to close down a
COPY safely in nonblock mode is a pair of entry points along the line of
"PQendcopyStart" and "PQendcopyPoll", with API conventions similar to
PQresetStart/PQresetPoll. This gives you the ability to do the reset
(if one is necessary) without blocking the application. PQendcopy
itself will only be useful to blocking applications.
I'd be willing to work on fixing this up, but currently other issues
you've mentioned seem higher on the priority list.
I'm sorry if they don't work for some situations other than COPY IN,
but it's functionality that I needed and I expect to be expanded on
by myself and others that take interest in nonblocking operation.I don't think that the nonblock code is anywhere near production quality
at this point. It may work for you, if you don't stress it too hard and
never have a communications failure; but I don't want to see us ship it
as part of Postgres unless these issues get addressed.
I'd really appreciate if it was instead left as undocumented until we
have it completed.
Doing that allows people like myself to see that work is in progress
to provide this functionality and possibly contribute to polishing
it up and expanding its usefullness instead of giving up entirely
or starting from scratch.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
From bouncefilter Sun Jan 23 21:11:25 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id VAA22487
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 21:10:51 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id VAA29590
for pgsql-hackers@postgreSQL.org; Sun, 23 Jan 2000 21:10:04 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001240210.VAA29590@candle.pha.pa.us>
Subject: initdb everyone
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Sun, 23 Jan 2000 21:10:04 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I have modified STATRELID cache lookup for Tom Lane and the optimizer.
initdb everyone. A system index has changed.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Jan 23 22:06:29 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA36990
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 22:06:17 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA91514
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 23:06:13 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 23 Jan 2000 23:06:13 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: Use of Indicies ...
Message-ID: <Pine.BSF.4.21.0001232301340.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Always something that confuses me ... I have a query that looks like:
SELECT count(counter_id) \
FROM referrer_link \
WHERE counter_id = ? \
AND referrer_id = ? \
AND stat_date = ?;
There is an index on all three conditions in the WHERE clause:
Yet EXPLAIN shows:
Aggregate (cost=2.05 rows=1 width=4)
-> Index Scan using referrer_link_counter_id on referrer_link (cost=2.05 rows=1 width=4)
EXPLAIN
Table looks like:
webcounter=> \d referrer_link
Table = referrer_link
+----------------------------------+----------------------------------+-------+
| Field | Type | Length|
+----------------------------------+----------------------------------+-------+
| counter_id | int4 | 4 |
| stat_date | datetime | 8 |
| referrer_id | int4 | 4 |
| referrer_hits | int8 | 8 |
+----------------------------------+----------------------------------+-------+
Indices: referrer_link_counter_id
referrer_link_referrer_id
referrer_link_stat_dateWhy does EXPLAIN only show the use of one of the indices, why counter_id
and why not all three?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 23 22:27:25 2000
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 WAA40074
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 22:27:14 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org (dial-1.r13.ncbrvr.infoave.net [207.144.84.131] (may
be forged))
by www.wgcr.org (8.9.3/8.9.3/WGCR) with ESMTP id WAA27374;
Sun, 23 Jan 2000 22:23:36 -0500
Message-ID: <388BC5AC.A2A3D0BA@wgcr.org>
Date: Sun, 23 Jan 2000 22:23:24 -0500
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 <pgman@candle.pha.pa.us>
CC: Don Baccus <dhogaza@pacifier.com>, Hannu Krosing <hannu@tm.ee>,
The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Happy column dropping
References: <200001232220.RAA24922@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Does anyone know why this thread is called, "Happy column dropping"?
Because Peter thought everyone would be happy being able to drop
columns.
Of course, more discussion should have happened. I have found out the
hard way about some of this in keeping up the RPM's. However, I have
found most of the RPM issues settle out from end users -- not from the
development team. Thus, I am in an 'in between' position -- which is an
ideal place for a packager, anyway.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Sun Jan 23 22:53:26 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id WAA46748
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 22:52:55 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA27391 for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 14:52:09 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpdOyxQp_;
Mon Jan 24 14:51:47 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
OAA11366 for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 14:51:47 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdWczzl_; Mon Jan 24 14:51:29 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA29166
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 14:51:28 +1100 (EST)
Received: from majere.design (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
OAA16335 for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 14:50:53 +1100 (EST)
Received: from bitmead.com (localhost [127.0.0.1])
by majere.design (8.8.8+Sun/8.8.8) with ESMTP id OAA27081
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 14:50:10 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <388BCBEF.615092D2@bitmead.com>
Date: Mon, 24 Jan 2000 14:50:07 +1100
From: Chris Bitmead <chris@bitmead.com>
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
References: <200001230426.XAA06789@candle.pha.pa.us>
<200001230426.XAA06789@candle.pha.pa.us>
<3.0.1.32.20000123072658.01040560@mail.pacifier.com>
<388B4E1E.12E3123B@tm.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hannu Krosing wrote:
Putting something in a development tree can hardly be called a "release"
I'm sure many people would appreciate it even without "preserving oid-s"
as OID's are declared deprecated for (AFAIK) >2 years,
I've never seen or heard of any mention of oids being "deprecated". Some
people don't like them much, other people like them. Myself, I think
they will be great when a few issues with them are cleaned up (e.g.
backup with preservation of oids and full INSERT statements).
and they don't give
any real advantage over primary key with default nextval, as there are
currently no means for reasonably getting from oid to record.
Not sure what you mean by "no means". They are queried and indexed like
other fields. No advantage? Well it takes one less pg call to get the
last value, and it takes less storage since they are there anyway. They
will also be very important if and when postgres makes more moves toward
being an ODBMS.
BTW, if someone implememnted INSERT where you may optionally specify the
oid, would this solve the problem, as I take it this patch is all about
implementing drop column in terms of a CREATE/SELECT INTO.
From bouncefilter Sun Jan 23 23:26:27 2000
Received: from munn.com (kmunn.munn.com [209.123.248.252])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA54951
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 23:26:17 -0500 (EST) (envelope-from kmunn@munn.com)
Received: from localhost (kmunn@localhost)
by munn.com (8.9.1/8.9.1) with ESMTP id XAA19765;
Sun, 23 Jan 2000 23:26:02 -0500
Date: Sun, 23 Jan 2000 23:26:01 -0500 (EST)
From: Kristofer Munn <kmunn@munn.com>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Patch for elog(FATAL)/elog(ERROR) infinite loop?
In-Reply-To: <001f01bf6606$904c0000$2801007e@tpf.co.jp>
Message-ID: <Pine.LNX.4.04.10001232323380.15048-100000@munn.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hiroshi Inoue
Is your report [HACKERS] ERROR: infinite recursion in proc_exit ?
Yes.
Is the TODO * -spinlock stuck problem when elog(FATAL) and elog(ERROR)
inside bufmgr ?
Yes?
The TODO case is different from your problem.
Oh. (pout) Is it in the TO_DO or, preferably, the HAS_BEEN_DONE? :-)
- K
Kristofer Munn * KMI * 973-509-9414 * AIM KrMunn * http://www.munn.com/
From bouncefilter Sun Jan 23 23:28:27 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA55210
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 23:27:56 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA14686;
Sun, 23 Jan 2000 23:27:22 -0500 (EST)
To: Jeroen van Vianen <jeroen@design.nl>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Implementing STDDEV and VARIANCE
In-reply-to: <388B677F.381B10E4@design.nl>
References: <4.2.0.58.20000123170505.00954560@mail.design.nl>
<6270.948652021@sss.pgh.pa.us> <388B677F.381B10E4@design.nl>
Comments: In-reply-to Jeroen van Vianen <jeroen@design.nl>
message dated "Sun, 23 Jan 2000 20:41:35 +0000"
Date: Sun, 23 Jan 2000 23:27:22 -0500
Message-ID: <14683.948688042@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Jeroen van Vianen <jeroen@design.nl> writes:
aggname
aggowner
aggtype
aggtranstype [ n, sx, sx2 ]
agginitfunction function that does ( n = 0, sx = 0.0, sx2 = 0.0 )
aggtransfunction function that does ( n = n + 1, sx = sx + x,
sx2 = sx2 + x * x )
aggfinalizefunction function that returns (sx2 - (1/n) * sx * sx ) /
n
Right, that's pretty much what I'm visualizing. One minor detail: there
is not an "agginitfunction", there is an "agginitvalue". So your
special datatype to hold n/sx/sx2 must have at least a typinput function
that can convert the text string held in pg_aggregate into the desired
internal form of the initial state. (At least, that's how it's done
now. Do you want to argue to change it? As long as we're opening up
the AGG design for reconsideration, we could revisit that choice too.)
Might it be better for me to wait for 7.1 before implementing stddev and
variance?
Well, you will need to be pretty fast on the draw if you want to get it
into 7.0 release, since we will be freezing features for beta in a week.
But I see no reason that you couldn't implement STDDEV within the
existing framework; just ignore transfn2 and do it as above. You might
have some problems with getting the desired response for zero or one
tuples, but there isn't any way to fix that within the current
framework :-(. We have to do the function manager rewrite before you
can have control over when to return a NULL. As long as you are willing
to live with that, you can have useful functionality now.
regards, tom lane
From bouncefilter Sun Jan 23 23:42:26 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id XAA61731
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 23:42:09 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA10384 for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:41:37 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0AJOxk;
Mon Jan 24 15:41:13 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
PAA24091 for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:41:12 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd08XlTG; Mon Jan 24 15:40:57 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA07502
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:40:56 +1100 (EST)
Received: from majere.design (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
PAA18160 for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:40:21 +1100 (EST)
Received: from bitmead.com (localhost [127.0.0.1])
by majere.design (8.8.8+Sun/8.8.8) with ESMTP id PAA27717
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:39:38 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <388BD78A.BEEA8502@bitmead.com>
Date: Mon, 24 Jan 2000 15:39:38 +1100
From: Chris Bitmead <chris@bitmead.com>
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Happy column dropping
References: <4.2.0.58.20000123170505.00954560@mail.design.nl>
<6270.948652021@sss.pgh.pa.us> <388B677F.381B10E4@design.nl>
<14683.948688042@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hannu Krosing wrote:
I'm sure many people would appreciate it even without "preserving oid-s"
as OID's are declared deprecated for (AFAIK) >2 years,
OIDs should not be deprecated (never heard that one before). They will
become more important if and when postgres moves more toward being an
odbms. For reasons see any book on object theory and identity.
From bouncefilter Sun Jan 23 23:56:27 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA64466
for <pgsql-hackers@postgresql.org>;
Sun, 23 Jan 2000 23:55:30 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id AAA92457;
Mon, 24 Jan 2000 00:54:25 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 24 Jan 2000 00:54:25 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Chris Bitmead <chris@bitmead.com>
cc: pgsql-hackers@postgresql.org
Subject: ORDBMS<->OID (Re: [HACKERS] Happy column dropping)
In-Reply-To: <388BD78A.BEEA8502@bitmead.com>
Message-ID: <Pine.BSF.4.21.0001240052020.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 24 Jan 2000, Chris Bitmead wrote:
Hannu Krosing wrote:
I'm sure many people would appreciate it even without "preserving oid-s"
as OID's are declared deprecated for (AFAIK) >2 years,OIDs should not be deprecated (never heard that one before). They will
become more important if and when postgres moves more toward being an
odbms. For reasons see any book on object theory and identity.
You are the second person that mentioned the ODBMS<->OID tie in ... when
you say ODBMS, is that the same as ORDBMS, or we talking a different
issue?
Want to elaborate? Like, since we already have the 'core', I believe,
what does it take to continue that trend?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Jan 23 23:55:27 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA64431
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 23:55:19 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id XAA14721;
Sun, 23 Jan 2000 23:54:58 -0500 (EST)
To: Alfred Perlstein <bright@wintelcom.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: pg_dump possible fix,
need testers. (was: Re: [HACKERS] pg_dump disaster)
In-reply-to: <20000123173254.T26520@fw.wintelcom.net>
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
<5120.948606837@sss.pgh.pa.us>
<20000123022341.J26520@fw.wintelcom.net>
<6208.948650136@sss.pgh.pa.us>
<20000123173254.T26520@fw.wintelcom.net>
Comments: In-reply-to Alfred Perlstein <bright@wintelcom.net>
message dated "Sun, 23 Jan 2000 17:32:54 -0800"
Date: Sun, 23 Jan 2000 23:54:58 -0500
Message-ID: <14718.948689698@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Alfred Perlstein <bright@wintelcom.net> writes:
There is no non-block mode, there's the old mode, and the _real_
non-blocking mode that I'm trying to get working.
Ah --- well, I guess we can agree that it doesn't work yet ;-)
user sends data almost filling the output buffer...
user sends another line of text overflowing the buffer...
pqFlush is invoked blocking the user until the output pipe clears...
and repeat.Right.
You agree that it's somewhat broken to do that right?
It's only broken for a client that doesn't want to block --- but,
clearly, for such a client we can't do it that way. I like the way
that fe-connect.c has been rewritten over the past couple of months:
provide a "start" and a "poll" function for each operation, and then
implement the old blocking-style function as "start" followed by a
loop around the "poll" function. Note (just to beat the drum one
more time) that neither the start nor the poll function has the
same API as the old-style function.
You can't simply refuse to support the case nbytes > bufsize at all,
because that will cause application failures as well (too long query
sends it into an infinite loop trying to queue data, most likely).
I don't have to think about this too much (nbytes > conn->outBufSize),
see: http://www.postgresql.org/docs/programmer/libpq-chapter4142.htm
the Caveats section for libpq:
The query buffer is 8192 bytes long, and queries over that length
will be rejected.
Is that still there? Well, I'm sorry if you relied on that statement,
but it's obsolete. Postgres no longer has any fixed limit on the
length of queries, and it won't do for libpq to re-introduce one.
(Quick grep: yipes, that statement is indeed still in the docs, in
more than one place even. Thanks for pointing this out.)
If I can enforce this limit then i'm fine, also there's nothing
stopping me from temporarily realloc()'ing the send buffer, or
chaining another sendbuffer if the first fills mid query, it would
be easy to restrict the application to only a single overcommit of
the send buffer, or a single circular buffer to avoid memory
copies.
I think reallocing the send buffer is perfectly acceptable. I'm not
quite following what you mean by "only one overcommit", though.
PQendcopy has the same interface design problem. It used to be that
(unless you passed a null pointer) PQendcopy would *guarantee* that
the connection was no longer in COPY state on return --- by resetting
it, if necessary. So the return code was mainly informative; the
application didn't have to do anything different if PQendcopy reported
failure. But now, a nonblocking application does need to pay attention
to whether PQendcopy completed or not --- and you haven't provided a way
for it to tell. If 1 is returned, the connection might still be in
COPY state, or it might not (PQendcopy might have reset it). If the
application doesn't distinguish these cases then it will fail.
PQstatus will allow you to determine if the connection has gone to
CONNECTION_BAD.
Neither of the states that we need to distinguish will be CONNECTION_BAD.
I suppose the application could look at the asyncStatus to see if it is
COPY_IN/COPY_OUT, but I think that would be very poor software design:
asyncStatus is intended to be private to libpq and readily redefinable.
(It's not presently visible in libpq-fe.h at all.) If we start
exporting it as public data we will regret it, IMHO. Much better to
provide a new exported function whose API is appropriate for this purpose.
I don't think that the nonblock code is anywhere near production quality
at this point. It may work for you, if you don't stress it too hard and
never have a communications failure; but I don't want to see us ship it
as part of Postgres unless these issues get addressed.
I'd really appreciate if it was instead left as undocumented until we
have it completed.
I'd be willing to consider that if I were sure that it couldn't break
any ordinary blocking-mode cases. Right now I don't have much
confidence about that...
regards, tom lane
From bouncefilter Sun Jan 23 23:56:26 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id XAA64535
for <pgsql-hackers@postgreSQL.org>;
Sun, 23 Jan 2000 23:56:06 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA24088;
Sun, 23 Jan 2000 23:55:18 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001240455.XAA24088@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <388BD78A.BEEA8502@bitmead.com> from Chris Bitmead at "Jan 24,
2000 03:39:38 pm"
To: Chris Bitmead <chris@bitmead.com>
Date: Sun, 23 Jan 2000 23:55:17 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hannu Krosing wrote:
I'm sure many people would appreciate it even without "preserving oid-s"
as OID's are declared deprecated for (AFAIK) >2 years,OIDs should not be deprecated (never heard that one before). They will
become more important if and when postgres moves more toward being an
odbms. For reasons see any book on object theory and identity.
Agreed.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 24 00:06:27 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA70518
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 00:05:47 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id VAA10250;
Sun, 23 Jan 2000 21:04:40 -0800 (PST)
Message-Id: <3.0.1.32.20000123210213.010588a0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 23 Jan 2000 21:02:13 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, Jeroen van Vianen <jeroen@design.nl>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Implementing STDDEV and VARIANCE
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <14683.948688042@sss.pgh.pa.us>
References: <388B677F.381B10E4@design.nl>
<4.2.0.58.20000123170505.00954560@mail.design.nl>
<6270.948652021@sss.pgh.pa.us> <388B677F.381B10E4@design.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:27 PM 1/23/00 -0500, Tom Lane wrote:
Right, that's pretty much what I'm visualizing. One minor detail: there
is not an "agginitfunction", there is an "agginitvalue". So your
special datatype to hold n/sx/sx2 must have at least a typinput function
that can convert the text string held in pg_aggregate into the desired
internal form of the initial state. (At least, that's how it's done
now. Do you want to argue to change it? As long as we're opening up
the AGG design for reconsideration, we could revisit that choice too.)
At the moment I have a hard time visualizing an aggregate function where
a constant initializer wouldn't serve, but ... what would be the cost of
the generalization? It would only be called once per query or subquery
containing the aggregate, right?
If generalizing it can be done over a latte or mocha, perhaps it's worth
doing. If it takes as long as drinking a pint of Guiness, perhaps not :)
(I mean, let's get into meaningful metrics here!)
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 00:22:27 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA74171
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 00:21:38 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA14763;
Mon, 24 Jan 2000 00:21:08 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>, Don Baccus <dhogaza@pacifier.com>,
Hannu Krosing <hannu@tm.ee>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-reply-to: <200001232127.QAA11739@candle.pha.pa.us>
References: <200001232127.QAA11739@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Sun, 23 Jan 2000 16:27:00 -0500"
Date: Mon, 24 Jan 2000 00:21:08 -0500
Message-ID: <14760.948691268@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I think we are spoiled with Tom, Jan, and Vadim who just show up and
produce 100% functional patches the first time.
Who, me? Go back and read the CVS logs for all my "oops..." messages.
a) 100% functional patches *after* extensive discussion
Usually some one cleans me up. :-) Even with discussion, my stuff is
not 100%.
Assuming that Peter is still listening and hasn't given up in disgust,
I think the take-home point here is "discuss first, implement second".
Even the guys who have been working with Postgres the longest are
keenly aware that they don't know all there is to know about the
system. *That's* why we have developed a tradition of sending proposals
to the list before doing anything major. Very often there's someone
who knows a little more than you do about one aspect or another, and
will be able to save you from a mistake.
regards, tom lane
From bouncefilter Mon Jan 24 00:27:27 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA74945
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 00:26:43 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA14825;
Mon, 24 Jan 2000 00:26:19 -0500 (EST)
To: Kristofer Munn <kmunn@munn.com>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Patch for elog(FATAL)/elog(ERROR) infinite loop?
In-reply-to: <Pine.LNX.4.04.10001232323380.15048-100000@munn.com>
References: <Pine.LNX.4.04.10001232323380.15048-100000@munn.com>
Comments: In-reply-to Kristofer Munn <kmunn@munn.com>
message dated "Sun, 23 Jan 2000 23:26:01 -0500"
Date: Mon, 24 Jan 2000 00:26:19 -0500
Message-ID: <14822.948691579@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Kristofer Munn <kmunn@munn.com> writes:
Is your report [HACKERS] ERROR: infinite recursion in proc_exit ?
Yes.
Oh. (pout) Is it in the TO_DO or, preferably, the HAS_BEEN_DONE? :-)
AFAIR we fixed that for 7.0 ...
regards, tom lane
From bouncefilter Mon Jan 24 00:28:27 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id AAA75215
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 00:28:13 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA27750;
Mon, 24 Jan 2000 00:27:24 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001240527.AAA27750@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <14760.948691268@sss.pgh.pa.us> from Tom Lane at "Jan 24,
2000 00:21:08 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 24 Jan 2000 00:27:23 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, Don Baccus <dhogaza@pacifier.com>,
Hannu Krosing <hannu@tm.ee>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I think we are spoiled with Tom, Jan, and Vadim who just show up and
produce 100% functional patches the first time.Who, me? Go back and read the CVS logs for all my "oops..." messages.
But you fix your own oops. Sometimes I throw in the towel.
a) 100% functional patches *after* extensive discussion
Usually some one cleans me up. :-) Even with discussion, my stuff is
not 100%.Assuming that Peter is still listening and hasn't given up in disgust,
I think the take-home point here is "discuss first, implement second".
Even the guys who have been working with Postgres the longest are
keenly aware that they don't know all there is to know about the
system. *That's* why we have developed a tradition of sending proposals
to the list before doing anything major. Very often there's someone
who knows a little more than you do about one aspect or another, and
will be able to save you from a mistake.
Yes. We certainly have driven that point home.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 24 01:00:27 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA86708
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 00:59:46 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA14042; Mon, 24 Jan 2000 16:58:41 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd02AB_h;
Mon Jan 24 16:58:16 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
QAA27531; Mon, 24 Jan 2000 16:58:16 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdFXJl0_; Mon Jan 24 16:57:56 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA04953;
Mon, 24 Jan 2000 16:57:55 +1100 (EST)
Received: from majere.design (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
QAA21116; Mon, 24 Jan 2000 16:57:20 +1100 (EST)
Received: from bitmead.com (localhost [127.0.0.1])
by majere.design (8.8.8+Sun/8.8.8) with ESMTP id QAA29381;
Mon, 24 Jan 2000 16:56:37 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <388BE995.B12BF335@bitmead.com>
Date: Mon, 24 Jan 2000 16:56:37 +1100
From: Chris Bitmead <chris@bitmead.com>
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-hackers@postgresql.org
Subject: Re: ORDBMS<->OID (Re: [HACKERS] Happy column dropping)
References: <Pine.BSF.4.21.0001240052020.79710-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
You are the second person that mentioned the ODBMS<->OID tie in ... when
you say ODBMS, is that the same as ORDBMS, or we talking a different
issue?Want to elaborate? Like, since we already have the 'core', I believe,
what does it take to continue that trend?
Hi, yes I am very interested in this issue, and ORDBMS and ODBMS are
rather different.
A long time ago, I wrote up a web page about this issue here...
http://www.tech.com.au/postgres/
which should tell you all my thoughts on this issue. Basicly I can
contribute a LOT of work to the postgres project, but as far as hacking
the back end to achieve it - the learning curve is steep compared to my
available time. But hacking a client side stuff, I could handle.
Enjoy,
Chris Bitmead.
From bouncefilter Mon Jan 24 00:59:27 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA86519
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 00:58:41 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA14949;
Mon, 24 Jan 2000 00:58:38 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Use of Indicies ...
In-reply-to: <Pine.BSF.4.21.0001232301340.79710-100000@thelab.hub.org>
References: <Pine.BSF.4.21.0001232301340.79710-100000@thelab.hub.org>
Comments: In-reply-to The Hermit Hacker <scrappy@hub.org>
message dated "Sun, 23 Jan 2000 23:06:13 -0400"
Date: Mon, 24 Jan 2000 00:58:38 -0500
Message-ID: <14946.948693518@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
There is an index on all three conditions in the WHERE clause:
Yet EXPLAIN shows:
Aggregate (cost=2.05 rows=1 width=4)
-> Index Scan using referrer_link_counter_id on referrer_link (cost=2.05 rows=1 width=4)
Why does EXPLAIN only show the use of one of the indices, why counter_id
and why not all three?
Indexscans only know how to use one index at a time.
The optimizer picked the counter_id index out of the three available
choices because it thought that would be the cheapest (most selective)
alternative --- or, if the computed selectivities were all the same,
just because it happened to try that one first.
Do you have reason to think that one of the other indexes would have
been cheaper?
regards, tom lane
From bouncefilter Mon Jan 24 02:29:28 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA08157
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 02:29:10 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
SAA00047 for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:28:39 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0ljVGs;
Mon Jan 24 18:28:14 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
SAA13575 for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:28:13 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdMH3nW_; Mon Jan 24 18:27:48 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id SAA18459
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:27:43 +1100 (EST)
Received: from majere.design (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
SAA24223 for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:27:03 +1100 (EST)
Received: from bitmead.com (localhost [127.0.0.1])
by majere.design (8.8.8+Sun/8.8.8) with ESMTP id SAA06042
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:26:20 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <388BFE98.E15320B5@bitmead.com>
Date: Mon, 24 Jan 2000 18:26:17 +1100
From: Chris Bitmead <chris@bitmead.com>
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: TOAST suggestion...
References: <Pine.BSF.4.21.0001240052020.79710-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Can I make a suggestion for toast? I don't know how much this is thought
about yet, but it seems like it would be a good idea if large object
support be re-implemented in terms of TOAST (when it is available).
Because current
large objects suck so much.
Can I suggest that the TOAST system should be implemented to allow for
random access?
So for example, to retrieve a whole data member, of course it looks
normal...
SELECT xxx from yyy;
But to retrieve a particular chunk....
SELECT PORTION(xxx, 65535, 131071) from yyy;
to retrieve the 2nd 64k chunk.
This could be useful for many sorts of apps.
From bouncefilter Mon Jan 24 04:49:30 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA42078
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 04:48:36 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id KAA151882;
Mon, 24 Jan 2000 10:47:31 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCAL3JLW>; Mon, 24 Jan 2000 10:47:31 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC214@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>, "'pgsql-hackers@postgreSQL.org'"
<pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Some notes on optimizer cost estimates
Date: Mon, 24 Jan 2000 10:47:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
As best I can measure on my hardware, the cost of a nonsequential
disk read should be estimated at 4 to 5 times the cost of a sequential
one ---
Same experience here with RS6000 AIX hardware.
450k/s random versus 4Mb/s sequential (16kb block readahead)
Compared with 256kb readahead the factor is even worse.
Like 10Mb/s sequential.
Andreas
From bouncefilter Mon Jan 24 04:58:30 2000
Received: from hu.tm.ee (ppp222.tele2.ee [212.107.33.222])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA43011
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 04:57:38 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id BF36E133E3; Mon, 24 Jan 2000 12:03:42 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <388C237E.709510E6@tm.ee>
Date: Mon, 24 Jan 2000 12:03:42 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Use of Indicies ...
References: <Pine.BSF.4.21.0001232301340.79710-100000@thelab.hub.org>
<14946.948693518@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
There is an index on all three conditions in the WHERE clause:
Yet EXPLAIN shows:
Aggregate (cost=2.05 rows=1 width=4)-> Index Scan using referrer_link_counter_id on referrer_link (cost=2.05 rows=1 width=4)
Why does EXPLAIN only show the use of one of the indices, why counter_id
and why not all three?Indexscans only know how to use one index at a time.
would it make sense to implement a new (?) "join" strategy for evaluating
AND's
that gets just tids from affected indices and then performs a multiset AND on
them
sorts the result and then uses the it to access the actual rows.
Do you have reason to think that one of the other indexes would have
been cheaper?
It could be faster if one could actually do the above.
It's just another of these unintuitive things I mentioned in the "Happy
dropping"
thread - common sense guess of optimiser behaviour is not what it actually
done.
--------------
Hannu
From bouncefilter Mon Jan 24 05:28:30 2000
Received: from design.nl (lexington.design.nl [193.78.77.101])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA51601
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 05:28:17 -0500 (EST)
(envelope-from jeroen@design.nl)
Received: from benny (big-dog.design.nl [212.206.76.72])
by design.nl (General Design 1.1) with ESMTP
id LAA21284; Mon, 24 Jan 2000 11:24:38 +0100 (NLD)
Message-Id: <4.2.2.20000124111157.00aa2530@mail.design.nl>
X-Sender: jeroenv@mail.design.nl
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Date: Mon, 24 Jan 2000 11:25:38 +0100
To: Tom Lane <tgl@sss.pgh.pa.us>, Don Baccus <dhogaza@pacifier.com>
From: Jeroen van Vianen <jeroen@design.nl>
Subject: Re: [HACKERS] Implementing STDDEV and VARIANCE
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <14683.948688042@sss.pgh.pa.us>
References: <388B677F.381B10E4@design.nl>
<4.2.0.58.20000123170505.00954560@mail.design.nl>
<6270.948652021@sss.pgh.pa.us> <388B677F.381B10E4@design.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 11:27 PM 1/23/00 -0500, Tom Lane wrote:
Jeroen van Vianen <jeroen@design.nl> writes:
aggname
aggowner
aggtype
aggtranstype [ n, sx, sx2 ]
agginitfunction function that does ( n = 0, sx = 0.0, sx2 = 0.0 )
aggtransfunction function that does ( n = n + 1, sx = sx + x,
sx2 = sx2 + x * x )
aggfinalizefunction function that returns (sx2 - (1/n) * sx * sx ) /
nRight, that's pretty much what I'm visualizing. One minor detail: there
is not an "agginitfunction", there is an "agginitvalue". So your
special datatype to hold n/sx/sx2 must have at least a typinput function
that can convert the text string held in pg_aggregate into the desired
internal form of the initial state. (At least, that's how it's done
now. Do you want to argue to change it? As long as we're opening up
the AGG design for reconsideration, we could revisit that choice too.)
I would suggest supplying an initfunction that initializes the datatype
that holds n/sx/sx2 so you're able to set individual members to NULL if so
desired. I also won't need to implement typinput for all required aggregate
types, one small headache less ;-)
count --> int4
min/max --> basetype
sum --> basetype
avg --> basetype, n
stddev, variance --> n, basetype, basetype
Might it be better for me to wait for 7.1 before implementing stddev and
variance?Well, you will need to be pretty fast on the draw if you want to get it
into 7.0 release, since we will be freezing features for beta in a week.
True.
But I see no reason that you couldn't implement STDDEV within the
existing framework; just ignore transfn2 and do it as above. You might
have some problems with getting the desired response for zero or one
tuples, but there isn't any way to fix that within the current
framework :-(. We have to do the function manager rewrite before you
can have control over when to return a NULL. As long as you are willing
to live with that, you can have useful functionality now.
The problem with zero or one rows is pretty important IMO if you want to
implement stddev and variance for both population and sample. You won't be
able to explain the difference in outcome if you don't do it right.
Let me wait for you to overhaul the fmgr code and do all the aggregate
stuff right in one sweep. Only thing is: how do we deal with current
user-defined aggregates?
At 09:02 PM 1/23/00 -0800, Don Baccus wrote:
At 11:27 PM 1/23/00 -0500, Tom Lane wrote:
Right, that's pretty much what I'm visualizing. One minor detail: there
is not an "agginitfunction", there is an "agginitvalue". So your
special datatype to hold n/sx/sx2 must have at least a typinput function
that can convert the text string held in pg_aggregate into the desired
internal form of the initial state. (At least, that's how it's done
now. Do you want to argue to change it? As long as we're opening up
the AGG design for reconsideration, we could revisit that choice too.)At the moment I have a hard time visualizing an aggregate function where
a constant initializer wouldn't serve, but ... what would be the cost of
the generalization? It would only be called once per query or subquery
containing the aggregate, right?
Initializer functions for count need to return 0, for min, max, avg, sum,
stddev and variance they need to set individual members to NULL (at least
that's how I see it now). A function returning this (with the new fmgr
code) would be very easy to implement (I hope ;-) ).
I'll hold my breath until the dust settles and we're starting 7.1.
Jeroen
From bouncefilter Mon Jan 24 05:55:31 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA58143
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 05:54:35 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id LAA168918;
Mon, 24 Jan 2000 11:53:55 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCAL3J99>; Mon, 24 Jan 2000 11:53:55 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC215@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Jeroen van Vianen'" <jeroen@design.nl>,
"'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Implementing STDDEV and VARIANCE
Date: Mon, 24 Jan 2000 11:53:45 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
2. I am proposing the names stddev(x) and variance(x) for
population and
samplestddev(x) and
samplevariance(x) for sample statistics. Any comments?
Other db's have:
stdev() for standard deviation sample (N-1)
variance() for variance computed from a sample (N-1)
3. I'm planning to implement this for types float4, float8
and numeric. Any
other types also? int[2,4,8] don't seem logical, as these
would introduce
serious rounding errors.
Integer would be good also. Do the arithmetic in numeric
to avoid loss of precision.
Andreas
From bouncefilter Mon Jan 24 06:00:31 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA59064
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 06:00:18 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id MAA169128
for <pgsql-hackers@postgreSQL.org>; Mon, 24 Jan 2000 12:00:16 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCAL3J00>; Mon, 24 Jan 2000 12:00:16 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC216@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'PostgreSQL-development'" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] column aliases
Date: Mon, 24 Jan 2000 12:00:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
What it looks like to me is that we have a bug in the
expansion of '*'.
It should be generating columns for both the explicit and
the implicit
FROM clause, but it's evidently deciding that it should only produce
output columns for the first one.Yes, since it is joining the two tables it should be returning all
columns of the join.This may go a long way towards explaining why people have been so
readily confused by the implicit-FROM-clause business!It *is* confusing, that's for sure!
IMHO, if there exists a from clause, we could insist,
that all tables are listed (no implicitly added table),
since it is really too error prone.
What I would not like to see removed is the ability to
avoid the from clause alltogether. Like in:
select xor.eval;
Andreas
From bouncefilter Mon Jan 24 06:13:31 2000
Received: from netrinsics.com ([202.106.6.112])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA68672
for <pgsql-hackers@hub.org>; Mon, 24 Jan 2000 06:12:32 -0500 (EST)
(envelope-from robinson@netrinsics.com)
Received: (from robinson@localhost)
by netrinsics.com (8.9.3/8.9.3) id TAA20988;
Mon, 24 Jan 2000 19:12:46 +0800 (+0800) (envelope-from robinson)
Date: Mon, 24 Jan 2000 19:12:46 +0800 (+0800)
From: Michael Robinson <robinson@netrinsics.com>
Message-Id: <200001241112.TAA20988@netrinsics.com>
To: pgsql-hackers@hub.org
Subject: fatal copy in/out error (6.5.3)
Do this:
testdb=> create table foo (word varchar(30));
CREATE
testdb=> insert into foo values ('\217\210');
INSERT 2337289 1
testdb=> copy "foo" to '/usr/local/pgsql/foo.out';
COPY
testdb=> \q
% od -c foo.out
0000000 217 210 \0 \n
0000004
One run produced:
0000000 217 210 \0 \b \n
In all cases, though, it emits a null. This, of course, causes "copy from" to
fail when it tries to parse a null-containing field in a multi-field record.
As for what the sequence "\217\210" represents, that's not really relevant
(it's not even a valid Chinese character, so far as I can tell). Someone
just entered this into our web interface and broke our database.
-Michael Robinson
P.S. As an aside, if "copy from" recognizes the \xxx octal convention, why
doesn't "copy to" use it to represent everything outside of \040..\176?
From bouncefilter Mon Jan 24 07:16:32 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA82390
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 07:15:39 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Elefant.DoCS.UU.SE (e99re41@Elefant.DoCS.UU.SE [130.238.9.181])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id NAA12371;
Mon, 24 Jan 2000 13:15:33 +0100 (MET)
Received: from localhost (e99re41@localhost) by Elefant.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA12589;
Mon, 24 Jan 2000 13:15:29 +0100
X-Authentication-Warning: Elefant.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 24 Jan 2000 13:15:27 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: The Hermit Hacker <scrappy@hub.org>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <Pine.BSF.4.21.0001230017180.79710-100000@thelab.hub.org>
Message-ID: <Pine.GSO.4.02A.10001241313230.12556-100000@Elefant.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 23 Jan 2000, The Hermit Hacker wrote:
Its not the *risk* that bothers me, its the lack of discussions ... IMHO,
he should have brought up the "I'm in the process of toasting the reliance
on OIDs" topic *before* implementing it ... give other ppl a chance to
possibly present alternatives ...
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Alain TESIO <tesio@easynet.fr>
Subject: Re: [GENERAL] A script which drops a column
Date: Thu, 25 Nov 1999 23:36:42 -0500 (EST)
Hello,
You may be interested by a script which drops a column as this
feature isn't supported by Postgresql. I guess it could be easier
and nice in Perl or something similar but I'm using what I know.The parameters are in that order :
the name of the database
the table
the column to dropAlain
#!/bin/sh
psql -d $1 -c "\d $2" | awk 'BEGIN { keep=1 } /+-/ { keep=1-keep } { if
(keep) { print } }' | grep -v "\-\-" | grep -v "Table *=" | grep -v " $3
" |
sed "s/| \([^ ]*\).*/\1/" | tr -s \\012 "," | sed "s/,$//" | sed
"s/\(.*\)/select \1 into temp tmp_drop_column from $2 ; drop table $2 ;
select * into $2 from tmp_drop_column;/" > tmp_sql_drop_column
psql -d $1 -f tmp_sql_drop_column
rm tmp_sql_drop_column
The fact is that internally this is exactly what we would have to do to
drop a column. Now that we have temp tables, maybe someone could code
up some C to do this, or just an pg_exec_query_dest() call to do the
job.
--
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 19026I think what I did is significantly better than that, and of course it
will be cleaned up by next week.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 24 07:34:32 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA88094
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 07:33:39 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12CidC-0007JH-00; Mon, 24 Jan 2000 12:30:06 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12Cid6-0007Qc-00; Mon, 24 Jan 2000 12:30:00 +0000
Date: Mon, 24 Jan 2000 12:30:00 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgresql.org
Subject: Re: pg_dump possible fix, need testers.
Message-ID: <20000124123000.C21345@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <20000122220256.H26520@fw.wintelcom.net>;
from bright@wintelcom.net on Sat, Jan 22, 2000 at 10:02:56PM -0800
On Sat, Jan 22, 2000 at 10:02:56PM -0800, Alfred Perlstein wrote:
I really hope the originator of the problem report will get back to
us to make sure it's settled.*poking Patrick Welche*
:)
Morning all!
Things are still not so good for me. The pg_dumpall > file, psql < file did
work, but later:
newnham=> select * from crsids,"tblPerson" where
newnham-> crsids.crsid != "tblPerson"."CRSID";
Backend sent B message without prior T
D21Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
which smells like a similar problem. (Note that this is a join. Straight
selects didn't cause problems)
While running that query, I ran the regression tests, so the ERRORs in the
log are OK, but just in case, here are the last two lines before the above
message:
postmaster: dumpstatus:
sock 5
After typing \. at the prompt
Unknown protocol character 'M' read from backend. (The protocol character
is the first character the backend sends in response to a query it
receives).
PQendcopy: resetting connection
Asynchronous NOTIFY 'ndropoulou' from backend with pid '1818589281'
received.
Asynchronous NOTIFY 'ndropoulou' from backend with pid '1818589281'
received.
and in the log:
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe
...
"ndropoulou" is an incomplete piece of select * data.
(New also, though probably unrelated: the sanity check fails with number of
index tuples exactly half number in heap - not equal)
For any more info, just ask!
Cheers,
Patrick
From bouncefilter Mon Jan 24 08:02:34 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA93118
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 08:02:07 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA95415;
Mon, 24 Jan 2000 09:00:59 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 24 Jan 2000 09:00:58 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <Pine.GSO.4.02A.10001241313230.12556-100000@Elefant.DoCS.UU.SE>
Message-ID: <Pine.BSF.4.21.0001240856020.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 24 Jan 2000, Peter Eisentraut wrote:
I think what I did is significantly better than that, and of course it
will be cleaned up by next week.
From a discussion with Bruce over the past 24hrs, as well as was mentioned
by Hannu on this list ... we effectively do this with VACUUM, so "copying"
that logic should be, I imagine, relatively easy, *and* it preserves OIDs
*and* it doesn't require 2x the space...
I imagine that DROP COLUMN isn't used that often, so the time it takes to
do this isn't an issue ...
=================
One thing I've never been able to figure out ... why isn't implementing
DROP COLUMN a simple matter of "lock table;remove field from pg_*;rebuild
table", similar to the way that we do when we vacuum?Because the column is still in the table, just invisible after removing
from pg_attribute. You need to remove the column from the heap, and
that requires creating a new version of the table. Vacuum moves tuples
but does not make them shorter.
That I understand ... excuse my ignorance, but what would it take to
do that? The way I envision a table 'on disk':
col1col2col3col4col5|col1col2col3col4col5|col1col2col3col4col5|
Basically, you have X tuples per page, where a page is 8192bytes,
correct? If you were to remove, let's say, col2 out of the table, why
can't you do:
lock table
read page 1 into memory
rewrite page1 to disk as:
col1col3col4col5|col1col3col4col5|col1col3col4col5|
add one to page and goto 'read page n to memory'
unlock table
I'm making an assumption here ... first one being that each 'tuples' has
some sort of endoftuple marker in the table ...
If we're removing a column, the resultant 'page size' from the modified
page is going to be smaller then the original, so I would think it would
be a relatively simple thing, considering that its a read/re-write from
the same part of the 'on disk file' ...
... and it wouldn't require 2X the space used by the table ...
===================
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Jan 24 08:06:32 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA95655
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 08:05:56 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA95456;
Mon, 24 Jan 2000 09:04:57 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 24 Jan 2000 09:04:37 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Use of Indicies ...
In-Reply-To: <14946.948693518@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001240901590.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 24 Jan 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
There is an index on all three conditions in the WHERE clause:
Yet EXPLAIN shows:
Aggregate (cost=2.05 rows=1 width=4)-> Index Scan using referrer_link_counter_id on referrer_link (cost=2.05 rows=1 width=4)
Why does EXPLAIN only show the use of one of the indices, why counter_id
and why not all three?Indexscans only know how to use one index at a time.
The optimizer picked the counter_id index out of the three available
choices because it thought that would be the cheapest (most selective)
alternative --- or, if the computed selectivities were all the same,
just because it happened to try that one first.Do you have reason to think that one of the other indexes would have
been cheaper?
Nope, just looked weird that not all three were used, that's all
... someone else responded to me on this with a similar response
... basically, that it didn't make sense to use all three indices since it
there would be no 'index' on the result of the first condition ...
Ie. if 'counter_id = ?' returned 4 tuples out of 40000, why look at those
40000 again for 'referrer_url = ?', when you already know that only 4
match the first condition ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Jan 24 08:27:33 2000
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 IAA99841
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 08:27:23 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id WAA18402
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 22:27:18 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-14 [133.137.84.14])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id WAA09596
for <pgsql-hackers@postgresql.org>; Mon, 24 Jan 2000 22:27:16 +0900
To: pgsql-hackers@postgresql.org
Subject: PQputline failed
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000124222938A.t-ishii@sra.co.jp>
Date: Mon, 24 Jan 2000 22:29:38 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 14
While populating a table using PQputline(), I have encountered a
PQputline() error (PQputline() returns none 0). It seems ok until it
puts 6664 records. I've never seen this in 6.5.*, and am wondering if
this is related to the recent changes made to libpq. Have I found a
new problem or it is just a known one with the current source tree?
FYI, to reproduce the problem, do followings:
cd pgsql/contrib/pgbench
make
(create fresh DB)
./pgbench -i the_DB_just_created
--
Tatsuo Ishii
From bouncefilter Mon Jan 24 09:16:33 2000
Received: from sultan.intranet.org (root@ppp-155.net10.magic.fr
[195.154.128.155]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA14562
for <pgsql-interfaces@postgresql.org>;
Mon, 24 Jan 2000 09:15:54 -0500 (EST) (envelope-from advl@advl.org)
Received: from localhost (localhost [[UNIX: localhost]])
by sultan.intranet.org (8.9.3/8.9.3) id PAA01587;
Mon, 24 Jan 2000 15:20:58 +0100
From: Compte utilisateur Sultan-advl <webmaster@advl.org>
Reply-To: webmaster@advl.org
Organization: ADVL
To: Jose Soares <jose@sferacarta.com>
Subject: Re: [INTERFACES] Re: ODBC drive strange behavior
Date: Mon, 24 Jan 2000 15:01:30 +0100
X-Mailer: KMail [version 1.0.21]
Content-Type: text/plain
References: <38881FC3.D34B1BEC@sferacarta.com>
Cc: pgsql-interfaces@postgresql.org
MIME-Version: 1.0
Message-Id: <00012415205702.01357@sultan>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id JAA14654
Le ven, 21 jan 2000, vous avez ���crit :
%_Sorry I forgot to send the attachement :)
Jose Soares wrote:
Data base server: PostgreSQL v6.5.2
OS server: Linux 2.0.37 (Debian)
Win Client: M$_Access95
PsqlODBC v6.40.0006
log file attached.Any help would be very apreciated.
Jos���
In my case using M$_Access97 without problem.
a)Try to upgrade to PsqlODBC v6.40.0007
b)Try to tune your odbc DSN with the help of PsqlODBC FAQ
c)Try to upgrade MDAC (odbc32 ==> About) in control panel
Regards.
Emmanuel
From bouncefilter Mon Jan 24 09:45:11 2000
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA21615
for <pgsql-general@postgresql.org>;
Mon, 24 Jan 2000 09:44:33 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (sfcabop1.nettuno.it [193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id PAA08605;
Mon, 24 Jan 2000 15:42:51 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 12Cld5-0003GU-00; Mon, 24 Jan 2000 15:42:11 +0000
Message-ID: <388C6577.A14466BD@sferacarta.com>
Date: Mon, 24 Jan 2000 15:45:11 +0100
From: Jose Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, Marc Tardif <admin@wtbwts.com>,
pgsql-general@postgresql.org
Subject: Re: [GENERAL] max(oid)
References: <Pine.LNX.4.21.0001221730360.3007-100000@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Peter Eisentraut wrote:
On 2000-01-21, Bruce Momjian mentioned:
Is there a way to use the max aggregate on an oid field? When I try on
6.5.3, I get the following error message:test=> select max(uid) from user_base;
ERROR: Unable to select an aggregate function max(oid)If there's any work-around, please let me know.
MarcAdded to TODO:
* allow aggregates on oid
We already had a TODO item for this and came to the conclusion that
* Make type equivalency apply to aggregates
will solve this.For right now the user could do the following:
INSERT INTO pg_aggregate VALUES ('max', <your user id>, 'int4larger', '-',
'-', 26, 26, 0, 26, NULL, NULL);
We need also aggregates for data type TIME
MAX(time)
MIN(time)
Jos���
From bouncefilter Mon Jan 24 09:52:33 2000
Received: from meryl.it.uu.se (root@meryl.it.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA22462
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 09:51:46 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krokodil.DoCS.UU.SE (e99re41@Krokodil.DoCS.UU.SE
[130.238.9.184])
by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id PAA26943
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 15:51:43 +0100 (MET)
Received: from localhost (e99re41@localhost) by Krokodil.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id PAA10985 for
<pgsql-hackers@postgresql.org>; Mon, 24 Jan 2000 15:51:41 +0100
X-Authentication-Warning: Krokodil.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 24 Jan 2000 15:51:41 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgresql.org
Subject: Well, then you keep your darn columns
Message-ID: <Pine.GSO.4.02A.10001241520480.10921-100000@Krokodil.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Let me thank all of those that spoke up in my support and let me tell of
those that were unhappy that I _will_ be here tomorrow as well. To
summarize the points and add a few of my own:
1) This is a TODO item.
2) I have reviewed several mutterings about how to implement this in the
archives and followed the consensus that you need to copy the table over
somehow. It's not like I made this up.
2a) Does anyone have a better idea? (Btw., I'm not too excited about
by-passing the storage manager and writing around in the table file on
disk. If vacuum does that, that doesn't mean it's the right thing to do.)
3) This isn't release software.
4) This isn't done. (But it will be.)
4a) If it won't get done then I add one line and it's disabled. I'm not
that dumb.
5) This isn't documented, so if you don't call the command then your life
goes on.
6) Users have been begging for this but nobody else has moved a finger.
7) If you are concerned about "perfect" implementation, then I invite you
to take a look at the create/drop user and create/drop database code from
6.5 and thank whomever you do thank that your database isn't fried yet.
8) Now that I know how to keep the oids around, they will be kept around.
(Thanks to those that interpreted my message as a starting point for a
discussion and not me laying down the law.)
9) What really gets me though is what your problem is. This is a nearly
SQL-compliant implementation of a very important feature. It doesn't
affect the rest of the code. It doesn't break the regression tests. It
checks for permissions, validity of parameters, etc. and even if it goes
wrong, it doesn't fry your database or any part of it.
Um, anyway, I'm open for implementation specific suggestions. I don't like
the coying either but it works.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 24 10:07:33 2000
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 KAA28304
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 10:06:56 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA04098;
Mon, 24 Jan 2000 15:12:00 GMT
Sender: lockhart@hub.org
Message-ID: <388C6BC0.948A4009@alumni.caltech.edu>
Date: Mon, 24 Jan 2000 15:12:00 +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: pgsql-hackers@postgreSQL.org
Subject: Re: Doc updates for index cost estimator change
References: <2071.948585763@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
There isn't (AFAICT) any existing documentation about how to make
a new kind of index, which would be the proper place for it.
May I impose on you to find/make a place for this and mark it up
properly?
OK.
Also, doc/src/graphics/catalogs.ag needs to be updated, but I have
no idea how. (The amopselect and amopnpages fields of pg_amop
are gone; pg_am has a new field amcostestimate.)
The primary graphics files should be .cgm files, but I see that we
only have those for one or two cases. The .ag files are Applix
Graphics files, which I use to embed the stuff into hardcopy.
I'll see about updating them, and committing a .cgm version of each.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 24 10:17:33 2000
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 KAA29743
for <docs@postgreSQL.org>; Mon, 24 Jan 2000 10:17:31 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA04103;
Mon, 24 Jan 2000 15:15:06 GMT
Sender: lockhart@hub.org
Message-ID: <388C6C7A.4FF0DB72@alumni.caltech.edu>
Date: Mon, 24 Jan 2000 15:15:06 +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: Mark Hollomon <mhh@nortelnetworks.com>,
Michael Alan Dorman <mdorman@debian.org>,
Postgres Documentation List <docs@postgreSQL.org>
Subject: Re: [DOCS] Re: [HACKERS] Building Documentation under Debian
References: <Pine.LNX.4.21.0001221742020.3007-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I think a lot of people found sgmltools to work for them (and perhaps a
lot more would, if they knew about it). That way you don't have to get
five different things and tune them to each other.
Currently, sgmltools is in an essentially unsupported state. Cees De
Groot has tried to enlist additional developers, to no avail, and has
resigned.
But if someone has a procedure to install sgmltools and can give the
mods for the makefiles we already have I'll be happy to put it in the
docs.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 24 10:39:34 2000
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA36178;
Mon, 24 Jan 2000 10:39:20 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (sfcabop1.nettuno.it [193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id QAA23754;
Mon, 24 Jan 2000 16:39:12 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 12CmHH-0003IC-00; Mon, 24 Jan 2000 16:23:43 +0000
Message-ID: <388C6F34.608E5E4A@sferacarta.com>
Date: Mon, 24 Jan 2000 16:26:44 +0100
From: Jose Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Byron Nikolaidis <byron.nikolaidis@home.com>
CC: interfaces <pgsql-interfaces@postgresql.org>,
hackers <pgsql-hackers@postgresql.org>
Subject: Re: [INTERFACES] Re: ODBC drive strange behavior
References: <38881F35.CAA49A56@sferacarta.com>
<38881FC3.D34B1BEC@sferacarta.com> <3889DD8D.32ACABD8@home.com>
Content-Type: multipart/alternative;
boundary="------------420A31138A746F2AC6E116CF"
--------------420A31138A746F2AC6E116CF
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Byron Nikolaidis wrote:
Jose Soares wrote:
Sorry I forgot to send the attachement :)
Jose Soares wrote:
Please help!
The PSQLODBC aborts a transaction with a strange error while execute a
legal query.
The message is:"Could not begin a transaction; unexpected protocol character from
backend (sen_query) (#1)"I tried the same query with psql client and it works with no problems.
Does anyone know what this message means ?
My configuration:
Data base server: PostgreSQL v6.5.2
OS server: Linux 2.0.37 (Debian)
Win Client: M$_Access95
PsqlODBC v6.40.0006
log file attached.Any help would be very apreciated.
Jos���
------------------------------------------------------------------------
Name: LOG_ERROR.log
LOG_ERROR.log Type: Text Document (application/x-unknown-content-type-txtfile)
Encoding: base64The error means the driver didn't receive the expected response
character from the backend. For queries, the expected response would be
something like:'T': results are coming (this one is the most likely expected)
'C': no tuples produced
'Z': ready for new query (in >= postgres 6.4 only).
'I': empty query produces this response
'N': notice
'E': errorIn your case, the query begins: (SELECT "figure"."azienda"
It might be the extra parenthesis around the query ? Try removing
them. If that's not it, try making the query really short, just as an
experiment. Also, using the wrong protocol with the backend can make
this happen.Byron
* About parenthesis around select this is the way M$-access translates
queries with UNIONs and I can't do nothing to change this behavior.
Thanks to developers, PostgreSQL now recognizes this syntax, in fact if I execute this
query on psql
it works.
* Just for an experiment I did the following change:
* The original query in M$-access was:
(
SELECT figure.azienda ,figure.codice_figura ,utenti.ragione_sociale ,utenti.istat
,utenti.cap,
utenti.indirizzo ,utenti.civico ,figure.tipo ,utenti.codice_fiscale
,utenti.partita_iva ,
figure.fine_attivita ,figure.data_esportazione ,figure.data_aggiornamento
,utenti.distretto,
figure.gruppo ,figure.data_esportazione ,utenti.data_esportazione
FROM figure INNER JOIN utenti ON (figure.codice_figura = utenti.azienda)
WHERE (figure.tipo IN ('D' ,'DB' ,'DO' ,'DS' ) )
)
UNION ALL
(
SELECT figure.azienda ,figure.codice_figura ,utenti.ragione_sociale ,utenti.istat ,
utenti.cap ,utenti.indirizzo,utenti.civico,figure.tipo,utenti.codice_fiscale,
utenti.partita_iva ,figure.fine_attivita ,figure.data_esportazione,
figure.data_aggiornamento,utenti.distretto,figure.gruppo,figure.data_esportazione,
utenti.data_esportazione
FROM figure INNER JOIN utenti ON (figure.codice_figura = utenti.azienda)
WHERE (figure.tipo IN ('P' ,'PB' ,'PO' ,'PS' ,'A' ) )
)
and it was translated to PostgreSQL as:
(SELECT "figure"."azienda" ,"figure"."codice_figura" ,"utenti"."ragione_sociale"
,"utenti"."istat" ,"utenti"."cap" ,"utenti"."indirizzo" ,"utenti"."civico"
,"figure"."tipo" ,"utenti"."codice_fiscale" ,"utenti"."partita_iva"
,"figure"."fine_attivita" ,"figure"."data_esportazione" ,"figure"."data_aggiornamento"
,"utenti"."distretto" ,"figure"."gruppo" ,"figure"."data_esportazione"
,"utenti"."data_esportazione"
FROM "figure","utenti"
WHERE (("figure"."tipo" IN ('D' ,'DB' ,'DO' ,'DS' ) )
AND ("figure"."codice_figura" = "utenti"."azienda" ) )
)
UNION ALL
(
SELECT "figure"."azienda" ,"figure"."codice_figura" ,"utenti"."ragione_sociale"
,"utenti"."istat" ,"utenti"."cap" ,"utenti"."indirizzo" ,"utenti"."civico"
,"figure"."tipo" ,"utenti"."codice_fiscale" ,"utenti"."partita_iva"
,"figure"."fine_attivita" ,"figure"."data_esportazione" ,"figure"."data_aggiornamento"
,"utenti"."distretto" ,"figure"."gruppo" ,"figure"."data_esportazione"
,"utenti"."data_esportazione"
FROM "figure","utenti"
WHERE (("figure"."tipo" IN ('P' ,'PB' ,'PO' ,'PS' ,'A' ) )
AND ("figure"."codice_figura" = "utenti"."azienda" ) )
)
I replaced the keyword INNER with LEFT and now it works but I can't realize why.
Any ideas Byron ?
Thanks,
Jos���
--------------420A31138A746F2AC6E116CF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Byron Nikolaidis wrote:
<blockquote TYPE=CITE>Jose Soares wrote:
<br>>
<br>> Sorry I forgot to send the attachement :)
<br>>
<br>> Jose Soares wrote:
<br>>
<br>> > Please help!
<br>> >
<br>> > The PSQLODBC aborts a transaction with a strange error while execute
a
<br>> > legal query.
<br>> > The message is:
<br>> >
<br>> > "Could not begin a transaction; unexpected protocol character from
<br>> > backend (sen_query) (#1)"
<br>> >
<br>> > I tried the same query with psql client and it works with no problems.
<br>> >
<br>> > Does anyone know what this message means ?
<br>> >
<br>> > My configuration:
<br>> >
<br>> > Data base server: PostgreSQL v6.5.2
<br>> > OS server: Linux 2.0.37 (Debian)
<br>> > Win Client: M$_Access95
<br>> > PsqlODBC v6.40.0006
<br>> > log file attached.
<br>> >
<br>> > Any help would be very apreciated.
<br>> >
<br>> > José
<br>>
<br>> ------------------------------------------------------------------------
<br>>
Name: LOG_ERROR.log
<br>> LOG_ERROR.log Type: Text Document
(application/x-unknown-content-type-txtfile)
<br>>
Encoding: base64
<p>The error means the driver didn't receive the expected response
<br>character from the backend. For queries, the expected response
would be
<br>something like:
<p>'T': results are coming (this one is the most likely expected)
<br>'C': no tuples produced
<br>'Z': ready for new query (in >= postgres 6.4 only).
<br>'I': empty query produces this response
<br>'N': notice
<br>'E': error
<p>In your case, the query begins: (SELECT "figure"."azienda"
<p>It might be the extra parenthesis around the query ? Try removing
<br>them. If that's not it, try making the query really short, just
as an
<br>experiment. Also, using the wrong protocol with the backend can
make
<br>this happen.
<p>Byron</blockquote>
<u>* About parenthesis around select this is the way M$-access translates</u>
<br><u>queries with UNIONs and I can't do nothing to change this behavior.</u>
<br><u>Thanks to developers, PostgreSQL now recognizes this syntax, in
fact if I execute this query on psql</u>
<br><u>it works.</u>
<p><u>* Just for an experiment I did the following change:</u><u></u>
<p><u>* The original query in M$-access was:</u>
<br>(
<br>SELECT figure.azienda ,figure.codice_figura ,utenti.ragione_sociale
,utenti.istat ,utenti.cap,
<br> utenti.indirizzo ,utenti.civico ,figure.tipo ,utenti.codice_fiscale
,utenti.partita_iva ,
<br> figure.fine_attivita ,figure.data_esportazione ,figure.data_aggiornamento
,utenti.distretto,
<br> figure.gruppo ,figure.data_esportazione ,utenti.data_esportazione
<br>FROM figure INNER JOIN utenti ON (figure.codice_figura = utenti.azienda)
<br>WHERE (figure.tipo IN ('D' ,'DB' ,'DO' ,'DS' ) )
<br> )
<br>UNION ALL
<br>(
<br>SELECT figure.azienda ,figure.codice_figura ,utenti.ragione_sociale
,utenti.istat ,
<br> utenti.cap ,utenti.indirizzo,utenti.civico,figure.tipo,utenti.codice_fiscale,
<br> utenti.partita_iva ,figure.fine_attivita ,figure.data_esportazione,
<br> figure.data_aggiornamento,utenti.distretto,figure.gruppo,figure.data_esportazione,
<br> utenti.data_esportazione
<br>FROM figure INNER JOIN utenti ON (figure.codice_figura = utenti.azienda)
<br>WHERE (figure.tipo IN ('P' ,'PB' ,'PO' ,'PS' ,'A' ) )
<br>)
<p><u>and it was translated to PostgreSQL as:</u>
<p>(SELECT "figure"."azienda" ,"figure"."codice_figura" ,"utenti"."ragione_sociale"
,"utenti"."istat" ,"utenti"."cap" ,"utenti"."indirizzo" ,"utenti"."civico"
,"figure"."tipo" ,"utenti"."codice_fiscale" ,"utenti"."partita_iva" ,"figure"."fine_attivita"
,"figure"."data_esportazione" ,"figure"."data_aggiornamento" ,"utenti"."distretto"
,"figure"."gruppo" ,"figure"."data_esportazione" ,"utenti"."data_esportazione"
<br>FROM "figure","utenti"
<br>WHERE (("figure"."tipo" IN ('D' ,'DB' ,'DO' ,'DS' ) )
<br>AND ("figure"."codice_figura" = "utenti"."azienda" ) )
<br>)
<br>UNION ALL
<br>(
<br>SELECT "figure"."azienda" ,"figure"."codice_figura" ,"utenti"."ragione_sociale"
,"utenti"."istat" ,"utenti"."cap" ,"utenti"."indirizzo" ,"utenti"."civico"
,"figure"."tipo" ,"utenti"."codice_fiscale" ,"utenti"."partita_iva" ,"figure"."fine_attivita"
,"figure"."data_esportazione" ,"figure"."data_aggiornamento" ,"utenti"."distretto"
,"figure"."gruppo" ,"figure"."data_esportazione" ,"utenti"."data_esportazione"
<br>FROM "figure","utenti"
<br>WHERE (("figure"."tipo" IN ('P' ,'PB' ,'PO' ,'PS' ,'A' ) )
<br>AND ("figure"."codice_figura" = "utenti"."azienda" ) )
<br>)
<p><u>I replaced the keyword INNER with LEFT and now it works but I can't
realize why.</u><u></u>
<p><u>Any ideas Byron ?</u><u></u>
<p><u>Thanks,</u>
<br><u>José</u>
<br><u></u> </html>
--------------420A31138A746F2AC6E116CF--
From bouncefilter Mon Jan 24 10:31:37 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA31923
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 10:30:37 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id KAA25174;
Mon, 24 Jan 2000 10:29:59 -0500 (EST)
To: Jeroen van Vianen <jeroen@design.nl>
cc: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Implementing STDDEV and VARIANCE
In-reply-to: <4.2.2.20000124111157.00aa2530@mail.design.nl>
References: <388B677F.381B10E4@design.nl>
<4.2.0.58.20000123170505.00954560@mail.design.nl>
<6270.948652021@sss.pgh.pa.us> <388B677F.381B10E4@design.nl>
<4.2.2.20000124111157.00aa2530@mail.design.nl>
Comments: In-reply-to Jeroen van Vianen <jeroen@design.nl>
message dated "Mon, 24 Jan 2000 11:25:38 +0100"
Date: Mon, 24 Jan 2000 10:29:58 -0500
Message-ID: <25171.948727798@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Jeroen van Vianen <jeroen@design.nl> writes:
Right, that's pretty much what I'm visualizing. One minor detail: there
is not an "agginitfunction", there is an "agginitvalue". So your
special datatype to hold n/sx/sx2 must have at least a typinput function
that can convert the text string held in pg_aggregate into the desired
internal form of the initial state. (At least, that's how it's done
now. Do you want to argue to change it? As long as we're opening up
the AGG design for reconsideration, we could revisit that choice too.)
I would suggest supplying an initfunction that initializes the datatype
that holds n/sx/sx2 so you're able to set individual members to NULL if so
desired. I also won't need to implement typinput for all required aggregate
types, one small headache less ;-)
I've been thinking about this and have come to the conclusion that using
an initial value string and a typinput function is still the right design,
compared to using a parameterless initializer function. See, that way
you have a shot at reusing the same transition type (and typinput code)
for several different aggregates with slightly different initial
condition requirements, whereas with the initializer-function approach,
you have no choice but to write a separate initializer function for each
aggregate initial condition you need.
I have been thinking that we could save some effort (at a trivial cost
in memory) by defining a datatype or two that is specifically intended
to be an aggregate transition state datatype. For example, a struct
containing three or four float8 fields and as many bool fields would
serve nicely for AVG, STDDEV, and probably some other aggregates; some
of them wouldn't use all the fields, but so what? The only support code
this datatype would need would be a typinput function to convert a
string from pg_aggregate into initial struct contents. By doing it that
way, the same datatype can support several aggregates with different
initial condition requirements, without having to write a separate
initializer function for each one.
I think the point about initializing struct contents to NULL is a red
herring. For basic C types like float8, there isn't such a thing as
NULL really; you have to have a separate flag field or count field to
tell you that you've seen no input yet. That can be initialized equally
well by a typinput function or by an initializer function. But the
typinput function gets to have a parameter taken from pg_aggregate;
an initializer function would not.
Let me wait for you to overhaul the fmgr code and do all the aggregate
stuff right in one sweep. Only thing is: how do we deal with current
user-defined aggregates?
Well, a user aggregate that only used transfn1, or only transfn2, would
convert directly. This scheme would break user aggregates that used
both, which is why I'm running it up the flagpole early --- to see if
anyone complains.
regards, tom lane
From bouncefilter Mon Jan 24 10:45:34 2000
Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA37360
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 10:45:29 -0500 (EST)
(envelope-from thuann@internic.net)
Received: from localhost (thuann@localhost)
by opsmail.internic.net (8.9.3/8.9.1) with ESMTP id KAA28831
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 10:44:59 -0500 (EST)
Date: Mon, 24 Jan 2000 10:44:59 -0500 (EST)
From: "Nguyen, Thuan X" <thuann@internic.net>
To: pgsql-hackers@postgreSQL.org
Subject: unsubscribe
In-Reply-To: <25171.948727798@sss.pgh.pa.us>
Message-ID: <Pine.SV4.4.10.10001241044350.26319-100000@opsmail.internic.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
unsubscribe
From bouncefilter Mon Jan 24 10:48:34 2000
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 KAA37924
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 10:48:26 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.8/MAPS) with ESMTP
id RAA23066; Mon, 24 Jan 2000 17:48:09 +0200 (EET)
Sender: a.joubert@albourne.com
Message-ID: <388C7420.D2D5A32C@albourne.com>
Date: Mon, 24 Jan 2000 15:47:44 +0000
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
References: <Pine.GSO.4.02A.10001241520480.10921-100000@Krokodil.DoCS.UU.SE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
As a user let me just say that I have been waiting for all the
'ALTER TABLE..' commands for a long time (changing constraints would be great
too!) and it has been mentioned many times that one should not use oids in
application code. The way I do it at the moment is to copy the table, so I
think all users are used to losing their oids when remocing a column from a
table. So while it is certainly better to keep the oids, Peter's code is a
big improvement on the current situation.
While I do understand and subscribe to the concerns about database
reliability, I would very much not like to keep my darn columns and thank
Peter for helping me get rid of them.
Adriaan
From bouncefilter Mon Jan 24 10:50:37 2000
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 KAA38173
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 10:50:02 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA04151;
Mon, 24 Jan 2000 15:58:09 GMT
Sender: lockhart@hub.org
Message-ID: <388C7691.C86A4AC3@alumni.caltech.edu>
Date: Mon, 24 Jan 2000 15:58:09 +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 <pgman@candle.pha.pa.us>, Jan Wieck <jwieck@debis.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Status on 7.0
References: <Pine.LNX.4.21.0001230158300.3007-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Well, rather than creating a huge potential hazard for everyone two weeks
before beta I'm going to settle for a cheaper solution (for now). There
are just too many subtleties that one would have to address early in a
devel cycle, so I'll put that on the the Forget-me-not list for 7.1.
Right.
Instead I'd suggest extending the idea of gram.y's xlateSqlType to two
functions provided by the backend
type_sql_to_internal
type_internal_to_sql
which psql and pg_dump could use. Once we switch some or all datatypes
over, this would be the only place we'd need to change -- until it's an
empty function at the end.
Sounds good to me. Unless we embed this knowledge in a table
somewhere, which perhaps we should have done originally. But then we
would have lots of overhead on queries...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Jan 24 11:07:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA44512
for <pgsql-hackers@hub.org>; Mon, 24 Jan 2000 11:07:17 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA25303;
Mon, 24 Jan 2000 11:06:56 -0500 (EST)
To: Michael Robinson <robinson@netrinsics.com>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] fatal copy in/out error (6.5.3)
In-reply-to: <200001241112.TAA20988@netrinsics.com>
References: <200001241112.TAA20988@netrinsics.com>
Comments: In-reply-to Michael Robinson <robinson@netrinsics.com>
message dated "Mon, 24 Jan 2000 19:12:46 +0800"
Date: Mon, 24 Jan 2000 11:06:55 -0500
Message-ID: <25300.948730015@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Robinson <robinson@netrinsics.com> writes:
testdb=> create table foo (word varchar(30));
CREATE
testdb=> insert into foo values ('\217\210');
INSERT 2337289 1
testdb=> copy "foo" to '/usr/local/pgsql/foo.out';
COPY
testdb=> \q
% od -c foo.out
0000000 217 210 \0 \n
0000004
Hmm. I get
0000000 217 210 \n
0000003
with either current sources or 6.5.3. I don't have MULTIBYTE nor
USE_LOCALE turned on, though. What is your configuration exactly?
This looks to me like something is deciding that \217 must be the
start of a 3-byte multibyte character... in which case, it should have
appeared that way in your database, I think.
regards, tom lane
From bouncefilter Mon Jan 24 11:31:35 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id LAA53023
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 11:31:22 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA16455;
Mon, 24 Jan 2000 11:29:20 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001241629.LAA16455@candle.pha.pa.us>
Subject: Re: [HACKERS] column aliases
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC216@sdexcsrv1.f000.d0188.sd.spardat.at>
from Zeugswetter Andreas SB at "Jan 24, 2000 12:00:08 pm"
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
Date: Mon, 24 Jan 2000 11:29:20 -0500 (EST)
CC: "'PostgreSQL-development'" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
This may go a long way towards explaining why people have been so
readily confused by the implicit-FROM-clause business!It *is* confusing, that's for sure!
IMHO, if there exists a from clause, we could insist,
that all tables are listed (no implicitly added table),
since it is really too error prone.What I would not like to see removed is the ability to
avoid the from clause alltogether. Like in:select xor.eval;
This is an interesting suggestion. I wonder if we can do this. We can
avoid producing NOTICE messages in this case.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 24 11:35:38 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA55104
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 11:35:22 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA96949;
Mon, 24 Jan 2000 12:34:52 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 24 Jan 2000 12:34:22 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Adriaan Joubert <a.joubert@albourne.com>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-Reply-To: <388C7420.D2D5A32C@albourne.com>
Message-ID: <Pine.BSF.4.21.0001241233300.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 24 Jan 2000, Adriaan Joubert wrote:
As a user let me just say that I have been waiting for all the
'ALTER TABLE..' commands for a long time (changing constraints would be great
too!) and it has been mentioned many times that one should not use oids in
application code. The way I do it at the moment is to copy the table, so I
think all users are used to losing their oids when remocing a column from a
table. So while it is certainly better to keep the oids, Peter's code is a
big improvement on the current situation.
Except, as Chris Bitmead brought up, OIDs appear to be a key requirement
in ODBMSs ... so, if we want to go what I *think* is 'next generation',
OIDs have to be kept ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Jan 24 11:45:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA56660
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 11:44:36 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA25457;
Mon, 24 Jan 2000 11:44:25 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Doc updates for index cost estimator change
In-reply-to: <388C6BC0.948A4009@alumni.caltech.edu>
References: <2071.948585763@sss.pgh.pa.us>
<388C6BC0.948A4009@alumni.caltech.edu>
Comments: In-reply-to Thomas Lockhart <lockhart@alumni.caltech.edu>
message dated "Mon, 24 Jan 2000 15:12:00 +0000"
Date: Mon, 24 Jan 2000 11:44:25 -0500
Message-ID: <25454.948732265@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
The primary graphics files should be .cgm files, but I see that we
only have those for one or two cases. The .ag files are Applix
Graphics files, which I use to embed the stuff into hardcopy.I'll see about updating them, and committing a .cgm version of each.
If the .ag files are derived files, meseems they should not be in
the CVS tree at all?
regards, tom lane
From bouncefilter Mon Jan 24 12:01:36 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id MAA61029
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 12:01:14 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA16860;
Mon, 24 Jan 2000 11:48:41 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001241648.LAA16860@candle.pha.pa.us>
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-Reply-To: <Pine.GSO.4.02A.10001241520480.10921-100000@Krokodil.DoCS.UU.SE>
from Peter Eisentraut at "Jan 24, 2000 03:51:41 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 24 Jan 2000 11:48:41 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Let me thank all of those that spoke up in my support and let me tell of
those that were unhappy that I _will_ be here tomorrow as well. To
summarize the points and add a few of my own:1) This is a TODO item.
2) I have reviewed several mutterings about how to implement this in the
archives and followed the consensus that you need to copy the table over
somehow. It's not like I made this up.
Yes, as Peter pointed out, he did exactly what I suggested in my e-mail
when he brought up the issue. I don't even remember sending the
e-mail, so it must have been some time ago, 25 Nov 1999.
2a) Does anyone have a better idea? (Btw., I'm not too excited about
by-passing the storage manager and writing around in the table file on
disk. If vacuum does that, that doesn't mean it's the right thing to do.)
I totally agree that bypassing the storage manager is the wrong way to
go with this. All the command/*.c stuff is make to be clean, not fast.
It is better to put something together that works rather than optimize
things like add user or create database.
Now, I will admit the ALTER DROP is going take much longer than most
command/*.c, so it may be worth it some day to try and do this, but I
don't see this as a priority at this point. We have many other items to
work on that are more important.
6) Users have been begging for this but nobody else has moved a finger.
Totally true.
7) If you are concerned about "perfect" implementation, then I invite you
to take a look at the create/drop user and create/drop database code from
6.5 and thank whomever you do thank that your database isn't fried yet.
Yes, that stuff is a mess, and Peter has cleaned it up quite a bit. And
I have already asked him about CLUSTER, which has serious problems.
8) Now that I know how to keep the oids around, they will be kept around.
(Thanks to those that interpreted my message as a starting point for a
discussion and not me laying down the law.)
Yes, it seems passing in the oid as part of heap_insert will do a good
job for us in a few other areas like when we want to modify the oid of a
tuple. Withouth that, we if you delete a tuple, you can't add it back
in with the same oid. That is pretty bad.
9) What really gets me though is what your problem is. This is a nearly
SQL-compliant implementation of a very important feature. It doesn't
affect the rest of the code. It doesn't break the regression tests. It
checks for permissions, validity of parameters, etc. and even if it goes
wrong, it doesn't fry your database or any part of it.
Yes, I am still totally confused. Let's hope it is just an aberation.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 24 11:50:37 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA57802
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 11:49:45 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id LAA25500;
Mon, 24 Jan 2000 11:49:20 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
"'PostgreSQL-development'" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] column aliases
In-reply-to: <200001241629.LAA16455@candle.pha.pa.us>
References: <200001241629.LAA16455@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
message dated "Mon, 24 Jan 2000 11:29:20 -0500"
Date: Mon, 24 Jan 2000 11:49:20 -0500
Message-ID: <25497.948732560@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
What I would not like to see removed is the ability to
avoid the from clause alltogether. Like in:select xor.eval;
This is an interesting suggestion. I wonder if we can do this. We can
avoid producing NOTICE messages in this case.
Sure --- only emit the notice if there is at least one RTE that *is*
marked inFromCl.
regards, tom lane
From bouncefilter Mon Jan 24 12:03:39 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id MAA62971
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 12:03:05 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA18853;
Mon, 24 Jan 2000 11:50:21 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001241650.LAA18853@candle.pha.pa.us>
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-Reply-To: <388C7420.D2D5A32C@albourne.com> from Adriaan Joubert at "Jan 24,
2000 03:47:44 pm"
To: Adriaan Joubert <a.joubert@albourne.com>
Date: Mon, 24 Jan 2000 11:50:21 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
As a user let me just say that I have been waiting for all the
'ALTER TABLE..' commands for a long time (changing constraints would be great
too!) and it has been mentioned many times that one should not use oids in
application code. The way I do it at the moment is to copy the table, so I
think all users are used to losing their oids when remocing a column from a
table. So while it is certainly better to keep the oids, Peter's code is a
big improvement on the current situation.
What happens if the dropped column is part of an index? Just curious.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 24 12:04:41 2000
Received: from hotzsun.jpl.nasa.gov (root@hotzsun.jpl.nasa.gov
[137.78.84.131])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA64366
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 12:04:13 -0500 (EST)
(envelope-from hotz@jpl.nasa.gov)
Received: from [137.78.84.130] (hotzmac [137.78.84.130])
by hotzsun.jpl.nasa.gov (8.9.3/8.9.3) with ESMTP id JAA24620;
Mon, 24 Jan 2000 09:00:46 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: hotzmail@hotzsun.jpl.nasa.gov
Message-Id: <v04020a4cb4b2354516da@[137.78.84.130]>
In-Reply-To: <25387.948414692@sss.pgh.pa.us>
Date: Mon, 24 Jan 2000 08:59:57 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
to be useful for cost estimating. We could make it a parameter like
we do for CPU_PAGE_WEIGHT ... but you know and I know that no one
ever bothers to adjust those numbers in the field ...
Appologies if this is addressed later in this thread.
Couldn't we test some of these parameters inside configure and set them there?
Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
From bouncefilter Mon Jan 24 12:05:36 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id MAA64595
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 12:05:24 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA19882;
Mon, 24 Jan 2000 12:03:06 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001241703.MAA19882@candle.pha.pa.us>
Subject: Re: [HACKERS] column aliases
In-Reply-To: <25497.948732560@sss.pgh.pa.us> from Tom Lane at "Jan 24,
2000 11:49:20 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 24 Jan 2000 12:03:06 -0500 (EST)
CC: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
"'PostgreSQL-development'" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <pgman@candle.pha.pa.us> writes:
What I would not like to see removed is the ability to
avoid the from clause alltogether. Like in:select xor.eval;
This is an interesting suggestion. I wonder if we can do this. We can
avoid producing NOTICE messages in this case.Sure --- only emit the notice if there is at least one RTE that *is*
marked inFromCl.
Seems like this would avoid most annoying messages.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 24 12:12:35 2000
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 MAA65744
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 12:11:40 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm220.noc.fukui.nsk.ne.jp [210.161.188.95])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id CAA05739; Tue, 25 Jan 2000 02:11:29 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Peter Eisentraut" <peter_e@gmx.net>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Well, then you keep your darn columns
Date: Tue, 25 Jan 2000 02:12:25 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@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 IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Pine.GSO.4.02A.10001241520480.10921-100000@Krokodil.DoCS.UU.SE>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Peter EisentrautLet me thank all of those that spoke up in my support and let me tell of
those that were unhappy that I _will_ be here tomorrow as well. To
summarize the points and add a few of my own:1) This is a TODO item.
2) I have reviewed several mutterings about how to implement this in the
archives and followed the consensus that you need to copy the table over
somehow. It's not like I made this up.2a) Does anyone have a better idea? (Btw., I'm not too excited about
by-passing the storage manager and writing around in the table file on
disk. If vacuum does that, that doesn't mean it's the right thing to do.)
I propose another implementation here. I don't think this is so
important a feature. I'm only afraid of forced implementation
especially using copy() and rename() for such a feature.
My idea is as follows.
1)add a visibile/invisible flag to pg_attribute
2)DROP COLUMN marks the column as invisible
3)user interface ignores the columns which are marked invisible
4)heap_formtuple() etc treats the column as NULL internally
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Jan 24 12:13:39 2000
Received: from netrinsics.com ([202.106.5.76])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA65936
for <pgsql-hackers@hub.org>; Mon, 24 Jan 2000 12:12:38 -0500 (EST)
(envelope-from robinson@netrinsics.com)
Received: (from robinson@localhost)
by netrinsics.com (8.9.3/8.9.3) id BAA38392;
Tue, 25 Jan 2000 01:12:28 +0800 (+0800) (envelope-from robinson)
Date: Tue, 25 Jan 2000 01:12:28 +0800 (+0800)
From: Michael Robinson <robinson@netrinsics.com>
Message-Id: <200001241712.BAA38392@netrinsics.com>
To: robinson@netrinsics.com, tgl@sss.pgh.pa.us
Subject: Re: [HACKERS] fatal copy in/out error (6.5.3)
Cc: pgsql-hackers@hub.org
In-Reply-To: <25300.948730015@sss.pgh.pa.us>
Tom Lane <tgl@sss.pgh.pa.us> writes:
Hmm. I get
0000000 217 210 \n
0000003
with either current sources or 6.5.3. I don't have MULTIBYTE nor
USE_LOCALE turned on, though. What is your configuration exactly?
My config line:
./configure --with-mb=EUC_CN
I can forward my include/config.h if that would be helpful.
The OS is FreeBSD 3.4-RELEASE.
This looks to me like something is deciding that \217 must be the
start of a 3-byte multibyte character... in which case, it should have
appeared that way in your database, I think.
That would be very weird, if true. \217 is certainly not the beginning of
a UTF-8 three-byte sequence, and EUC doesn't have three-byte codes.
-Michael Robinson
From bouncefilter Mon Jan 24 12:19:35 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id MAA67485
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 12:19:07 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA20659;
Mon, 24 Jan 2000 12:17:51 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001241717.MAA20659@candle.pha.pa.us>
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
In-Reply-To: <v04020a4cb4b2354516da@[137.78.84.130]> from "Henry B. Hotz" at
"Jan 24, 2000 08:59:57 am"
To: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Date: Mon, 24 Jan 2000 12:17:51 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
to be useful for cost estimating. We could make it a parameter like
we do for CPU_PAGE_WEIGHT ... but you know and I know that no one
ever bothers to adjust those numbers in the field ...Appologies if this is addressed later in this thread.
Couldn't we test some of these parameters inside configure and set them there?
That would be cool.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 24 12:26:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA69403
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 12:25:55 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA25686;
Mon, 24 Jan 2000 12:25:29 -0500 (EST)
To: "Henry B. Hotz" <hotz@jpl.nasa.gov>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
In-reply-to: <v04020a4cb4b2354516da@[137.78.84.130]>
References: <v04020a4cb4b2354516da@[137.78.84.130]>
Comments: In-reply-to "Henry B. Hotz" <hotz@jpl.nasa.gov>
message dated "Mon, 24 Jan 2000 08:59:57 -0800"
Date: Mon, 24 Jan 2000 12:25:29 -0500
Message-ID: <25683.948734729@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
to be useful for cost estimating. We could make it a parameter like
we do for CPU_PAGE_WEIGHT ... but you know and I know that no one
ever bothers to adjust those numbers in the field ...
Couldn't we test some of these parameters inside configure and set
them there?
If we could figure out a reasonably cheap way of estimating these
numbers, it'd be worth setting up custom values at installation time.
I don't know how to do that --- AFAICS, getting trustworthy numbers by
measurement would require hundreds of meg of temporary disk space and
probably hours of runtime. (A smaller test would be completely
corrupted by kernel disk caching effects.)
But perhaps someone has an idea how to do it.
regards, tom lane
From bouncefilter Mon Jan 24 12:30:37 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA70553
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 12:30:18 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA25726;
Mon, 24 Jan 2000 12:29:43 -0500 (EST)
To: prlw1@cam.ac.uk
cc: Alfred Perlstein <bright@wintelcom.net>,
Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: pg_dump possible fix, need testers.
In-reply-to: <20000124123000.C21345@quartz.newn.cam.ac.uk>
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
<20000124123000.C21345@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Mon, 24 Jan 2000 12:30:00 +0000"
Date: Mon, 24 Jan 2000 12:29:43 -0500
Message-ID: <25723.948734983@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
Things are still not so good for me. The pg_dumpall > file, psql < file did
work, but later:
newnham=> select * from crsids,"tblPerson" where
newnham-> crsids.crsid != "tblPerson"."CRSID";
Backend sent B message without prior T
D21Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
which smells like a similar problem. (Note that this is a join. Straight
selects didn't cause problems)
Bizarre. Obviously, the frontend and backend have gotten out of sync,
but it's not too clear who's to blame. Since you also mention
(New also, though probably unrelated: the sanity check fails with number of
index tuples exactly half number in heap - not equal)
I think that you may have some subtle platform-specific problems in the
backend.
What exactly is your platform/compiler/configuration, anyway?
regards, tom lane
From bouncefilter Mon Jan 24 12:35:35 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id MAA74097
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 12:34:28 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA21868;
Mon, 24 Jan 2000 12:33:34 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001241733.MAA21868@candle.pha.pa.us>
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-Reply-To: <NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp> from Hiroshi Inoue
at "Jan 25, 2000 02:12:25 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 24 Jan 2000 12:33:34 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
My idea is as follows.
1)add a visibile/invisible flag to pg_attribute
2)DROP COLUMN marks the column as invisible
3)user interface ignores the columns which are marked invisible
4)heap_formtuple() etc treats the column as NULL internally
Yes, but how much code is that going to hit? Seems it would be a lot.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 24 12:36:39 2000
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net
[194.217.242.90]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA75077;
Mon, 24 Jan 2000 12:36:17 -0500 (EST)
(envelope-from peter@retep.org.uk)
Received: from maidast.demon.co.uk ([158.152.22.37] helo=maidast.retep.org.uk)
by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1)
id 12CnPS-0005X7-0W; Mon, 24 Jan 2000 17:36:15 +0000
Received: from localhost (peter@localhost [127.0.0.1])
by maidast.retep.org.uk (8.9.3/8.9.3) with ESMTP id RAA05150;
Mon, 24 Jan 2000 17:33:58 GMT
Date: Mon, 24 Jan 2000 17:33:58 +0000 (GMT)
From: Peter Mount <peter@retep.org.uk>
To: "PostgreSQL Interfaces (E-mail)" <pgsql-hackers@postgresql.org>
cc: "PostgreSQL Developers List (E-mail)" <hackers@postgresql.org>
Subject: Re: [HACKERS] Proposed change to the JDBC driver
In-Reply-To:
<1B3D5E532D18D311861A00600865478C70C0EA@exchange1.nt.maidstone.gov.uk>
Message-ID: <Pine.LNX.4.10.10001241731400.4761-100000@maidast.retep.org.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
As I haven't seen any replies to this, can I assume no body objects to me
making this fairly major change to the driver?
I need to know sometime in the next few hours, as I'm about to fit the
pieces together.
Peter
On Wed, 19 Jan 2000, Peter Mount wrote:
I'm sending this to both the hackers and interfaces lists as this
affects the 7.0 release and an interface.Ok, up until now the driver has operated under a base package of
postgresql. This has worked fine so far but technically breaks Sun's
rules on package naming. The rule is that any organisations package
names begins with their domain name. This prevents two different package
names from clashing.Ie: My own classes always begin with uk.org.retep as my own domain is
retep.org.uk. The classes I write here begin with uk.gov.maidstone.Now, what I'm thinking is that as the 7.0 driver isn't going to be
compatible with earlier backends (mainly due to the core changes like
date/time handling, but there are others), I'm proposing to change our
base package name from postgresql to org.postgresql so that we comply
with this rule (which has been around since Java first came out).All this involves in the source is to create an empty directory called
org, and move the original postgresql directory into it. Then each .java
file will need org. prefixed to the package name.The down side, is that any existing source that uses the driver will
need amending so that either the Class.forName() line reads:Class.forName("org.postgresql");
or if it's supplied as a parameter (which is my prefered way) the org.
added.Now because of this downside, I want to see what everyone thinks about
making this change before I do it, as I have a lot of things to do to
the source to implement it, but it would be better to do it now,
especially as it's the first new major release since JDBC was included.Peter
--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.************
--
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 Jan 24 12:34:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA74096
for <pgsql-hackers@hub.org>; Mon, 24 Jan 2000 12:34:28 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA25769;
Mon, 24 Jan 2000 12:34:20 -0500 (EST)
To: Michael Robinson <robinson@netrinsics.com>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] fatal copy in/out error (6.5.3)
In-reply-to: <200001241712.BAA38392@netrinsics.com>
References: <200001241712.BAA38392@netrinsics.com>
Comments: In-reply-to Michael Robinson <robinson@netrinsics.com>
message dated "Tue, 25 Jan 2000 01:12:28 +0800"
Date: Mon, 24 Jan 2000 12:34:19 -0500
Message-ID: <25765.948735259@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
This looks to me like something is deciding that \217 must be the
start of a 3-byte multibyte character... in which case, it should have
appeared that way in your database, I think.
That would be very weird, if true. \217 is certainly not the beginning of
a UTF-8 three-byte sequence, and EUC doesn't have three-byte codes.
Hmm. And I don't suppose it's real likely that \217 is a one-byte code
and \210 starts a two-byte code?
I'm out of my depth here --- it seems this is almost certainly a
MULTIBYTE issue, but I know very little about MULTIBYTE. I'm going
to punt and hope some of our MULTIBYTE experts pick it up.
regards, tom lane
From bouncefilter Mon Jan 24 12:48:35 2000
Received: from hotzsun.jpl.nasa.gov (root@hotzsun.jpl.nasa.gov
[137.78.84.131])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA78076
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 12:48:27 -0500 (EST)
(envelope-from hotz@jpl.nasa.gov)
Received: from [137.78.84.130] (hotzmac [137.78.84.130])
by hotzsun.jpl.nasa.gov (8.9.3/8.9.3) with ESMTP id JAA24741;
Mon, 24 Jan 2000 09:47:29 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: hotzmail@hotzsun.jpl.nasa.gov
Message-Id: <v04020a4eb4b23e7c41dd@[137.78.84.130]>
In-Reply-To: <25683.948734729@sss.pgh.pa.us>
References: <v04020a4cb4b2354516da@[137.78.84.130]>
<v04020a4cb4b2354516da@[137.78.84.130]>
Date: Mon, 24 Jan 2000 09:46:40 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
Cc: pgsql-hackers@postgreSQL.org
At 9:25 AM -0800 1/24/00, Tom Lane wrote:
"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
to be useful for cost estimating. We could make it a parameter like
we do for CPU_PAGE_WEIGHT ... but you know and I know that no one
ever bothers to adjust those numbers in the field ...Couldn't we test some of these parameters inside configure and set
them there?If we could figure out a reasonably cheap way of estimating these
numbers, it'd be worth setting up custom values at installation time.I don't know how to do that --- AFAICS, getting trustworthy numbers by
measurement would require hundreds of meg of temporary disk space and
probably hours of runtime. (A smaller test would be completely
corrupted by kernel disk caching effects.)
Getting a rough estimate of CPU speed is trivial. Getting a rough estimate
of sequential disk access shouldn't be too hard, though you would need to
make sure it didn't give the wrong answer if you ran configure twice in a
row or something. Getting a rough estimate of disk access for a single
non-sequential disk page also shouldn't be too hard with the same caviats.
Measuring sequential vs. random reads probably takes a large dataset as you
say.
I suspect that there is a range of important parameters and we can only
easily measure some of them. If we do so and use canned values (ratios,
where possible) for the others then we're probably still ahead.
I'll leave the details for the people who actually have time to do some of
this stuff.
Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
From bouncefilter Mon Jan 24 12:54:35 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA79314
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 12:54:05 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id MAA25855;
Mon, 24 Jan 2000 12:53:50 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Peter Eisentraut" <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-reply-to: <NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp>
References: <NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Tue, 25 Jan 2000 02:12:25 +0900"
Date: Mon, 24 Jan 2000 12:53:49 -0500
Message-ID: <25852.948736429@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
My idea is as follows.
1)add a visibile/invisible flag to pg_attribute
2)DROP COLUMN marks the column as invisible
3)user interface ignores the columns which are marked invisible
4)heap_formtuple() etc treats the column as NULL internally
That could be a really good idea. I don't think you'd even need to
touch heap_formtuple (and it'd be better not to mess with the guts
of the system to implement this feature, for both speed and reliability
reasons).
Let's see: DROP COLUMN would have to mark the column invisible, remove
any associated constraints (particularly NOT NULL) and indexes, and
it'd be done. The parser would then have to ignore the column when
doing column name lookups or expansion of '*', and it would have to
insert a NULL value for the column when transforming INSERT or UPDATE.
And that'd be just about it. I like it.
The only drawback of this scheme is that the space occupied by the
deleted column wouldn't go away immediately (in any given tuple,
it'd be reclaimed on the next UPDATE of the tuple). On the other hand,
you could construe that as a feature --- you don't have to wait around
for a DROP COLUMN to finish. Anyone who did want to reclaim space
immediately could do
UPDATE table SET someothercolumn = someothercolumn;
followed by a VACUUM. But I bet a lot of people would be just as
happy to let it happen in background.
regards, tom lane
From bouncefilter Mon Jan 24 12:58:35 2000
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA80209
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 12:58:11 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id SAA178558;
Mon, 24 Jan 2000 18:58:06 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <CCAL3MY8>; Mon, 24 Jan 2000 18:58:05 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC21C@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>
Cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Some notes on optimizer cost estimates
Date: Mon, 24 Jan 2000 18:58:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Couldn't we test some of these parameters inside configure and set
them there?If we could figure out a reasonably cheap way of estimating these
numbers, it'd be worth setting up custom values at installation time.
Imho this whole idea is not so good. (Sorry)
My points are:
1. even if it is good for an optimizer to be smart,
it is even more important, that it is predictable
2. I compile on test machine, production is completely different
(more processors, faster disks and controllers)
Andreas
From bouncefilter Mon Jan 24 12:59:36 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA80423
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 12:59:25 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12Cnm0-0007Th-00; Mon, 24 Jan 2000 17:59:32 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12Cnlp-0007Xo-00; Mon, 24 Jan 2000 17:59:21 +0000
Date: Mon, 24 Jan 2000 17:59:21 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alfred Perlstein <bright@wintelcom.net>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: pg_dump possible fix, need testers.
Message-ID: <20000124175921.F21345@quartz.newn.cam.ac.uk>
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
<20000124123000.C21345@quartz.newn.cam.ac.uk>
<25723.948734983@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <25723.948734983@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Mon, Jan 24, 2000 at 12:29:43PM -0500
On Mon, Jan 24, 2000 at 12:29:43PM -0500, Tom Lane wrote:
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
Things are still not so good for me. The pg_dumpall > file, psql < file did
work, but later:newnham=> select * from crsids,"tblPerson" where
newnham-> crsids.crsid != "tblPerson"."CRSID";
Backend sent B message without prior T
D21Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.which smells like a similar problem. (Note that this is a join. Straight
selects didn't cause problems)Bizarre. Obviously, the frontend and backend have gotten out of sync,
but it's not too clear who's to blame. Since you also mention(New also, though probably unrelated: the sanity check fails with number of
index tuples exactly half number in heap - not equal)I think that you may have some subtle platform-specific problems in the
backend.What exactly is your platform/compiler/configuration, anyway?
NetBSD-1.4P/i386 / egcs-2.91.66 19990314 (egcs-1.1.2 release)
configure --enable-debug
This morning I cvs'd made, installed, moved data->data2, initdb, started
up postmaster, reloaded data (this worked!), then tried the join. It's a
big one, so I thought I might as well stress it at the same time, and did
a regression test.
Anything I could try to narrow the problem down?
Cheers,
Patrick
From bouncefilter Mon Jan 24 13:07:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA85663
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 13:06:41 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA25951;
Mon, 24 Jan 2000 13:06:23 -0500 (EST)
To: Peter Mount <peter@retep.org.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Proposed change to the JDBC driver
In-reply-to: <Pine.LNX.4.10.10001241731400.4761-100000@maidast.retep.org.uk>
References: <Pine.LNX.4.10.10001241731400.4761-100000@maidast.retep.org.uk>
Comments: In-reply-to Peter Mount <peter@retep.org.uk>
message dated "Mon, 24 Jan 2000 17:33:58 +0000"
Date: Mon, 24 Jan 2000 13:06:23 -0500
Message-ID: <25948.948737183@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Mount <peter@retep.org.uk> writes:
As I haven't seen any replies to this, can I assume no body objects to me
making this fairly major change to the driver?
AFAICS, it's not "major" in the sense of a functionality change, it's
just that each calling app will need to replace "postgresql" with
"org.postgresql"?
If you're gonna do it, 7.0 seems like the right time to do it.
regards, tom lane
From bouncefilter Mon Jan 24 13:11:36 2000
Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA86752
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 13:11:11 -0500 (EST) (envelope-from geek+@cmu.edu)
Received: from export.andrew.cmu.edu (EXPORT.ANDREW.CMU.EDU [128.2.23.2])
by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id NAA04071
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 13:11:09 -0500 (EST)
Date: 24 Jan 2000 13:11:10 -0500
Message-ID: <emacs-smtp-439-14476-38334-94463@export.andrew.cmu.edu>
From: Brian E Gallew <geek+@cmu.edu>
X-Mailer: BatIMail version 3.2
To: pgsql-hackers@postgreSQL.org
In-reply-to: <v04020a4eb4b23e7c41dd@[137.78.84.130]>
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
References: <v04020a4cb4b2354516da@[137.78.84.130]>
<v04020a4cb4b2354516da@[137.78.84.130]>
<v04020a4eb4b23e7c41dd@[137.78.84.130]>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/signed; protocol="application/pgp-signature";
boundary="pgp-sign-Multipart_Mon_Jan_24_13:11:09_2000-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
--pgp-sign-Multipart_Mon_Jan_24_13:11:09_2000-1
Content-Type: text/plain; charset=US-ASCII
Then <hotz@jpl.nasa.gov> spoke up and said:
I don't know how to do that --- AFAICS, getting trustworthy numbers by
measurement would require hundreds of meg of temporary disk space and
probably hours of runtime. (A smaller test would be completely
corrupted by kernel disk caching effects.)Getting a rough estimate of CPU speed is trivial. Getting a rough estimate
of sequential disk access shouldn't be too hard, though you would need to
make sure it didn't give the wrong answer if you ran configure twice in a
row or something. Getting a rough estimate of disk access for a single
non-sequential disk page also shouldn't be too hard with the same caviats.
Measuring sequential vs. random reads probably takes a large dataset as you
say.
A point for consideration: this need not be a configure test. Any
commercial database usage carries with it the expectation of a
non-trivial effort at tuning. This being the case, it might make
sense to bring in some foresight here. As PostgreSQL matures, people
are going to be using it on non-homogeneous systems (e.g mixture of
3600, 7200, and 10k rpm disks). Our cost estimates should therefore
vary somewhat as tables start living on different disks (yet another
reason why symlinks are not the answer).
Right now, I would kill to have a tool that I could run over a couple
hours and many gigabytes of disk space that would give me indications
of how to tune my Oracle database. We may want to think about, in the
future, adding in the ability to tune specific tables by keeping query
statistics and analyzing them. Even post-processing debug output
would help, although turning debugging on adds some non-trivial
overhead.
--
=====================================================================
| JAVA must have been developed in the wilds of West Virginia. |
| After all, why else would it support only single inheritance?? |
=====================================================================
| Finger geek@cmu.edu for my public key. |
=====================================================================
--pgp-sign-Multipart_Mon_Jan_24_13:11:09_2000-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface
iQBVAwUBOIyVvYdzVnzma+gdAQGsUwH+LA5rqAvL3rF8VeLZAKsXAO6yStOHiLgu
wqFolK/jeRTF08poyg9a+jFAB48wEVukeF90A3zhVUw6CofnF8ZcEA==
=B8FW
-----END PGP MESSAGE-----
--pgp-sign-Multipart_Mon_Jan_24_13:11:09_2000-1--
From bouncefilter Mon Jan 24 13:14:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA87428
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 13:13:51 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA26000;
Mon, 24 Jan 2000 13:13:46 -0500 (EST)
To: "Henry B. Hotz" <hotz@jpl.nasa.gov>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
In-reply-to: <v04020a4eb4b23e7c41dd@[137.78.84.130]>
References: <v04020a4cb4b2354516da@[137.78.84.130]>
<v04020a4cb4b2354516da@[137.78.84.130]>
<v04020a4eb4b23e7c41dd@[137.78.84.130]>
Comments: In-reply-to "Henry B. Hotz" <hotz@jpl.nasa.gov>
message dated "Mon, 24 Jan 2000 09:46:40 -0800"
Date: Mon, 24 Jan 2000 13:13:45 -0500
Message-ID: <25997.948737625@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
I don't know how to do that --- AFAICS, getting trustworthy numbers by
measurement would require hundreds of meg of temporary disk space and
probably hours of runtime. (A smaller test would be completely
corrupted by kernel disk caching effects.)
Getting a rough estimate of CPU speed is trivial. Getting a rough estimate
of sequential disk access shouldn't be too hard, though you would need to
make sure it didn't give the wrong answer if you ran configure twice in a
row or something. Getting a rough estimate of disk access for a single
non-sequential disk page also shouldn't be too hard with the same caviats.
In practice this would be happening at initdb time, not configure time,
since it'd be a lot easier to do it in C code than in a shell script.
But that's a detail. I'm still not clear on how you can wave away the
issue of kernel disk caching --- if you don't use a test file that's
larger than the disk cache, ISTM you risk getting a number that's
entirely devoid of any physical I/O at all.
regards, tom lane
From bouncefilter Mon Jan 24 13:12:36 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA87049
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 13:12:32 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.243]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 24 Jan 2000 12:02:55 -0600
Sender: ed
Message-ID: <388C9664.1D975D2D@austin.rr.com>
Date: Mon, 24 Jan 2000 12:13:56 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
References: <NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp>
<25852.948736429@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Let's see: DROP COLUMN would have to mark the column invisible, remove
any associated constraints (particularly NOT NULL) and indexes, and
it'd be done. The parser would then have to ignore the column when
doing column name lookups or expansion of '*', and it would have to
insert a NULL value for the column when transforming INSERT or UPDATE.
And that'd be just about it. I like it.
How would you handle multi-column indices that included the column
being dropped? E.g.,
create unique index foobar on mytable(foo,bar);
where the 'bar' column is then dropped...
Dropping all of that index would seem to be problematic.
Cheers,
Ed Loehr
From bouncefilter Mon Jan 24 13:18:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA88347
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 13:18:19 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA26020;
Mon, 24 Jan 2000 13:17:57 -0500 (EST)
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgresql.org>
Subject: Re: AW: [HACKERS] Some notes on optimizer cost estimates
In-reply-to:
<219F68D65015D011A8E000006F8590C603FDC21C@sdexcsrv1.f000.d0188.sd.spardat.at>
References:
<219F68D65015D011A8E000006F8590C603FDC21C@sdexcsrv1.f000.d0188.sd.spardat.at>
Comments: In-reply-to Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
message dated "Mon, 24 Jan 2000 18:58:02 +0100"
Date: Mon, 24 Jan 2000 13:17:57 -0500
Message-ID: <26017.948737877@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
My points are:
1. even if it is good for an optimizer to be smart,
it is even more important, that it is predictable
A good point indeed. And unless we find that there is a huge range in
the ratios across different machines, we'd be wasting our time trying to
calibrate the numbers for a particular machine --- we could just as well
use an average value. The optimizer has many other, far worse, sources
of error than that.
2. I compile on test machine, production is completely different
(more processors, faster disks and controllers)
In practice we'd do this at initdb time, not configure time, so I'm
not sure that that's really an issue. But your other point is
well taken.
regards, tom lane
From bouncefilter Mon Jan 24 13:21:36 2000
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 NAA88708
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 13:20:44 -0500 (EST)
(envelope-from peter@retep.org.uk)
Received: from maidast.demon.co.uk ([158.152.22.37] helo=maidast.retep.org.uk)
by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
id 12Co6R-000N5T-0A; Mon, 24 Jan 2000 18:20:40 +0000
Received: from localhost (peter@localhost [127.0.0.1])
by maidast.retep.org.uk (8.9.3/8.9.3) with ESMTP id SAA05320;
Mon, 24 Jan 2000 18:18:25 GMT
Date: Mon, 24 Jan 2000 18:18:24 +0000 (GMT)
From: Peter Mount <peter@retep.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Proposed change to the JDBC driver
In-Reply-To: <25948.948737183@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.10.10001241816480.4761-100000@maidast.retep.org.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 24 Jan 2000, Tom Lane wrote:
Peter Mount <peter@retep.org.uk> writes:
As I haven't seen any replies to this, can I assume no body objects to me
making this fairly major change to the driver?AFAICS, it's not "major" in the sense of a functionality change, it's
just that each calling app will need to replace "postgresql" with
"org.postgresql"?
Correct.
If you're gonna do it, 7.0 seems like the right time to do it.
That's exactly why I wanted to do it now.
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 Jan 24 13:20:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA88644
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 13:20:11 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA26044;
Mon, 24 Jan 2000 13:20:05 -0500 (EST)
To: Patrick Welche <prlw1@newn.cam.ac.uk>
cc: Alfred Perlstein <bright@wintelcom.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: pg_dump possible fix, need testers.
In-reply-to: <20000124175921.F21345@quartz.newn.cam.ac.uk>
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
<20000124123000.C21345@quartz.newn.cam.ac.uk>
<25723.948734983@sss.pgh.pa.us>
<20000124175921.F21345@quartz.newn.cam.ac.uk>
Comments: In-reply-to Patrick Welche <prlw1@newn.cam.ac.uk>
message dated "Mon, 24 Jan 2000 17:59:21 +0000"
Date: Mon, 24 Jan 2000 13:20:04 -0500
Message-ID: <26041.948738004@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
This morning I cvs'd made, installed, moved data->data2, initdb, started
up postmaster, reloaded data (this worked!), then tried the join. It's a
big one, so I thought I might as well stress it at the same time, and did
a regression test.
Anything I could try to narrow the problem down?
Hmm. Why don't you try running the parallel regression test, to see
if that blows up too?
regards, tom lane
From bouncefilter Mon Jan 24 13:31:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA91727
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 13:31:03 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA26083;
Mon, 24 Jan 2000 13:30:22 -0500 (EST)
To: Ed Loehr <eloehr@austin.rr.com>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-reply-to: <388C9664.1D975D2D@austin.rr.com>
References: <NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp>
<25852.948736429@sss.pgh.pa.us> <388C9664.1D975D2D@austin.rr.com>
Comments: In-reply-to Ed Loehr <eloehr@austin.rr.com>
message dated "Mon, 24 Jan 2000 12:13:56 -0600"
Date: Mon, 24 Jan 2000 13:30:21 -0500
Message-ID: <26080.948738621@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Ed Loehr <eloehr@austin.rr.com> writes:
How would you handle multi-column indices that included the column
being dropped? E.g.,
create unique index foobar on mytable(foo,bar);
where the 'bar' column is then dropped...
Good question, but I don't think we had an answer for it in the other
scheme either.
In Hiroshi's scheme it seems like it might "just work" anyway: the index
would still be there, it'd just start filling with all nulls in the bar
column. AFAIR, a unique index won't complain about that under SQL92
rules.
On the whole it might be better to refuse to do the DROP COLUMN until
the user gets rid of such an index. It would certainly be wrong for
us to try to replace the index with
create unique index foobar on mytable(foo);
since the original index did *not* imply uniqueness on foo alone.
Similarly, I'd be very strongly inclined to punt if we find any
constraints that mention both the target column and other columns.
We cannot fix those automatically, and silently dropping them doesn't
sound good either. Make the user do something with them, instead.
regards, tom lane
From bouncefilter Mon Jan 24 13:46:36 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA96872
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 13:46:04 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA26166;
Mon, 24 Jan 2000 13:45:44 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>, "Peter Eisentraut" <peter_e@gmx.net>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-reply-to: <25852.948736429@sss.pgh.pa.us>
References: <NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp>
<25852.948736429@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
message dated "Mon, 24 Jan 2000 12:53:49 -0500"
Date: Mon, 24 Jan 2000 13:45:43 -0500
Message-ID: <26163.948739543@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Let's see: DROP COLUMN would have to mark the column invisible, remove
any associated constraints (particularly NOT NULL) and indexes, and
it'd be done. The parser would then have to ignore the column when
doing column name lookups or expansion of '*', and it would have to
insert a NULL value for the column when transforming INSERT or UPDATE.
And that'd be just about it. I like it.
On further reflection I can think of a few other places that would have
to be taught to skip over "invisible" columns: COPY and pg_dump would,
and probably there are some others. But it still seems like this is
a simple and robust scheme with considerable advantages, and many
fewer "I'm not sure how to do that" gaps in it.
regards, tom lane
From bouncefilter Mon Jan 24 14:15:37 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA04752
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 14:14:52 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA25003;
Mon, 24 Jan 2000 11:14:15 -0800 (PST)
Message-Id: <3.0.1.32.20000124105605.01067ec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jan 2000 10:56:05 -0800
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
"'PostgreSQL-development'" <pgsql-hackers@postgreSQL.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] column aliases
In-Reply-To: <219F68D65015D011A8E000006F8590C603FDC216@sdexcsrv1.f000.d0
188.sd.spardat.at>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:00 PM 1/24/00 +0100, Zeugswetter Andreas SB wrote:
IMHO, if there exists a from clause, we could insist,
that all tables are listed (no implicitly added table),
since it is really too error prone.What I would not like to see removed is the ability to
avoid the from clause alltogether. Like in:select xor.eval;
Yeah...in porting the arsDigita Community System over from
Oracle, we created a dummy table called "dual" because of
the clunky Oracle-ism involving that table.
In other words, in Oracle you can't say:
select sydate();
because you must have a "from" clause. By convention you
use a dummy built-in table called "dual" which has one row:
select sysdate() from dual;
Ugh. I agree that being able to exclude the from clause
altogether is nice.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 14:15:36 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA04751
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 14:14:52 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id LAA25036;
Mon, 24 Jan 2000 11:14:18 -0800 (PST)
Message-Id: <3.0.1.32.20000124110953.01065910@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jan 2000 11:09:53 -0800
To: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-Reply-To: <Pine.GSO.4.02A.10001241520480.10921-100000@Krokodil.DoCS.U U.SE>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 03:51 PM 1/24/00 +0100, Peter Eisentraut wrote:
9) What really gets me though is what your problem is. This is a nearly
SQL-compliant implementation of a very important feature.
Really? Dropping constraints fits the definition of "nearly compliant"?
Not sure I'd agree with that. It makes it fairly useless for a very wide
range
of users coming from a commercial db environment, because such users tend
to use referential integrity very heavily.
Regarding the rest of your note, I should hope that what's clear is that
folks don't really have a beef with your stepping up to the plate to
implement an important feature, but rather the fait-accompli approach
you took rather than raising the issue for discussion beforehand.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 15:01:37 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA18939
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:01:23 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA11824;
Mon, 24 Jan 2000 12:00:47 -0800 (PST)
Message-Id: <3.0.1.32.20000124111857.0106a2a0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jan 2000 11:18:57 -0800
To: Bruce Momjian <pgman@candle.pha.pa.us>, Peter Eisentraut <peter_e@gmx.net>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Well, then you keep your darn columns
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <200001241648.LAA16860@candle.pha.pa.us>
References: <Pine.GSO.4.02A.10001241520480.10921-100000@Krokodil.DoCS.UU.SE>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:48 AM 1/24/00 -0500, Bruce Momjian wrote:
2a) Does anyone have a better idea? (Btw., I'm not too excited about
by-passing the storage manager and writing around in the table file on
disk. If vacuum does that, that doesn't mean it's the right thing to do.)
I totally agree that bypassing the storage manager is the wrong way to
go with this. All the command/*.c stuff is make to be clean, not fast.
It is better to put something together that works rather than optimize
things like add user or create database.
Now, I will admit the ALTER DROP is going take much longer than most
command/*.c, so it may be worth it some day to try and do this, but I
don't see this as a priority at this point. We have many other items to
work on that are more important.
Also, by-passing the storage manager would make it more difficult to
replace it with another, for instance a storage manager based on raw
disk I/O, which some folks seem interested in. Though I don't count
myself in that class, it seems like the storage manager abstraction
has been preserved in order to simplify alternative approaches if
folks want to add them in the future, and it seems wrong to by-pass
that layer of abstraction.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 14:26:37 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id OAA07063
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 14:26:17 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA07676;
Mon, 24 Jan 2000 14:25:34 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001241925.OAA07676@candle.pha.pa.us>
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-Reply-To: <3.0.1.32.20000124110953.01065910@mail.pacifier.com> from Don
Baccus at "Jan 24, 2000 11:09:53 am"
To: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 24 Jan 2000 14:25:34 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
At 03:51 PM 1/24/00 +0100, Peter Eisentraut wrote:
9) What really gets me though is what your problem is. This is a nearly
SQL-compliant implementation of a very important feature.Really? Dropping constraints fits the definition of "nearly compliant"?
Not sure I'd agree with that. It makes it fairly useless for a very wide
range
of users coming from a commercial db environment, because such users tend
to use referential integrity very heavily.Regarding the rest of your note, I should hope that what's clear is that
folks don't really have a beef with your stepping up to the plate to
implement an important feature, but rather the fait-accompli approach
you took rather than raising the issue for discussion beforehand.
Maybe I am to blame for this. He asked on the list in November, and I
told him to do it the way he did it. I did not mention anything about
oids or constraints, and suggested a "something is better than nothing"
approach to the problem.
Seems most people do not agree with that suggestion I made.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 24 14:30:37 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id OAA08230
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 14:30:21 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA07794;
Mon, 24 Jan 2000 14:29:29 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001241929.OAA07794@candle.pha.pa.us>
Subject: Re: [HACKERS] column aliases
In-Reply-To: <3.0.1.32.20000124105605.01067ec0@mail.pacifier.com> from Don
Baccus at "Jan 24, 2000 10:56:05 am"
To: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 24 Jan 2000 14:29:29 -0500 (EST)
CC: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
"'PostgreSQL-development'" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
At 12:00 PM 1/24/00 +0100, Zeugswetter Andreas SB wrote:
IMHO, if there exists a from clause, we could insist,
that all tables are listed (no implicitly added table),
since it is really too error prone.What I would not like to see removed is the ability to
avoid the from clause alltogether. Like in:select xor.eval;
Yeah...in porting the arsDigita Community System over from
Oracle, we created a dummy table called "dual" because of
the clunky Oracle-ism involving that table.In other words, in Oracle you can't say:
select sydate();
because you must have a "from" clause. By convention you
use a dummy built-in table called "dual" which has one row:select sysdate() from dual;
Ugh. I agree that being able to exclude the from clause
altogether is nice.
Yes, with INFORMIX, we use 'tab1' as a one-row table.
The cool part is SELECT pg_class.* is the same as SELECT * FROM
pg_class.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 24 15:02:38 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA19469
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:01:48 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA11843;
Mon, 24 Jan 2000 12:00:49 -0800 (PST)
Message-Id: <3.0.1.32.20000124113537.010734c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jan 2000 11:35:37 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, "Hiroshi Inoue" <Inoue@tpf.co.jp>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Well, then you keep your darn columns
Cc: "Peter Eisentraut" <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
In-Reply-To: <25852.948736429@sss.pgh.pa.us>
References: <NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp>
<NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:53 PM 1/24/00 -0500, Tom Lane wrote:
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
My idea is as follows.
1)add a visibile/invisible flag to pg_attribute
2)DROP COLUMN marks the column as invisible
3)user interface ignores the columns which are marked invisible
4)heap_formtuple() etc treats the column as NULL internallyThat could be a really good idea.
I'd been thinking along these lines as a possibility, too, but
didn't want to rock the boat any more than I've done already. Now
that it's on the table, though...
Let's see: DROP COLUMN would have to mark the column invisible, remove
any associated constraints (particularly NOT NULL) and indexes, and
it'd be done. The parser would then have to ignore the column when
doing column name lookups or expansion of '*', and it would have to
insert a NULL value for the column when transforming INSERT or UPDATE.
And that'd be just about it. I like it.
Yep.
The only drawback of this scheme is that the space occupied by the
deleted column wouldn't go away immediately (in any given tuple,
it'd be reclaimed on the next UPDATE of the tuple). On the other hand,
you could construe that as a feature --- you don't have to wait around
for a DROP COLUMN to finish. Anyone who did want to reclaim space
immediately could do
UPDATE table SET someothercolumn = someothercolumn;
followed by a VACUUM.
Or perhaps vacuum could be made smart enough to remove deleted columns?
Perhaps optionally?
But I bet a lot of people would be just as happy to let it happen
in background.
Well...one reason why this idea arose in my mind is because I'm actually
doing it for a web-based table definer that's part of the (tiresomely
overmentioned) arsDigita Community System. It lets you add and drop
columns via the web (you're actually defining auxillary tables used
by some canned code so it's not quite as weird as it may sound). I
simply enforce that user-defined table names begin with a character,
and when a user "drops" a column rename it to an "illegal" name in
a special form, which the rest of the web interface simply doesn't
display. The user can't tell that the columns not really dropped,
maintaining the illusion that the system's 100% compatible with the
Oracle-based version.
It works just great for this application, though it's a royal kludge.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 14:46:37 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA14043
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 14:45:58 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA99082;
Mon, 24 Jan 2000 15:44:20 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 24 Jan 2000 15:44:20 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-Reply-To: <25852.948736429@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.0001241543210.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 24 Jan 2000, Tom Lane wrote:
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
My idea is as follows.
1)add a visibile/invisible flag to pg_attribute
2)DROP COLUMN marks the column as invisible
3)user interface ignores the columns which are marked invisible
4)heap_formtuple() etc treats the column as NULL internallyThat could be a really good idea. I don't think you'd even need to
touch heap_formtuple (and it'd be better not to mess with the guts
of the system to implement this feature, for both speed and reliability
reasons).Let's see: DROP COLUMN would have to mark the column invisible, remove
any associated constraints (particularly NOT NULL) and indexes, and
it'd be done. The parser would then have to ignore the column when
doing column name lookups or expansion of '*', and it would have to
insert a NULL value for the column when transforming INSERT or UPDATE.
And that'd be just about it. I like it.The only drawback of this scheme is that the space occupied by the
deleted column wouldn't go away immediately (in any given tuple,
it'd be reclaimed on the next UPDATE of the tuple). On the other hand,
you could construe that as a feature --- you don't have to wait around
for a DROP COLUMN to finish. Anyone who did want to reclaim space
immediately could do
UPDATE table SET someothercolumn = someothercolumn;
followed by a VACUUM. But I bet a lot of people would be just as
happy to let it happen in background.
Hey Bruce ... Look here ^^^^ :)
Oh, there is a second drawback to it though ...
DROP COLUMN name
ADD COLUMN name <of a different type>
Then what? :(
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Jan 24 15:02:37 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA19562
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:01:52 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA11873;
Mon, 24 Jan 2000 12:00:51 -0800 (PST)
Message-Id: <3.0.1.32.20000124115333.01072ec0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jan 2000 11:53:33 -0800
To: Ed Loehr <eloehr@austin.rr.com>, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Well, then you keep your darn columns
Cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <388C9664.1D975D2D@austin.rr.com>
References: <NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp>
<25852.948736429@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:13 PM 1/24/00 -0600, Ed Loehr wrote:
Tom Lane wrote:
Let's see: DROP COLUMN would have to mark the column invisible, remove
any associated constraints (particularly NOT NULL) and indexes, and
it'd be done. The parser would then have to ignore the column when
doing column name lookups or expansion of '*', and it would have to
insert a NULL value for the column when transforming INSERT or UPDATE.
And that'd be just about it. I like it.How would you handle multi-column indices that included the column
being dropped? E.g.,create unique index foobar on mytable(foo,bar);
where the 'bar' column is then dropped...
Dropping all of that index would seem to be problematic.
Hmmm...dropping the index is what Oracle does, or so claims their
documentation. It makes sense because getting rid of "bar"
may well mean that the uniquness constraint will no longer be
satisfied, right? In fact, odds are it won't for a multi-column
index. Anyway, Oracle drops all indices which reference the
column.
Also, it turns out that "drop column" in Oracle does reclaim the
space occupied by the data, but there's a "set unused" variant that
does EXACTLY what's being talked about - i.e. marks the column as
unused and makes it invisible to queries.
Interesting.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 15:01:40 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA19329
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:01:37 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA11883;
Mon, 24 Jan 2000 12:00:52 -0800 (PST)
Message-Id: <3.0.1.32.20000124115531.01071320@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jan 2000 11:55:31 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>, "Henry B. Hotz" <hotz@jpl.nasa.gov>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <25997.948737625@sss.pgh.pa.us>
References: <v04020a4eb4b23e7c41dd@[137.78.84.130]>
<v04020a4cb4b2354516da@[137.78.84.130]>
<v04020a4cb4b2354516da@[137.78.84.130]>
<v04020a4eb4b23e7c41dd@[137.78.84.130]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 01:13 PM 1/24/00 -0500, Tom Lane wrote:
In practice this would be happening at initdb time, not configure time,
since it'd be a lot easier to do it in C code than in a shell script.
But that's a detail. I'm still not clear on how you can wave away the
issue of kernel disk caching --- if you don't use a test file that's
larger than the disk cache, ISTM you risk getting a number that's
entirely devoid of any physical I/O at all.
And even the $100 6.4 GB Ultra DMA drive I bought last week has
2MB of cache. hdparm shows me getting 19 mB/second transfers
even though it adjusts for the file system cache. It's only a
5400 RPM disk and I'm certain the on-disk cache is impacting
this number.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 15:05:37 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA23590
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:05:05 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA13150;
Mon, 24 Jan 2000 12:04:25 -0800 (PST)
Message-Id: <3.0.1.32.20000124120220.01067490@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jan 2000 12:02:20 -0800
To: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Well, then you keep your darn columns
Cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.BSF.4.21.0001241543210.79710-100000@thelab.hub.org>
References: <25852.948736429@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 03:44 PM 1/24/00 -0400, The Hermit Hacker wrote:
Oh, there is a second drawback to it though ...
DROP COLUMN name
ADD COLUMN name <of a different type>Then what? :(
I don't understand...the idea is to make the old column name
invisible, and therefore "add column" won't see it either.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 15:25:38 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA27425
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:24:44 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA99607;
Mon, 24 Jan 2000 16:23:17 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 24 Jan 2000 16:23:16 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-Reply-To: <3.0.1.32.20000124120220.01067490@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0001241622250.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 24 Jan 2000, Don Baccus wrote:
At 03:44 PM 1/24/00 -0400, The Hermit Hacker wrote:
Oh, there is a second drawback to it though ...
DROP COLUMN name
ADD COLUMN name <of a different type>Then what? :(
I don't understand...the idea is to make the old column name
invisible, and therefore "add column" won't see it either.
so the pg_* file that maintains the 'fields' in a table would have two
fields of the same name, one enabled, one disabled?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Jan 24 15:27:37 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA27980
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:27:29 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA21097;
Mon, 24 Jan 2000 12:26:28 -0800 (PST)
Message-Id: <3.0.1.32.20000124122411.01076d10@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jan 2000 12:24:11 -0800
To: The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Well, then you keep your darn columns
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.BSF.4.21.0001241622250.79710-100000@thelab.hub.org>
References: <3.0.1.32.20000124120220.01067490@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 04:23 PM 1/24/00 -0400, The Hermit Hacker wrote:
so the pg_* file that maintains the 'fields' in a table would have two
fields of the same name, one enabled, one disabled?
Or perhaps the name is set to null, whatever.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 15:26:38 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA27679
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:25:52 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA99612;
Mon, 24 Jan 2000 16:24:26 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 24 Jan 2000 16:24:26 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Don Baccus <dhogaza@pacifier.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-Reply-To: <3.0.1.32.20000124113537.010734c0@mail.pacifier.com>
Message-ID: <Pine.BSF.4.21.0001241623360.79710-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 24 Jan 2000, Don Baccus wrote:
you could construe that as a feature --- you don't have to wait around
for a DROP COLUMN to finish. Anyone who did want to reclaim space
immediately could do
UPDATE table SET someothercolumn = someothercolumn;
followed by a VACUUM.Or perhaps vacuum could be made smart enough to remove deleted columns?
Perhaps optionally?
when bruce and I discussed this, that was one thing we both agreed upon
... Vacuum is too slow as it is, let alone adding in more things for it to
do :(
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Jan 24 15:26:37 2000
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA27702
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 15:26:05 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.243]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 24 Jan 2000 14:25:40 -0600
Sender: ed
Message-ID: <388CB580.6B336648@austin.rr.com>
Date: Mon, 24 Jan 2000 14:26:40 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
References: <NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp>
<25852.948736429@sss.pgh.pa.us>
<3.0.1.32.20000124115333.01072ec0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
How would you handle multi-column indices that included the column
being dropped? E.g.,create unique index foobar on mytable(foo,bar);
where the 'bar' column is then dropped...
... Oracle drops all indices which reference the column.
Seems like a new 'gotcha'... either way, informative warnings/notices
would be nice.
Along these same lines, how would pre-existing functions that
referenced the just-dropped column be handled? I'm thinking of
PL/pgSQL...
Cheers,
Ed Loehr
From bouncefilter Mon Jan 24 15:33:38 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA32607
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 15:32:56 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA23049;
Mon, 24 Jan 2000 12:31:52 -0800 (PST)
Message-Id: <3.0.1.32.20000124122948.01076800@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jan 2000 12:29:48 -0800
To: Ed Loehr <eloehr@austin.rr.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Well, then you keep your darn columns
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
In-Reply-To: <388CB580.6B336648@austin.rr.com>
References: <NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp>
<25852.948736429@sss.pgh.pa.us>
<3.0.1.32.20000124115333.01072ec0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:26 PM 1/24/00 -0600, Ed Loehr wrote:
Don Baccus wrote:
How would you handle multi-column indices that included the column
being dropped? E.g.,create unique index foobar on mytable(foo,bar);
where the 'bar' column is then dropped...
... Oracle drops all indices which reference the column.
Seems like a new 'gotcha'... either way, informative warnings/notices
would be nice.
I'm not saying that Oracle's "right", I just offer it as one datapoint.
I have access to an Oracle installation, so it's easy enough for me to
try things out.
If dropping the index were decided upon, a notice would be nice, yes.
Or, as Tom suggested, making the user drop relevant indices by hand
first as a safeguard.
Along these same lines, how would pre-existing functions that
referenced the just-dropped column be handled? I'm thinking of
PL/pgSQL...
I presume they'd fail just like any client software accessing those
columns via libpq queries, query files fed to psql, etc. Dropping
a column is something you don't want to do blithely in an existing,
complex application, that's for sure!
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 16:03:37 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id QAA45722
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 16:03:04 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA16128;
Mon, 24 Jan 2000 15:37:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001242037.PAA16128@candle.pha.pa.us>
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-Reply-To: <Pine.BSF.4.21.0001241543210.79710-100000@thelab.hub.org> from
The
Hermit Hacker at "Jan 24, 2000 03:44:20 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 24 Jan 2000 15:37:02 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
The only drawback of this scheme is that the space occupied by the
deleted column wouldn't go away immediately (in any given tuple,
it'd be reclaimed on the next UPDATE of the tuple). On the other hand,
you could construe that as a feature --- you don't have to wait around
for a DROP COLUMN to finish. Anyone who did want to reclaim space
immediately could do
UPDATE table SET someothercolumn = someothercolumn;
followed by a VACUUM. But I bet a lot of people would be just as
happy to let it happen in background.Hey Bruce ... Look here ^^^^ :)
Oh, there is a second drawback to it though ...
DROP COLUMN name
ADD COLUMN name <of a different type>Then what? :(
Double-yikes. There goes that idea, or does it? Attributes are
numbered. How does a missing attribute get handled for new rows?
My guess is that we have to keep this thing around forever. Can you
imagine having all those user apps tha query pg_attribute supress that
column. Sound like too much work to me.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 24 16:48:38 2000
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 QAA56371
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 16:47:41 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <D3KATMTJ>; Mon, 24 Jan 2000 23:44:00 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C488@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Ed Loehr '" <eloehr@austin.rr.com>, "'Tom Lane '" <tgl@sss.pgh.pa.us>
Cc: "'Hiroshi Inoue '" <Inoue@tpf.co.jp>, "'Peter Eisentraut '"
<peter_e@gmx.net>, "'pgsql-hackers@postgreSQL.org '"
<pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Well, then you keep your darn columns
Date: Mon, 24 Jan 2000 23:39:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
All the databases that I've worked on (that actually have the ability to
drop columns) generate an error if the column to be dropped is part of a
key, and I think that is sound behaviour.
MikeA
-----Original Message-----
From: Ed Loehr
To: Tom Lane
Cc: Hiroshi Inoue; Peter Eisentraut; pgsql-hackers@postgreSQL.org
Sent: 00/01/24 08:13
Subject: Re: [HACKERS] Well, then you keep your darn columns
Tom Lane wrote:
Let's see: DROP COLUMN would have to mark the column invisible, remove
any associated constraints (particularly NOT NULL) and indexes, and
it'd be done. The parser would then have to ignore the column when
doing column name lookups or expansion of '*', and it would have to
insert a NULL value for the column when transforming INSERT or UPDATE.
And that'd be just about it. I like it.
How would you handle multi-column indices that included the column
being dropped? E.g.,
create unique index foobar on mytable(foo,bar);
where the 'bar' column is then dropped...
Dropping all of that index would seem to be problematic.
Cheers,
Ed Loehr
************
From bouncefilter Mon Jan 24 16:46:38 2000
Received: from hu.tm.ee (ppp209.tele2.ee [212.107.33.209])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA56208
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 16:46:01 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 2A9391321E; Mon, 24 Jan 2000 23:52:08 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <388CC987.B5B86454@tm.ee>
Date: Mon, 24 Jan 2000 23:52:07 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
Cc: Adriaan Joubert <a.joubert@albourne.com>,
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
References: <Pine.BSF.4.21.0001241233300.79710-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
On Mon, 24 Jan 2000, Adriaan Joubert wrote:
As a user let me just say that I have been waiting for all the
'ALTER TABLE..' commands for a long time (changing constraints would be great
too!) and it has been mentioned many times that one should not use oids in
application code. The way I do it at the moment is to copy the table, so I
think all users are used to losing their oids when remocing a column from a
table. So while it is certainly better to keep the oids, Peter's code is a
big improvement on the current situation.Except, as Chris Bitmead brought up, OIDs appear to be a key requirement
in ODBMSs ... so, if we want to go what I *think* is 'next generation',
OIDs have to be kept ...
But the decision was (from Vadim IIRC) to drop them, at least in non system
tables.
The cited reasons were:
* crappy implementation that taxed performance (probably fixed by now)
* nobody else seemed to have them and the push then was to the direction of
mainstream bean-counting DB with main objective of getting that base
functionality right.
* they take up "too much" space (probably a non-issue in current world of
dropping disk/memory prices)
* you can always re-implement them at the application level (the same was
cited
for dropping time travel)
If it is now a general opinion that OIDs will remain, it should be stated
somewhere,
as I suspect that much of pg community operates under the impression that they
are
going away in future as have some other nice but not fully developed features
like
time travel.
I do understand that time travel could be implemented using a bunch of
rules+views
but to be really useful rules views should be much more developed and
integrated
with inheritance, up to the level where you could say:
create table stock(
item_id int,
quantity int,
price numeric(15,2)
) inherits (time_travel);
and then have all the needed tables/rules/views produced automatically.
If we had that level of sofistication we could also safely drop OIDs as a
built-in
system feature and still have it by changing the last line to
) inherits (time_travel,odbms_table);
-----------------
Hannu
From bouncefilter Mon Jan 24 16:54:38 2000
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA57159
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 16:54:00 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max03-089.enterprise.net
[194.72.196.89])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id VAA16928;
Mon, 24 Jan 2000 21:53:54 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id VAA25637;
Mon, 24 Jan 2000 21:52:57 GMT
Message-Id: <200001242152.VAA25637@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: Jan Wieck <wieck@debis.com>
cc: pgsql-hackers@postgresql.org
Subject: Inheritance, referential integrity and other constraints
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 24 Jan 2000 21:52:56 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>
I would like to work on improving implementation of inheritance,
especially with regard to referential integrity. I suspect there are
a number of issues that may be related and will need to be done together.
In addition, this will be my first attempt to do anything serious in
the PostgreSQL code itself, so I would like to get some hints as
to what I haven't even thought about!
First, I would like to change the definition of the foreign key
constraints to allow the inheritance star to follow a table name.
This would mean that, for RI purposes, the named table would be
aggregated with its descendants. So "REFERENCES tbl" would mean that
the foreign key must exist in tbl, but "REFERENCES tbl*" would allow it
to exist either in tbl or in any of tbl's descendants.
Implications: where * is used, dropping a descendant table is OK, so
long as the parent continues to exist. ON DELETE actions would apply
to all the relations in the table to be dropped; to reduce complexity,
this should be broken down into:
`DELETE FROM descendant; DROP TABLE descendant'
and the whole should be treated as atomic. If any one relation could
not be deleted, the whole operation would fail.
Use of ON DELETE or ON UPDATE implies there must be an index on the
referring column, to enable checking or deletion to be done speedily.
This doesn't seem to happen at the moment. If the reference is to
an inheritance group, it would seem to be appropriate that all the
tables in the group should use the same index. Similarly, where
a unique or primary key constraint is inherited, it may be desirable
to use a single index to manage the constraint. The implication of
this would be that there must be a check when a table is dropped
to make sure that a grouped index is not dropped until the last
table in the group is dropped.
Is this feasible, or would it require too many changes elsewhere?
Another item I would like to get fixed is to make sure that all
constraints are inherited when a descendant table is created; this
is a current TODO item. It will also be necessary to ensure that
added constraints get inherited, when ALTER TABLE ... ADD/DROP
CONSTRAINT gets implemented.
====== Design proposal =======
I think that the implications of inheritance have never been fully
explored and I would like to establish the framework in which future
work that involves inheritance will be done.
It seems to me that declaring a table to inherit from another, and
enabling both to be read together by the table* syntax, together
imply certain things about an inheritance group:
1. All tables in the group must possess all the columns of their
ancestor, and all those columns must be of the same type.
2. Some constraints at least must be shared - primary key is the most
obvious example; I think that _all_ constraints on inherited columns
should be shared. It is probably not practicable to force table
constraints to be shared upwards.
3. There seems to be no need to enforce similar restrictions on
GRANT. In fact it is quite likely that different permissions could
apply to different tables in the hierarchy.
4. Dropping a table implies dropping all its descendants.
==============================
I would like to consider the implications of this proposal in the light
of the ALTER TABLE commands that have recently been added.
The grammar for ALTER TABLE allows either `ALTER TABLE table ...' or
`ALTER TABLE table* ...'. I would like to suggest that an alteration
to a parent table must necessarily involve all its descendants and
that alterations to inherited columns must be done in the appropriate
parent. So, given this hierarchy of tables:
t1 (c1 char(2) primary key,
c2 text)
t2 (c3 int not null
c4 timestamp default current_timestamp) inherits (t1)
t3 (c5 text not null) inherits (t2)
adding a column to t1, means the same column must be added to t2 and t3
and must appear before any columns originating in t2; columns c1 to c4
cannot be dropped from table t3 unless they are also dropped from the
parents. Alterations to c2 must be done in t1, and alterations to c4
must be done in t2. Any table constraint applied to t1 would automatically
be inherited by t2 and t3, a new constraint added to t2 would be
inherited by t3 but would not affect t1.
Attempts to use ALTER TABLE to bypass these restrictions should be
disallowed.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"If anyone has material possessions and sees his
brother in need but has no pity on him, how can the
love of God be in him?"
I John 3:17
From bouncefilter Mon Jan 24 17:12:39 2000
Received: from hu.tm.ee (ppp209.tele2.ee [212.107.33.209])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA63384
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 17:11:59 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 4E5111321E; Tue, 25 Jan 2000 00:18:08 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <388CCF9F.809E93AC@tm.ee>
Date: Tue, 25 Jan 2000 00:18:07 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
Hiroshi Inoue <Inoue@tpf.co.jp>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
References: <200001242037.PAA16128@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
The only drawback of this scheme is that the space occupied by the
deleted column wouldn't go away immediately (in any given tuple,
it'd be reclaimed on the next UPDATE of the tuple). On the other hand,
you could construe that as a feature --- you don't have to wait around
for a DROP COLUMN to finish. Anyone who did want to reclaim space
immediately could do
UPDATE table SET someothercolumn = someothercolumn;
followed by a VACUUM. But I bet a lot of people would be just as
happy to let it happen in background.Hey Bruce ... Look here ^^^^ :)
Oh, there is a second drawback to it though ...
DROP COLUMN name
ADD COLUMN name <of a different type>
or the same type, it will be added at the end anyway.
part of making it invisible should be making its _name_ invisible in pg_*
one way would be to rename it to '\n'+str(next_available_oid) or sone other
invalid column name.
Then what? :(
Double-yikes. There goes that idea, or does it? Attributes are
numbered. How does a missing attribute get handled for new rows?
The proposition was to set it always to NULL (takes no additional storage
if there are other null columns, (fieldcnt+31)/8 bytes else.
BTW, the current handling of nulls in storage is a bit weird - the bitvector
for
null/not null starts at position 31, but if there is a bitmap space is
allocated
in 4-byte chunks starting at position 32 (at least on linux/x86)
My guess is that we have to keep this thing around forever.
Or until dump/reload, the renumbering will be automatic there.
Can you
imagine having all those user apps tha query pg_attribute supress that
column. Sound like too much work to me.
To me it sounds like a thing that _must_ be done at major number change,
so 7.0 is a good place.
OTOH, we could provide SQL92 ways for getting the info that current user
apps get by querying pg_attribute.
IIRC it requires a bunch of views on system tables, some of which could be
lifted straight from psql's \d* commands.
-----------------------------
Hannu
From bouncefilter Mon Jan 24 17:37:39 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA72097
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 17:36:45 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id OAA07513;
Mon, 24 Jan 2000 14:35:35 -0800 (PST)
Message-Id: <3.0.1.32.20000124143019.0107a3c0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jan 2000 14:30:19 -0800
To: Hannu Krosing <hannu@tm.ee>, The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Well, then you keep your darn columns
Cc: Adriaan Joubert <a.joubert@albourne.com>,
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
In-Reply-To: <388CC987.B5B86454@tm.ee>
References: <Pine.BSF.4.21.0001241233300.79710-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:52 PM 1/24/00 +0200, Hannu Krosing wrote:
But the decision was (from Vadim IIRC) to drop them, at least in non system
tables.
The cited reasons were:
* crappy implementation that taxed performance (probably fixed by now)
* nobody else seemed to have them and the push then was to the direction of
mainstream bean-counting DB with main objective of getting that base
functionality right.
Regarding this last, Oracle has an equivalent - rowid. In the web
toolkit I'm helping port, it's used somewhat often, and having oid
available has been a convenience.
Having said that, its use in this toolkit's could be replaced by
simply creating a sequence and numbering rows by hand. Their loss
wouldn't bother me particularly even though it would add a little
work (not much) to this project.
* they take up "too much" space (probably a non-issue in current world of
dropping disk/memory prices)
* you can always re-implement them at the application level (the same was
cited
for dropping time travel)
Yep!
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 17:37:39 2000
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id RAA73957
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 17:37:09 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA02667;
Mon, 24 Jan 2000 17:34:33 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001242234.RAA02667@candle.pha.pa.us>
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-Reply-To: <388CCF9F.809E93AC@tm.ee> from Hannu Krosing at "Jan 25,
2000 00:18:07 am"
To: Hannu Krosing <hannu@tm.ee>
Date: Mon, 24 Jan 2000 17:34:33 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
Hiroshi Inoue <Inoue@tpf.co.jp>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Can you
imagine having all those user apps tha query pg_attribute supress that
column. Sound like too much work to me.To me it sounds like a thing that _must_ be done at major number change,
so 7.0 is a good place.OTOH, we could provide SQL92 ways for getting the info that current user
apps get by querying pg_attribute.IIRC it requires a bunch of views on system tables, some of which could be
lifted straight from psql's \d* commands.
If this is going to require any significant backend baggage, I say drop
it. Things are complicated enough. I did temp tables in one file so we
would not have "I am a temp" and "I am not a temp" floating all over the
backend. I don't really want "I am not an attribute" around either.
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Jan 24 17:37:42 2000
Received: from hu.tm.ee (ppp209.tele2.ee [212.107.33.209])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA73985
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 17:37:33 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id DA6A91321E; Tue, 25 Jan 2000 00:43:41 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <388CD59D.74A3C03@tm.ee>
Date: Tue, 25 Jan 2000 00:43:41 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
Cc: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
References: <Pine.BSF.4.21.0001240856020.79710-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
Because the column is still in the table, just invisible after removing
from pg_attribute. You need to remove the column from the heap, and
that requires creating a new version of the table. Vacuum moves tuples
but does not make them shorter.That I understand ... excuse my ignorance, but what would it take to
do that? The way I envision a table 'on disk':col1col2col3col4col5|col1col2col3col4col5|col1col2col3col4col5|
I recently did a small python script to salvage deleted tuples and I can say
that current docs on the layout of storage are very incomplete ant partially
wrong.
Basically, you have X tuples per page, where a page is 8192bytes,
correct? If you were to remove, let's say, col2 out of the table, why
can't you do:lock table
read page 1 into memory
rewrite page1 to disk as:
col1col3col4col5|col1col3col4col5|col1col3col4col5|
add one to page and goto 'read page n to memory'
unlock tableI'm making an assumption here ... first one being that each 'tuples' has
some sort of endoftuple marker in the table ...
you do have startoftuple/startoffreespace (as a offset inside the page)
but getting at the starts of col2 and col3 is not that easy - you must use
all the accessor functions from pg_attribute and count null-bits (and
shift null-bitmap) if present
That's why I actually like the idea of just hiding the column (and setting
it to DEFAULT NULL) - you don't automatically reclaim space, but you don't
need much any extra space either. And it's very fast.
And as a practical person I like the current implementation too, mainly
because
it's there and it does not break anything, at least when you don't use it ;)
As it is not a feature anyone would use in scripts very often (except Don
Baccus ;)
If we're removing a column, the resultant 'page size' from the modified
page is going to be smaller then the original, so I would think it would
be a relatively simple thing, considering that its a read/re-write from
the same part of the 'on disk file' ...... and it wouldn't require 2X the space used by the table ...
But a system crash while doing it would do really bad things, not to mention
the fact that it bypasses storage manager making future changes to storage
managers very hard.
VACUUMs bypassing of storage manager is understandable as it is a part of
storage manager and not a general SQL thing - a garbage-collecting
all-in-memory
signing-while-working storage manager will not need vacuum, analyse it may
need,
perhaps.
-----------------
Hannu
From bouncefilter Mon Jan 24 17:50:39 2000
Received: from hu.tm.ee (ppp209.tele2.ee [212.107.33.209])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA76558
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 17:50:07 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id D50461321F; Tue, 25 Jan 2000 00:56:16 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <388CD890.494E6754@tm.ee>
Date: Tue, 25 Jan 2000 00:56:16 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "Henry B. Hotz" <hotz@jpl.nasa.gov>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
References: <v04020a4eb4b23e7c41dd@[137.78.84.130]>
<v04020a4cb4b2354516da@[137.78.84.130]>
<v04020a4cb4b2354516da@[137.78.84.130]>
<v04020a4eb4b23e7c41dd@[137.78.84.130]>
<3.0.1.32.20000124115531.01071320@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 01:13 PM 1/24/00 -0500, Tom Lane wrote:
In practice this would be happening at initdb time, not configure time,
or perhaps it can be collected when running regression tests.
since it'd be a lot easier to do it in C code than in a shell script.
But that's a detail. I'm still not clear on how you can wave away the
issue of kernel disk caching --- if you don't use a test file that's
larger than the disk cache, ISTM you risk getting a number that's
entirely devoid of any physical I/O at all.And even the $100 6.4 GB Ultra DMA drive I bought last week has
2MB of cache. hdparm shows me getting 19 mB/second transfers
even though it adjusts for the file system cache. It's only a
5400 RPM disk and I'm certain the on-disk cache is impacting
this number.
But they also claim internal bitrates of more than 250 Mbits/s, which stays
the same for both 5400 and 7200 RPM disks (the latter even have the same
seek time) so that may actually be true for sequential reads if they have
all their read paths at optimal efficiency and readahead and cache do
their job.
-------------
Hannu
From bouncefilter Mon Jan 24 18:16:39 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA85395
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:15:21 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id JAA03050;
Tue, 25 Jan 2000 09:58:42 +1100
Message-Id: <3.0.5.32.20000125100005.0334bea0@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 25 Jan 2000 10:00:05 +1100
To: Tom Lane <tgl@sss.pgh.pa.us>,
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: AW: [HACKERS] Some notes on optimizer cost estimates
Cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgresql.org>
In-Reply-To: <26017.948737877@sss.pgh.pa.us>
References:
<219F68D65015D011A8E000006F8590C603FDC21C@sdexcsrv1.f000.d0188.sd.spardat.at>
<219F68D65015D011A8E000006F8590C603FDC21C@sdexcsrv1.f000.d0188.sd.spardat.at>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 13:17 24/01/00 -0500, Tom Lane wrote:
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
My points are:
1. even if it is good for an optimizer to be smart,
it is even more important, that it is predictableA good point indeed. And unless we find that there is a huge range in
the ratios across different machines, we'd be wasting our time trying to
calibrate the numbers for a particular machine --- we could just as well
use an average value. The optimizer has many other, far worse, sources
of error than that.2. I compile on test machine, production is completely different
(more processors, faster disks and controllers)In practice we'd do this at initdb time, not configure time, so I'm
not sure that that's really an issue. But your other point is
well taken.
I would guess it would become an issue if a server is upgraded (better/more
disks, faster CPU etc). This could be fixed by storing the optimizer
settings in a system table in the DB, and reading them the first time a
backend opens it. Just an idea.
If you *do* go with the 'store them in the DB' solution, then you also need
to provide an way of updating them (SQL, presumably), and a utility to
refresh them based on the current hardware.
What this then amounts to is 'hand-tuning' of optimizer settings, which is
an old chestnut that I would like to see reconsidered - sometimes, for
specific important queries, it is very good to be able to tell the DB how
to go about satisfying the query (or at least, what join order to use and
which indices to scan). Is this so far removed from the above,
philosophically? Is it worth considering?
Bye for now,
Philip Warner.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
From bouncefilter Mon Jan 24 17:56:39 2000
Received: from hu.tm.ee (ppp209.tele2.ee [212.107.33.209])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA78094
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 17:56:35 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id E2DC61321E; Tue, 25 Jan 2000 01:02:41 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <388CDA11.5E2253FD@tm.ee>
Date: Tue, 25 Jan 2000 01:02:41 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Baccus <dhogaza@pacifier.com>
Cc: The Hermit Hacker <scrappy@hub.org>,
Adriaan Joubert <a.joubert@albourne.com>,
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
References: <Pine.BSF.4.21.0001241233300.79710-100000@thelab.hub.org>
<3.0.1.32.20000124143019.0107a3c0@mail.pacifier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Don Baccus wrote:
At 11:52 PM 1/24/00 +0200, Hannu Krosing wrote:
But the decision was (from Vadim IIRC) to drop them, at least in non system
tables.
The cited reasons were:
* crappy implementation that taxed performance (probably fixed by now)
* nobody else seemed to have them and the push then was to the direction of
mainstream bean-counting DB with main objective of getting that base
functionality right.Regarding this last, Oracle has an equivalent - rowid. In the web
toolkit I'm helping port, it's used somewhat often, and having oid
available has been a convenience.
My impression was thet Oracles ROWID is more like our TID - i.e. not a very
stable thing. I may be wrong of course, as last time I used oracle seriously
was more than 3 years ago.
Having said that, its use in this toolkit's could be replaced by
simply creating a sequence and numbering rows by hand.
Or using 'default nextid()' which seems to be the recommended and portable (?)
way.
----------------
Hannu
From bouncefilter Mon Jan 24 18:26:43 2000
Received: from acheron.rime.com.au (root@albatr.lnk.telstra.net
[139.130.54.222]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA87381
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 18:25:41 -0500 (EST)
(envelope-from pjw@rhyme.com.au)
Received: from oberon (Oberon.rime.com.au [203.8.195.100])
by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id KAA03130;
Tue, 25 Jan 2000 10:07:34 +1100
Message-Id: <3.0.5.32.20000125100856.0334bea0@mail.rhyme.com.au>
X-Sender: pjw@mail.rhyme.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 25 Jan 2000 10:08:56 +1100
To: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>
From: Philip Warner <pjw@rhyme.com.au>
Subject: Re: [HACKERS] Well, then you keep your darn columns
Cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgresql.org
In-Reply-To: <Pine.BSF.4.21.0001241543210.79710-100000@thelab.hub.org>
References: <25852.948736429@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 15:44 24/01/00 -0400, The Hermit Hacker wrote:
On Mon, 24 Jan 2000, Tom Lane wrote:
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
My idea is as follows.
1)add a visibile/invisible flag to pg_attribute
2)DROP COLUMN marks the column as invisible
3)user interface ignores the columns which are marked invisible
4)heap_formtuple() etc treats the column as NULL internally
...etc..
Oh, there is a second drawback to it though ...
DROP COLUMN name
ADD COLUMN name <of a different type>Then what? :(
Aren't there two separate issues to be resolved:
1. What happens with meta-data referential integrity - a problem for all
implementations.
2. How is it implemeneted.
For my 0.02c, the meta data integrity issue should be resolved by saying
'drop column' is not allowed if there is any (non-system-generated)
metadata that refers to it. Most people (I think) drop columns because they
have no use for them any longer. If they have indexes, constraints,
triggers etc based on those columns, then the drop should fail, since these
items are a prima-facie case that there is a use for them. Cascading
deletes are a nice thing, but for meta-data they can be quite dangerous.
As far as the implementation is concerned, I like the idea of 'hiding' the
deleted column, but am curious: can it be hidden more effectively so that
the only thing that ever sees it is the part of the code that reads it from
disk?
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
From bouncefilter Mon Jan 24 18:03:39 2000
Received: from hu.tm.ee (ppp209.tele2.ee [212.107.33.209])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA82026
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 18:03:22 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id D08161321E; Tue, 25 Jan 2000 01:09:31 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <388CDBAB.37869806@tm.ee>
Date: Tue, 25 Jan 2000 01:09:31 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
Hiroshi Inoue <Inoue@tpf.co.jp>, Peter Eisentraut <peter_e@gmx.net>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
References: <200001242234.RAA02667@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
OTOH, we could provide SQL92 ways for getting the info that current user
apps get by querying pg_attribute.IIRC it requires a bunch of views on system tables, some of which could be
lifted straight from psql's \d* commands.If this is going to require any significant backend baggage, I say drop
it. Things are complicated enough. I did temp tables in one file so we
would not have "I am a temp" and "I am not a temp" floating all over the
backend. I don't really want "I am not an attribute" around either.
Possible valid complain true for hidden attributes.
But the ANSI/ISO system table views gould probably done even as a add-on
package that just creates the views - with nothing in backend.
And promoting them as the default way for finding out about schema would free
us
from concerns about user-level apps when we need to change internal system
table
structures.
It could at least be added to TODO for 7.x
-----------------
Hannu
From bouncefilter Mon Jan 24 18:26:39 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA87453
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:26:12 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id PAA26026;
Mon, 24 Jan 2000 15:25:00 -0800 (PST)
Message-Id: <3.0.1.32.20000124151744.01081650@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jan 2000 15:17:44 -0800
To: Hannu Krosing <hannu@tm.ee>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Well, then you keep your darn columns
Cc: The Hermit Hacker <scrappy@hub.org>,
Adriaan Joubert <a.joubert@albourne.com>,
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
In-Reply-To: <388CDA11.5E2253FD@tm.ee>
References: <Pine.BSF.4.21.0001241233300.79710-100000@thelab.hub.org>
<3.0.1.32.20000124143019.0107a3c0@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 01:02 AM 1/25/00 +0200, Hannu Krosing wrote:
Regarding this last, Oracle has an equivalent - rowid. In the web
toolkit I'm helping port, it's used somewhat often, and having oid
available has been a convenience.My impression was thet Oracles ROWID is more like our TID - i.e. not a very
stable thing. I may be wrong of course, as last time I used oracle seriously
was more than 3 years ago.
Hmmm...maybe so. I'm not sure, either...porting existing Oracle code
to PostgreSQL by no means makes me an Oracle expert.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 18:24:39 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA87010
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:23:47 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA27786 for <pgsql-hackers@postgresql.org>;
Tue, 25 Jan 2000 10:23:10 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0ULhCo;
Tue Jan 25 10:22:40 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA09485 for <pgsql-hackers@postgresql.org>;
Tue, 25 Jan 2000 10:22:40 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdq91kM_; Tue Jan 25 10:22:08 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA03030
for <pgsql-hackers@postgresql.org>;
Tue, 25 Jan 2000 10:22:08 +1100 (EST)
Received: from majere.design (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA13373 for <pgsql-hackers@postgresql.org>;
Tue, 25 Jan 2000 10:21:32 +1100 (EST)
Received: from bitmead.com (localhost [127.0.0.1])
by majere.design (8.8.8+Sun/8.8.8) with ESMTP id KAA10702
for <pgsql-hackers@postgresql.org>;
Tue, 25 Jan 2000 10:20:50 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <388CDE51.E5240641@bitmead.com>
Date: Tue, 25 Jan 2000 10:20:49 +1100
From: Chris Bitmead <chris@bitmead.com>
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
References: <NDBBIJLOILGIKBGDINDFAEFDCCAA.Inoue@tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hiroshi Inoue wrote:
I propose another implementation here. I don't think this is so
important a feature. I'm only afraid of forced implementation
especially using copy() and rename() for such a feature.
Hi all....
Can I just point out that the above is THE RIGHT THING(tm). I havn't
followed this thread from the beginning, but can I point out that
implementing drop column as a copy/rename is not good (better than
nothing I guess).
Take a cue from a database like VERSANT (http://www.versant.com). You
can change the database's schema while the database is running. Time
taken to delete a column is roughly 0.0 seconds no matter how large the
table. Going the whole hog, you keep the old schema available so that
when you retrieve an old tuple it can be updated the next time that
tuple is updated.
My idea is as follows.
1)add a visibile/invisible flag to pg_attribute
2)DROP COLUMN marks the column as invisible
3)user interface ignores the columns which are marked invisible
4)heap_formtuple() etc treats the column as NULL internallyRegards.
Hiroshi Inoue
Inoue@tpf.co.jp************
From bouncefilter Mon Jan 24 18:32:46 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA92267
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:32:34 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12CsxL-0007dX-00; Mon, 24 Jan 2000 23:31:35 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12Csx5-00049r-00; Mon, 24 Jan 2000 23:31:19 +0000
Date: Mon, 24 Jan 2000 23:31:19 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: pg_dump possible fix, need testers.
Message-ID: <20000124233119.B29261@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
<20000124123000.C21345@quartz.newn.cam.ac.uk>
<25723.948734983@sss.pgh.pa.us>
<20000124175921.F21345@quartz.newn.cam.ac.uk>
<26041.948738004@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <26041.948738004@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Mon, Jan 24, 2000 at 01:20:04PM -0500
Earlier I wrote:
(New also, though probably unrelated: the sanity check fails with number of
index tuples exactly half number in heap - not equal)
TL> I think that you may have some subtle platform-specific problems in the
TL> backend.
On Mon, Jan 24, 2000, Tom Lane wrote:
TL> Hmm. Why don't you try running the parallel regression test, to see
TL> if that blows up too?
Rerunning the ordinary regression "runtest", the sanity_check passes. The
difference being that this time I wasn't running a select at the same time.
The parallel test "runcheck" fails on different parts at different times eg:
test select_into ... FAILED
because
! psql: connection to database "regression" failed - Backend startup failed
(BTW in resultmap, I need the .*-.*-netbsd rather than just netbsd, I think
it's because config.guess returns i386-unknown-netbsd1.4P, and just netbsd
would imply the string starts with netbsd)
3 times in a row now, gmake runtest on its own is fine, gmake runtest with a
concurrent join select makes sanity_check fail with
+ NOTICE: RegisterSharedInvalid: SI buffer overflow
+ NOTICE: InvalidateSharedInvalid: cache state reset
+ NOTICE: Index onek_stringu1: NUMBER OF INDEX' TUPLES (1000) IS NOT THE SAME AS HEAP' (2000).
+ Recreate the index.
+ NOTICE: Index onek_hundred: NUMBER OF INDEX' TUPLES (1000) IS NOT THE SAME AS
HEAP' (2000).
+ Recreate the index.and the join will still get itself confused
select * from crsids,"tblPerson" where
newnham-> crsids.crsid != "tblPerson"."CRSID";
Backend sent B message without prior T
D21Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
\.
Unknown protocol character 'M' read from backend. (The protocol character
is the first character the backend sends in response to a query it
receives).
PQendcopy: resetting connection
Asynchronous NOTIFY 'ndropoulou' from backend with pid '1818589281'
received.
Asynchronous NOTIFY 'ndropoulou' from backend with pid '1818589281'
received.
Then plenty of
pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32
keep on happening even though the connection is apparently dropped and psql
exited. Running a regression test during this fails sanity_check. Restart
postmaster, and the sanity_check passes. Run the join, and all breaks.
Ah - some joins work. The above join works if I replace * by "Surname". It
should return 750440 rows. It seems to just be a matter of quantity of data
going down the connection. A * row contains 428 varchars worth and about 10
numbers. Just in case it's just me, I'll build a new kernel (when in
kern_proc doubt..)
Cheers,
Patrick
From bouncefilter Mon Jan 24 18:36:39 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA93043
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 18:35:56 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA09458 for <pgsql-hackers@postgreSQL.org>;
Tue, 25 Jan 2000 10:35:24 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd0u7qFM;
Tue Jan 25 10:34:51 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA21098 for <pgsql-hackers@postgreSQL.org>;
Tue, 25 Jan 2000 10:34:50 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpd0DaQUE; Tue Jan 25 10:34:26 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA13369
for <pgsql-hackers@postgreSQL.org>;
Tue, 25 Jan 2000 10:34:25 +1100 (EST)
Received: from majere.design (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA13755 for <pgsql-hackers@postgreSQL.org>;
Tue, 25 Jan 2000 10:33:50 +1100 (EST)
Received: from bitmead.com (localhost [127.0.0.1])
by majere.design (8.8.8+Sun/8.8.8) with ESMTP id KAA10707
for <pgsql-hackers@postgreSQL.org>;
Tue, 25 Jan 2000 10:33:07 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <388CE133.EE3ADAC5@bitmead.com>
Date: Tue, 25 Jan 2000 10:33:07 +1100
From: Chris Bitmead <chris@bitmead.com>
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Inheritance,
referential integrity and other constraints
References: <200001242152.VAA25637@linda.lfix.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
As long as you're working on this area you could fix the problem where
if you do ALTER table* ADD COLUMN ... pg_dump no longer works because
the column orders have changed in different inherited tables.
Oliver Elphick wrote:
I would like to work on improving implementation of inheritance,
especially with regard to referential integrity. I suspect there are
a number of issues that may be related and will need to be done together.
In addition, this will be my first attempt to do anything serious in
the PostgreSQL code itself, so I would like to get some hints as
to what I haven't even thought about!First, I would like to change the definition of the foreign key
constraints to allow the inheritance star to follow a table name.
This would mean that, for RI purposes, the named table would be
aggregated with its descendants. So "REFERENCES tbl" would mean that
the foreign key must exist in tbl, but "REFERENCES tbl*" would allow it
to exist either in tbl or in any of tbl's descendants.Implications: where * is used, dropping a descendant table is OK, so
long as the parent continues to exist. ON DELETE actions would apply
to all the relations in the table to be dropped; to reduce complexity,
this should be broken down into:
`DELETE FROM descendant; DROP TABLE descendant'
and the whole should be treated as atomic. If any one relation could
not be deleted, the whole operation would fail.Use of ON DELETE or ON UPDATE implies there must be an index on the
referring column, to enable checking or deletion to be done speedily.
This doesn't seem to happen at the moment. If the reference is to
an inheritance group, it would seem to be appropriate that all the
tables in the group should use the same index. Similarly, where
a unique or primary key constraint is inherited, it may be desirable
to use a single index to manage the constraint. The implication of
this would be that there must be a check when a table is dropped
to make sure that a grouped index is not dropped until the last
table in the group is dropped.Is this feasible, or would it require too many changes elsewhere?
Another item I would like to get fixed is to make sure that all
constraints are inherited when a descendant table is created; this
is a current TODO item. It will also be necessary to ensure that
added constraints get inherited, when ALTER TABLE ... ADD/DROP
CONSTRAINT gets implemented.====== Design proposal =======
I think that the implications of inheritance have never been fully
explored and I would like to establish the framework in which future
work that involves inheritance will be done.It seems to me that declaring a table to inherit from another, and
enabling both to be read together by the table* syntax, together
imply certain things about an inheritance group:1. All tables in the group must possess all the columns of their
ancestor, and all those columns must be of the same type.2. Some constraints at least must be shared - primary key is the most
obvious example; I think that _all_ constraints on inherited columns
should be shared. It is probably not practicable to force table
constraints to be shared upwards.3. There seems to be no need to enforce similar restrictions on
GRANT. In fact it is quite likely that different permissions could
apply to different tables in the hierarchy.4. Dropping a table implies dropping all its descendants.
==============================
I would like to consider the implications of this proposal in the light
of the ALTER TABLE commands that have recently been added.The grammar for ALTER TABLE allows either `ALTER TABLE table ...' or
`ALTER TABLE table* ...'. I would like to suggest that an alteration
to a parent table must necessarily involve all its descendants and
that alterations to inherited columns must be done in the appropriate
parent. So, given this hierarchy of tables:t1 (c1 char(2) primary key,
c2 text)t2 (c3 int not null
c4 timestamp default current_timestamp) inherits (t1)t3 (c5 text not null) inherits (t2)
adding a column to t1, means the same column must be added to t2 and t3
and must appear before any columns originating in t2; columns c1 to c4
cannot be dropped from table t3 unless they are also dropped from the
parents. Alterations to c2 must be done in t1, and alterations to c4
must be done in t2. Any table constraint applied to t1 would automatically
be inherited by t2 and t3, a new constraint added to t2 would be
inherited by t3 but would not affect t1.Attempts to use ALTER TABLE to bypass these restrictions should be
disallowed.--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"If anyone has material possessions and sees his
brother in need but has no pity on him, how can the
love of God be in him?"
I John 3:17************
From bouncefilter Mon Jan 24 18:39:40 2000
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au
[202.12.144.17]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA93869
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 18:39:38 -0500 (EST)
(envelope-from chris@bitmead.com)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA12999 for <pgsql-hackers@postgreSQL.org>;
Tue, 25 Jan 2000 10:39:06 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17)
via SMTP by mailo.vtcif.telstra.com.au, id smtpd282wa_;
Tue Jan 25 10:38:38 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id
KAA24767 for <pgsql-hackers@postgreSQL.org>;
Tue, 25 Jan 2000 10:38:38 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au"
via SMTP by localhost, id smtpdHzuB3_; Tue Jan 25 10:38:18 2000
Received: from lunitari.nimrod.itg.telecom.com.au
(lunitari.nimrod.itg.telecom.com.au [192.53.254.48]) by
mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA16315
for <pgsql-hackers@postgreSQL.org>;
Tue, 25 Jan 2000 10:38:17 +1100 (EST)
Received: from majere.design (majere [192.53.254.45])
by lunitari.nimrod.itg.telecom.com.au (8.9.1/8.9.3) with ESMTP id
KAA13891 for <pgsql-hackers@postgreSQL.org>;
Tue, 25 Jan 2000 10:37:42 +1100 (EST)
Received: from bitmead.com (localhost [127.0.0.1])
by majere.design (8.8.8+Sun/8.8.8) with ESMTP id KAA10713
for <pgsql-hackers@postgreSQL.org>;
Tue, 25 Jan 2000 10:37:00 +1100 (EST)
Sender: chrisb@nimrod.itg.telstra.com.au
Message-ID: <388CE21C.26602A5E@bitmead.com>
Date: Tue, 25 Jan 2000 10:37:00 +1100
From: Chris Bitmead <chris@bitmead.com>
Organization: IBM Global Services
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
References: <200001242037.PAA16128@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Double-yikes. There goes that idea, or does it? Attributes are
numbered. How does a missing attribute get handled for new rows?
My guess is that we have to keep this thing around forever. Can you
imagine having all those user apps tha query pg_attribute supress that
column. Sound like too much work to me.
I don't know the intimate details of the postgres implementation, but I
would have thought every row would need a version number and you would
need to somehow store how the table looked at each version.
Because you could
CREATE TABLE
INSERT
ALTER DROP
INSERT/DELETE
ALTER DROP/ADD
INSERT/DELETE
and you would end up with rows with 5 or 6 different formats.
From bouncefilter Mon Jan 24 18:38:39 2000
Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA93448
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:38:06 -0500 (EST)
(envelope-from prlw1@newn.cam.ac.uk)
Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1)
id 12Ct3s-0007do-00; Mon, 24 Jan 2000 23:38:20 +0000
Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1)
id 12Ct3d-0004AE-00; Mon, 24 Jan 2000 23:38:05 +0000
Date: Mon, 24 Jan 2000 23:38:05 +0000
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: pg_dump possible fix, need testers.
Message-ID: <20000124233805.C29261@quartz.newn.cam.ac.uk>
Reply-To: prlw1@cam.ac.uk
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
<20000124123000.C21345@quartz.newn.cam.ac.uk>
<25723.948734983@sss.pgh.pa.us>
<20000124175921.F21345@quartz.newn.cam.ac.uk>
<26041.948738004@sss.pgh.pa.us>
<20000124154926.L26520@fw.wintelcom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.1i
In-Reply-To: <20000124154926.L26520@fw.wintelcom.net>;
from bright@wintelcom.net on Mon, Jan 24, 2000 at 03:49:26PM -0800
On Mon, Jan 24, 2000 at 03:49:26PM -0800, Alfred Perlstein wrote:
I just ran the regression tests as best as I know how:
~/pgcvs/pgsql/src/test/regress % gmake runcheck
~/pgcvs/pgsql/src/test/regress % grep FAIL run_check.out
test int2 ... FAILED
test int4 ... FAILED
test float8 ... FAILED
sequential test geometry ... FAILED
~/pgcvs/pgsql/src/test/regress %no int2/int4? yipes!
Not to worry, those will be differences in error message wording, but
I ran it 10 more times and one time I got:
test constraints ... FAILED
What did this error come from? (cf regression.diffs)
but i got no weird parse errors or anything from the backend.
Have you been able to find any weirdness with the fix I posted,
or is this more likely an issue with Patrick Welche's setup?
I'm not sure: on the one hand, that evil join of mine returns the entire
contents of a table, and the connection gets confused. Smaller joins work.
Maybe it doesn't happen to you because you don't put in such a useless
select (What do you want 750440 rows for?) On the other hand vacuum analyze
table_name doesn't work for me but obviously does for everyone else, so at
least something is wrong with my setup.
Cheers,
Patrick
From bouncefilter Mon Jan 24 18:41:42 2000
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 SAA94301
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:41:27 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61832 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S75808AbQAXXkk>;
Tue, 25 Jan 2000 00:40:40 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CtDK-00015C-00; Tue, 25 Jan 2000 00:48:06 +0100
Date: Tue, 25 Jan 2000 00:48:06 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: Tom Lane <tgl@sss.pgh.pa.us>, The Hermit Hacker <scrappy@hub.org>,
PostgreSQL Development <pgsql-hackers@postgresql.org>,
Bruce Momjian <pgman@candle.pha.pa.us>
Subject: RE: [HACKERS] Happy column dropping
In-Reply-To: <NDBBIJLOILGIKBGDINDFIEELCCAA.Inoue@tpf.co.jp>
Message-ID: <Pine.LNX.4.21.0001242145450.525-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-23, Hiroshi Inoue mentioned:
Anyway I have 2 basic questions.
1) Is the * 2x disk usage * implementation really needed ?
Yes, unless you bypass all transaction logic and do a get a row, change
the row, delete the old row, write the new row, and silently hope that no
problems come up down the line. If you do an SQL update of all the rows in
a 10GB table you temporarily need 20GB in case there is a rollback.
2) Why rename() ?
I don't trust rename() at all in transaction control.
The first thing we should do it to change relname -> relation file
name mapping in order to avoid calling rename().
That's a good point. The alter table / rename code makes free use of this,
which is just waiting to kick somebody in the head. If you think this
could be addressed in the next release, I'm even for dropping my
business and wait for a cleaner solution.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 24 18:41:47 2000
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 SAA94306
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:41:28 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62034 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S59427AbQAXXku>;
Tue, 25 Jan 2000 00:40:50 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CtDa-000168-00; Tue, 25 Jan 2000 00:48:22 +0100
Date: Tue, 25 Jan 2000 00:48:22 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <4776.948602291@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001242130430.525-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-22, Tom Lane mentioned:
AFAIK there is nothing particularly magic about OIDs. You could
perfectly well create the new table with the same OIDs as are in the
old table (see COPY WITH OIDS if you are wondering how).
Okay, the oids of the user data are safe.
Is it possible/safe to change to oid of the new pg_class entry back to the
old one? In that case the trouble of moving over all the constraints, etc.
would be half the work.Wrong way to think about it. You should be doing a heap_update of the
catalog tuples that need to change, ISTM.You could almost get away with doing it like you describe, except that
there is a unique index on pg_class OIDs these days (right, Bruce?)
and that index will kick out an error. But heap_update on the original
table tuple will work.I think what we may want here is something comparable to what's been
discussed recently for VACUUM: build the new table as a new heap file
and then rename the physical file into place, without really doing
anything to the pg_class tuple --- except of course you'd need to
heap_update it to adjust the number-of-attributes field.
I've tried to do that but it messed me up big time. If I drop the column
and do a select * from tablename it segfaults. The same happens on vacuum
analyze (but not plain vacuum). For the analyze part I traced it down to
the tuple that gets passed to nocachegetattr() still has t_data->t_natts
set at the old value put the data itself is no longer there, hence
segfault. Vacuum does some Page and MemoryContext things to get that
tuple, so I'm lost there, but I figure select has the same problem. Seems
like not all the buffers have been flushed, but there aren't any more I
could think of. Because when I reconnect, everything is fine. Help!
What more needs to be done?
newrel = heap_create(...);
{ copy data from oldrel to newrel }
{ update pg_class.relnatts }
{ update pg_attribute }
{ update pg_attrdef }
/* get rid of old one */
ReleaseRelationBuffers(oldrel);
smgrunlink(..., oldrelname);
RelationForgetRelation(oldrel_oid);
/* Rename the new one */
FlushRelationBuffers(tempname, (BlockNumber) 0, true);
smgrclose(..., tempname);
heap_close(newrel);
rename(tempname, oldrelname);
This is pretty much what it does. Not enough flushing? Too much flushing?
However, the more severe problem with this approach is this: If for some
reason whatsoever the rename() call fails you've already deleted the
original table on disk and now you're stuck with a heap file that you
can't rename plus a catalog entry to a table that doesn't exist on disk.
Panic. Any reordering of the above suggested? Of course, rename would
normally be able to atomically overwrite the old table, but since the
disk representation might be split over several files we lose. The table
renaming code makes some pretty dangerous assumptions in this regard, I
just noticed. Perhaps we should forbid this kind of messing with big
tables, at least until we come up with a better scheme. And that's leaving
alone the fact that calling rename in the first place is a pretty bad
violation of the storage manager encapsulation. Darn it.
2) how do I find out if the dropped column is referenced in a constraint,
trigger, rule (this is necessary for a correct RESTRICT/CASCADE
implementation)Actually it's worse than that: you need to be prepared to renumber the
columns after the dropped one, too. Probably what you will need to do
is read in and deparse all the relevant rules and triggers, then reparse
them against the updated table schema. Ugly. And no, I have no idea
how you even *find* all the relevant rules. (Jan?)
I think this will be postponed. This is not even done on DROP TABLE, so it
will be consistent. ;)
Oh, btw., heaven help you if you try this on tables that are inherited
from.The whole thing should be done inside a recursive routine that applies
the same change to all children of the target table. See ALTER TABLE
ADD COLUMN for an example. (ADD COLUMN is pretty broken too, since it
doesn't preserve consistency of column numbering across child tables ---
want to reimplement it in this same style?)
Yes I saw that. I'm just going to forbid use of this on inheritance trees
until all of this gets fixed in one run.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 24 18:41:39 2000
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 SAA94351
for <hackers@postgresql.org>; Mon, 24 Jan 2000 18:41:35 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62199 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S100387AbQAXXk7>;
Tue, 25 Jan 2000 00:40:59 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CtDl-00016H-00; Tue, 25 Jan 2000 00:48:33 +0100
Date: Tue, 25 Jan 2000 00:48:33 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] psql updates
In-Reply-To: <20704.948559054@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001242357080.525-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-22, Tom Lane mentioned:
The tab-completion
behavior seems a little flaky (if you press tab when you don't have
a partial keyword typed, it wipes out whatever word you do have typed)
In some cases this might be intentional. For example, when you enter
=> insert xx<tab>
then the xx gets replaced by INTO because it's the only valid thing to put
there anyway. If you observed someting different, then I'd be interested
in looking at it.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 24 18:42:45 2000
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 SAA94475
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:41:55 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62516 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S34847AbQAXXlQ>;
Tue, 25 Jan 2000 00:41:16 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CtDz-00016N-00; Tue, 25 Jan 2000 00:48:47 +0100
Date: Tue, 25 Jan 2000 00:48:47 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <4776.948602291@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.21.0001242215060.525-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-22, Tom Lane mentioned:
2) how do I find out if the dropped column is referenced in a constraint,
trigger, rule (this is necessary for a correct RESTRICT/CASCADE
implementation)Actually it's worse than that: you need to be prepared to renumber the
columns after the dropped one, too. Probably what you will need to do
is read in and deparse all the relevant rules and triggers, then reparse
them against the updated table schema. Ugly. And no, I have no idea
how you even *find* all the relevant rules. (Jan?)
Perhaps their should be a pg_attribute.attisusedbytrigger::oid,
pg_attribute.attisconstrainedbyconstr::oid, etc. Eventually, I think, this
is unavoidable if you want DROP TABLE to do the right thing as well, and
scanning and decoding possibly hundreds of rules, triggers, and
constraints won't get you far.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 24 18:42:40 2000
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 SAA94496
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:42:05 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62690 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S96288AbQAXXl3>;
Tue, 25 Jan 2000 00:41:29 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CtEB-00016P-00; Tue, 25 Jan 2000 00:48:59 +0100
Date: Tue, 25 Jan 2000 00:48:59 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Don Baccus <dhogaza@pacifier.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Happy column dropping
In-Reply-To: <3.0.1.32.20000123072658.01040560@mail.pacifier.com>
Message-ID: <Pine.LNX.4.21.0001242148490.525-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-23, Don Baccus mentioned:
I certainly don't want to discourage Peter, either, and perhaps
was a bit too harsh. But release of a feature this half-baked
would fit the stereotype many people have held towards free,
open source software, and postgres in particular.
Who said something of a release? Whatever happened to release early,
release often?
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 24 18:26:40 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA87535
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 18:26:37 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id PAA11569;
Mon, 24 Jan 2000 15:49:26 -0800 (PST)
Date: Mon, 24 Jan 2000 15:49:26 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Patrick Welche <prlw1@newn.cam.ac.uk>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: pg_dump possible fix, need testers.
Message-ID: <20000124154926.L26520@fw.wintelcom.net>
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
<20000124123000.C21345@quartz.newn.cam.ac.uk>
<25723.948734983@sss.pgh.pa.us>
<20000124175921.F21345@quartz.newn.cam.ac.uk>
<26041.948738004@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <26041.948738004@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Mon, Jan 24, 2000 at 01:20:04PM -0500
* Tom Lane <tgl@sss.pgh.pa.us> [000124 10:54] wrote:
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
This morning I cvs'd made, installed, moved data->data2, initdb, started
up postmaster, reloaded data (this worked!), then tried the join. It's a
big one, so I thought I might as well stress it at the same time, and did
a regression test.Anything I could try to narrow the problem down?
Hmm. Why don't you try running the parallel regression test, to see
if that blows up too?
I just ran the regression tests as best as I know how:
~/pgcvs/pgsql/src/test/regress % gmake runcheck
~/pgcvs/pgsql/src/test/regress % grep FAIL run_check.out
test int2 ... FAILED
test int4 ... FAILED
test float8 ... FAILED
sequential test geometry ... FAILED
~/pgcvs/pgsql/src/test/regress %
no int2/int4? yipes!
I ran it 10 more times and one time I got:
test constraints ... FAILED
but i got no weird parse errors or anything from the backend.
Have you been able to find any weirdness with the fix I posted,
or is this more likely an issue with Patrick Welche's setup?
-Alfred
From bouncefilter Mon Jan 24 18:43:39 2000
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 SAA94969
for <pgsql-general@postgresql.org>;
Mon, 24 Jan 2000 18:42:55 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63393 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S67619AbQAXXmJ>;
Tue, 25 Jan 2000 00:42:09 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CtEt-00016Z-00; Tue, 25 Jan 2000 00:49:43 +0100
Date: Tue, 25 Jan 2000 00:49:43 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Jose Soares <jose@sferacarta.com>
cc: pgsql-general@postgresql.org,
Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [GENERAL] max(oid)
In-Reply-To: <388C6577.A14466BD@sferacarta.com>
Message-ID: <Pine.LNX.4.21.0001242110090.525-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-24, Jose Soares mentioned:
We need also aggregates for data type TIME
MAX(time)
MIN(time)
Thomas, do you think this could be done?
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 24 18:43:44 2000
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 SAA94976
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 18:42:56 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63595 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S61473AbQAXXmX>;
Tue, 25 Jan 2000 00:42:23 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CtF1-00016b-00; Tue, 25 Jan 2000 00:49:51 +0100
Date: Tue, 25 Jan 2000 00:49:51 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Marc Tardif <admin@wtbwts.com>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [GENERAL] max(oid)
In-Reply-To: <200001230318.WAA02830@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.21.0001242109040.525-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
Btw., this is fixed now.
On 2000-01-22, Bruce Momjian mentioned:
Got it. TODO updated.
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
On 2000-01-21, Bruce Momjian mentioned:
Is there a way to use the max aggregate on an oid field? When I try on
6.5.3, I get the following error message:test=> select max(uid) from user_base;
ERROR: Unable to select an aggregate function max(oid)If there's any work-around, please let me know.
MarcAdded to TODO:
* allow aggregates on oid
We already had a TODO item for this and came to the conclusion that
* Make type equivalency apply to aggregates
will solve this.For right now the user could do the following:
INSERT INTO pg_aggregate VALUES ('max', <your user id>, 'int4larger', '-',
'-', 26, 26, 0, 26, NULL, NULL);--
Peter Eisentraut Sernanders v_g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 24 18:43:40 2000
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 SAA95009
for <hackers@postgresql.org>; Mon, 24 Jan 2000 18:43:15 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63844 "EHLO
regulus.its.uu.se")
by merganser.its.uu.se with ESMTP id <S38943AbQAXXmh>;
Tue, 25 Jan 2000 00:42:37 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 12CtFC-00016d-00; Tue, 25 Jan 2000 00:50:02 +0100
Date: Tue, 25 Jan 2000 00:50:02 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Vince Vielhaber <vev@michvhf.com>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] New install doc
In-Reply-To: <XFMail.000122203652.vev@michvhf.com>
Message-ID: <Pine.LNX.4.21.0001242105030.525-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>
On 2000-01-22, Vince Vielhaber mentioned:
# chown -R postgres:postgres /usr/local/pgsql
that should be the same on most systems with perhaps the exception of the
colon. Anyway it'll make sure that all the files have the correct owners.
The reason I mentioned it is on one install where I used:
install -u postgres -g postgres
all of the directories were created ug root:wheel and the files in them
were ug postgres:postgres so I had to go back one and do the above chown.
PostgreSQL couldn't create databases.
Ha! If you try to subvert the make install logic then you're on your
own. The directories are created by a script called mkinstalldirs (which
is used by the rest of the world as well) and that doesn't know about
permissions. If you would like this to work, then how about patching up
mkinstalldirs? You'll find it in the src dir, it's a really simple thingy.
--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Mon Jan 24 18:57:40 2000
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA98277
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 18:56:58 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id PAA08080;
Mon, 24 Jan 2000 15:55:41 -0800 (PST)
Message-Id: <3.0.1.32.20000124155337.010834f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jan 2000 15:53:37 -0800
To: Peter Eisentraut <peter_e@gmx.net>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Happy column dropping
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
In-Reply-To: <Pine.LNX.4.21.0001242148490.525-100000@localhost.localdoma
in>
References: <3.0.1.32.20000123072658.01040560@mail.pacifier.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:48 AM 1/25/00 +0100, Peter Eisentraut wrote:
On 2000-01-23, Don Baccus mentioned:
I certainly don't want to discourage Peter, either, and perhaps
was a bit too harsh. But release of a feature this half-baked
would fit the stereotype many people have held towards free,
open source software, and postgres in particular.Who said something of a release? Whatever happened to release early,
release often?
Is "release early, release often" why RH 6.1 doesn't seem to recognize
memory > 64 MB on a wide variety of x86 systems, the exact same boxes
on which RH 6.0 properly detected memory? (kernel 2.2.*)
Sometimes I wonder...it leaves the impression that RH 6.1 left the house
with little QA testing.
I was unaware that other folks had pointed to the copy/rename approach
earlier as being a possible means of implementation. I thought you'd
pulled that one out of your hat. Still, more advance discussion would've
perhaps led to other approaches to investigate, just as discussion
now is doing.
I'm going to be blunt: implementation of "drop column" by doing a copy/rename
isn't something one expects of a competitive commercial-quality RDBMS.
Perhaps it's the best we can expect of Postgres, though. If so, so be it.
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From bouncefilter Mon Jan 24 18:57:40 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA98316
for <hackers@postgreSQL.org>; Mon, 24 Jan 2000 18:57:07 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id SAA27227;
Mon, 24 Jan 2000 18:57:01 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] psql updates
In-reply-to: <Pine.LNX.4.21.0001242357080.525-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001242357080.525-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Tue, 25 Jan 2000 00:48:33 +0100"
Date: Mon, 24 Jan 2000 18:57:01 -0500
Message-ID: <27224.948758221@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
On 2000-01-22, Tom Lane mentioned:
The tab-completion
behavior seems a little flaky (if you press tab when you don't have
a partial keyword typed, it wipes out whatever word you do have typed)
In some cases this might be intentional. For example, when you enter
=> insert xx<tab>
then the xx gets replaced by INTO because it's the only valid thing to put
there anyway. If you observed someting different, then I'd be interested
in looking at it.
What I see with this ancient libreadline is
SELECT zz<tab>
zz is wiped out and replaced by a single space. However, this does
*not* happen with more modern readlines; and since I don't even know
where to get source code corresponding to the readline that's on this
old Linux system, I doubt it's worth worrying about.
regards, tom lane
From bouncefilter Mon Jan 24 19:00:39 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA99490
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 19:00:25 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA27263;
Mon, 24 Jan 2000 19:00:16 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-reply-to: <Pine.LNX.4.21.0001242215060.525-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001242215060.525-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Tue, 25 Jan 2000 00:48:47 +0100"
Date: Mon, 24 Jan 2000 19:00:16 -0500
Message-ID: <27260.948758416@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
Perhaps their should be a pg_attribute.attisusedbytrigger::oid,
pg_attribute.attisconstrainedbyconstr::oid, etc. Eventually, I think, this
is unavoidable if you want DROP TABLE to do the right thing as well, and
scanning and decoding possibly hundreds of rules, triggers, and
constraints won't get you far.
Wouldn't help much: when you do a DROP TRIGGER, do you turn off the
attisusedbytrigger, or not? You'd still end up scanning everything,
just at a different time.
Maybe if it were a reference count, and not just a bit --- but I'd sure
hate to try to guarantee that we maintain the reference count
accurately.
regards, tom lane
From bouncefilter Mon Jan 24 19:21:40 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA08360
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 19:21:16 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA27378;
Mon, 24 Jan 2000 19:19:31 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Don Baccus <dhogaza@pacifier.com>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Happy column dropping
In-reply-to: <Pine.LNX.4.21.0001242148490.525-100000@localhost.localdomain>
References: <Pine.LNX.4.21.0001242148490.525-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
message dated "Tue, 25 Jan 2000 00:48:59 +0100"
Date: Mon, 24 Jan 2000 19:19:31 -0500
Message-ID: <27375.948759571@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut <peter_e@gmx.net> writes:
I certainly don't want to discourage Peter, either, and perhaps
was a bit too harsh. But release of a feature this half-baked
would fit the stereotype many people have held towards free,
open source software, and postgres in particular.
Who said something of a release?
Um, you do recall that we are one week from feature-freeze for 7.0 beta,
don't you? It's mighty late in the cycle to be committing code that you
are not expecting to release in more or less its current form. The
reason the howls have been so loud is that because of the calendar,
everyone is assuming that you intend to release this code more or less
as it stands.
If that was *not* your intent, perhaps you had better pull the code out
until after we fork the tree for 7.1 development.
Whatever happened to release early, release often?
The Postgres project has generally adopted a more conservative approach
to releases, because we know that people entrust critical data to
DBMSes. We don't have anything that corresponds to a development
release series; *all* our releases are supposed to be "stable releases".
Of course we don't always get there, but that's the idea.
Jan has been muttering that we ought to have some means of dealing with
code development that spans multiple release cycles, ie, CVS branches
for work that is not expected to be part of the very next release.
I've found it hard enough to keep track of tip vs. last release branch,
but maybe something like that is needed. It would let people push code
out for review without implying that they think it's good enough to go
into the next release.
regards, tom lane
From bouncefilter Mon Jan 24 19:16:40 2000
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 TAA07522
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 19:16:10 -0500 (EST) (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 JAA05953; Tue, 25 Jan 2000 09:15:33 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Peter Eisentraut" <peter_e@gmx.net>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, "The Hermit Hacker" <scrappy@hub.org>,
"PostgreSQL Development" <pgsql-hackers@postgreSQL.org>,
"Bruce Momjian" <pgman@candle.pha.pa.us>
Subject: RE: [HACKERS] Happy column dropping
Date: Tue, 25 Jan 2000 09:21:15 +0900
Message-ID: <000b01bf66ca$17c86820$2801007e@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: <Pine.LNX.4.21.0001242145450.525-100000@localhost.localdomain>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
-----Original Message-----
From: Peter Eisentraut [mailto:peter@sd.tpf.co.jp]On Behalf Of Peter
EisentrautOn 2000-01-23, Hiroshi Inoue mentioned:
Anyway I have 2 basic questions.
1) Is the * 2x disk usage * implementation really needed ?
Yes, unless you bypass all transaction logic and do a get a row, change
the row, delete the old row, write the new row, and silently hope that no
problems come up down the line. If you do an SQL update of all the rows in
a 10GB table you temporarily need 20GB in case there is a rollback.
I have already proposed another idea.
It only changes pg_attribute not touching relation files at all.
Probably it isn't the best solution but would be better than 2x disk usage
implementation.
2) Why rename() ?
I don't trust rename() at all in transaction control.
The first thing we should do it to change relname -> relation file
name mapping in order to avoid calling rename().That's a good point. The alter table / rename code makes free use of this,
which is just waiting to kick somebody in the head. If you think this
could be addressed in the next release, I'm even for dropping my
business and wait for a cleaner solution.
I wonder that no one but me has complained about this.
CLUSTER/ALTER TABLE RENAME TO already have the same flaw.
And maybe restructuring VACUUM also.
As far as I see,fixed mapping relname to relation filename is the
problem. This doesn't allow the coexistence of old and new relation
files. If old and new relation files could coexist we would be able to
update the relation_file_name attribute(we should add this kind of
atribute) of pg_class. Of cource,there must be the standard
mechanism to remove old files after commit.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Mon Jan 24 19:26:40 2000
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA09076
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 19:25:57 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id TAA27425;
Mon, 24 Jan 2000 19:25:44 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Peter Eisentraut" <peter_e@gmx.net>,
"The Hermit Hacker" <scrappy@hub.org>,
"PostgreSQL Development" <pgsql-hackers@postgreSQL.org>,
"Bruce Momjian" <pgman@candle.pha.pa.us>
Subject: Re: [HACKERS] Happy column dropping
In-reply-to: <000b01bf66ca$17c86820$2801007e@tpf.co.jp>
References: <000b01bf66ca$17c86820$2801007e@tpf.co.jp>
Comments: In-reply-to "Hiroshi Inoue" <Inoue@tpf.co.jp>
message dated "Tue, 25 Jan 2000 09:21:15 +0900"
Date: Mon, 24 Jan 2000 19:25:43 -0500
Message-ID: <27422.948759943@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
As far as I see,fixed mapping relname to relation filename is the
problem. This doesn't allow the coexistence of old and new relation
files.
Yes, and Vadim has proposed using relation OIDs as filenames for
reasons of his own, IIRC.
If we did that we could also solve the problems we have now with
rolling back table deletion/rename inside an aborted transaction.
I've been resisting this idea, but maybe it's time to bite the bullet
and accept that relation filenames can't be the same as the logical
names of the relations.
regards, tom lane
From bouncefilter Mon Jan 24 20:07:40 2000
Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA22294
for <pgsql-hackers@postgreSQL.org>;
Mon, 24 Jan 2000 20:06:46 -0500 (EST)
(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
by fw.wintelcom.net (8.9.3/8.9.3) id RAA14290;
Mon, 24 Jan 2000 17:30:49 -0800 (PST)
Date: Mon, 24 Jan 2000 17:30:49 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: prlw1@cam.ac.uk
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: pg_dump possible fix, need testers.
Message-ID: <20000124173048.P26520@fw.wintelcom.net>
References: <20000122211427.C26520@fw.wintelcom.net>
<200001230525.AAA08020@candle.pha.pa.us>
<20000122220256.H26520@fw.wintelcom.net>
<20000124123000.C21345@quartz.newn.cam.ac.uk>
<25723.948734983@sss.pgh.pa.us>
<20000124175921.F21345@quartz.newn.cam.ac.uk>
<26041.948738004@sss.pgh.pa.us>
<20000124154926.L26520@fw.wintelcom.net>
<20000124233805.C29261@quartz.newn.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000124233805.C29261@quartz.newn.cam.ac.uk>;
from prlw1@newn.cam.ac.uk on Mon, Jan 24, 2000 at 11:38:05PM +0000
* Patrick Welche <prlw1@newn.cam.ac.uk> [000124 16:02] wrote:
On Mon, Jan 24, 2000 at 03:49:26PM -0800, Alfred Perlstein wrote:
I just ran the regression tests as best as I know how:
~/pgcvs/pgsql/src/test/regress % gmake runcheck
~/pgcvs/pgsql/src/test/regress % grep FAIL run_check.out
test int2 ... FAILED
test int4 ... FAILED
test float8 ... FAILED
sequential test geometry ... FAILED
~/pgcvs/pgsql/src/test/regress %no int2/int4? yipes!
Not to worry, those will be differences in error message wording, but
I ran it 10 more times and one time I got:
test constraints ... FAILEDWhat did this error come from? (cf regression.diffs)
but i got no weird parse errors or anything from the backend.
Have you been able to find any weirdness with the fix I posted,
or is this more likely an issue with Patrick Welche's setup?I'm not sure: on the one hand, that evil join of mine returns the entire
contents of a table, and the connection gets confused. Smaller joins work.
Maybe it doesn't happen to you because you don't put in such a useless
select (What do you want 750440 rows for?) On the other hand vacuum analyze
table_name doesn't work for me but obviously does for everyone else, so at
least something is wrong with my setup.
whoa whoa whoa... I just updated my snapshot to today's code and lot
more seems broken:
10 runs of the regression test:
test aggregates ... FAILED
test alter_table ... FAILED
test btree_index ... FAILED
test create_misc ... FAILED
test create_operator ... FAILED
test float8 ... FAILED
test hash_index ... FAILED
test int2 ... FAILED
test int4 ... FAILED
test limit ... FAILED
test portals ... FAILED
test portals_p2 ... FAILED
test random ... FAILED
test rules ... FAILED
test select_distinct ... FAILED
test select_distinct_on ... FAILED
test select_views ... FAILED
test transactions ... FAILED
test triggers ... FAILED
sequential test create_type ... FAILED
sequential test create_view ... FAILED
sequential test geometry ... FAILED
sequential test select ... FAILED
I'm going to see what happens if i revert my changes
to libpq completely, but before updating from and old
repo of 2-3 daysall i get are the int/float single constraints
error.
runtests and regression diffs are at:
http://www.freebsd.org/~alfred/postgresql/
-Alfred
From bouncefilter Mon Jan 24 20:39:41 2000
Received: from thelab.hub.org (nat206.228.mpoweredpc.net [142.177.206.228])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA31142
for <pgsql-hackers@postgresql.org>;
Mon, 24 Jan 2000 20:38:50 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA02794;
Mon, 24 Jan 2000 21:34:48 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 24 Jan 2000 21:34:48 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Well, then you keep your darn columns
In-Reply-To: <200001242037.PAA16128@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0001242133440.362-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 24 Jan 2000, Bruce Momjian wrote:
The only drawback of this scheme is that the space occupied by the
deleted column wouldn't go away immediately (in any given tuple,
it'd be reclaimed on the next UPDATE of the tuple). On the other hand,
you could construe that as a feature --- you don't have to wait around
for a DROP COLUMN to finish. Anyone who did want to reclaim space
immediately could do
UPDATE table SET someothercolumn = someothercolumn;
followed by a VACUUM. But I bet a lot of people would be just as
happy to let it happen in background.Hey Bruce ... Look here ^^^^ :)
Oh, there is a second drawback to it though ...
DROP COLUMN name
ADD COLUMN name <of a different type>Then what? :(
Double-yikes. There goes that idea, or does it? Attributes are
not necessarily, just playing devil's advocate ... :)
numbered. How does a missing attribute get handled for new rows?
My guess is that we have to keep this thing around forever. Can you
imagine having all those user apps tha query pg_attribute supress that
column. Sound like too much work to me.
I *still* think the best is the "re-write the table in place" method
... we already have most of the logic, I would think, from VACUUM ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org