Postgres problems with 6.4 / 6.5 (fwd)

Hi Andrew,

1) Doing a pg_dump and psql -f on a database I get lots of errors saying
"query buffer max length of 16384 exceeded" and then (eventually) I get
a segmentation fault. The load lines don't seem to be that large (the
full insert statement, including error, is maybe 220 bytes. It seems
that if I split the dumped file into 40-line chunks and do a vacuum
after each one, I can get the whole thing to load without the errors.

I think there must be some specific peculiarity in your data that's
causing this; certainly lots of people rely on pg_dump for backup
without problems. Can you provide a sample script that triggers the
problem?

Further investigation reveals that if I do a VACUUM immediately after
the DROP TABLE that things are OK, but otherwise the pg_attribute* files
in the database directory just get bigger and bigger. This is even the
case when I do a VACUUM after every second 'DROP TABLE' - for the space
to be recovered, I have to VACUUM immediately after a DROP TABLE, which
doesn't seem right somehow.

That does seem odd. If you just create and drop tables like mad then
I'd expect pg_class, pg_attribute, etc to grow --- the rows in them
that describe your dropped tables don't get recycled until you vacuum.
But vacuum should reclaim the space.

Actually, wait a minute. Is it pg_attribute itself that fails to shrink
after vacuum, or is it the indexes on pg_attribute? IIRC we have a known
problem with vacuum failing to reclaim space in indexes. There is a
patch available that improves the behavior for 6.5.*, and I believe that
improving it further is on the TODO list for 7.0.

I think you can find that patch in the patch mailing list archives at
www.postgresql.org, or it may already be in 6.5.2 (or failing that,
in the upcoming 6.5.3). [Anyone know for sure?]

For user tables it's possible to work around the problem by dropping and
rebuilding indexes every so often, but DO NOT try that on pg_attribute.
As a stopgap solution you might consider not dropping and recreating
your temp table; leave it around and just delete all the rows in it
between uses.

regards, tom lane

From bouncefilter Tue Oct 19 11:12:54 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA49353
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 11:12:05 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA09351;
Tue, 19 Oct 1999 11:11:12 -0400 (EDT)
To: wieck@debis.com (Jan Wieck)
cc: maillist@candle.pha.pa.us (Bruce Momjian), pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Readline use in trouble?
In-reply-to: Your message of Tue, 19 Oct 1999 16:35:22 +0200 (MET DST)
<m11daME-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Tue, 19 Oct 1999 11:11:11 -0400
Message-ID: <9349.940345871@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

I think readline isn't our biggest problem. What about if
they notice that our parser can only be compiled when using
bison, and that we ship the generated output for the case
someone doesn't has bison installed?

Non problem. From the Bison manual:

File: bison.info, Node: Conditions, Next: Copying, Prev: Introduction, Up: Top

Conditions for Using Bison
**************************

As of Bison version 1.24, we have changed the distribution terms for
`yyparse' to permit using Bison's output in non-free programs.
Formerly, Bison parsers could be used only in programs that were free
software.

The other GNU programming tools, such as the GNU C compiler, have
never had such a requirement. They could always be used for non-free
software. The reason Bison was different was not due to a special
policy decision; it resulted from applying the usual General Public
License to all of the Bison source code.

The output of the Bison utility--the Bison parser file--contains a
verbatim copy of a sizable piece of Bison, which is the code for the
`yyparse' function. (The actions from your grammar are inserted into
this function at one point, but the rest of the function is not
changed.) When we applied the GPL terms to the code for `yyparse', the
effect was to restrict the use of Bison output to free software.

We didn't change the terms because of sympathy for people who want to
make software proprietary. *Software should be free.* But we
concluded that limiting Bison's use to free software was doing little to
encourage people to make other software free. So we decided to make the
practical conditions for using Bison match the practical conditions for
using the other GNU tools.

regards, tom lane

From bouncefilter Tue Oct 19 12:22:57 1999
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 MAA67275
for <hackers@postgreSQL.org>; Tue, 19 Oct 1999 12:22:14 -0400 (EDT)
(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 RAA22982;
Tue, 19 Oct 1999 17:13:03 +0200
Date: Tue, 19 Oct 1999 17:13:02 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Need refresh on main page...
In-Reply-To: <380C91F6.8383E6A1@wgcr.org>
Message-ID: <Pine.LNX.3.96.991019170258.22482A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Oct 1999, Lamar Owen wrote:

Vince Vielhaber wrote:

Actually that's on our main page, which is just announcements. The news
page (Latest News on the menu bar) gets quite involved. Would someone
care to give me some updated text for that as well?

"RPM's for PostgreSQL 6.5.2 are now available, and shipped with RedHat
Linux version 6.1. Included in these RPMS:

Hmm RedHat, and for Debian (and people which needn't Hat for comp-work:-) exists
package with 6.5.2?

------------------------------------------------------------------------------
<zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/

Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
------------------------------------------------------------------------------
...and cathedral dilapidate

From bouncefilter Tue Oct 19 11:13:55 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id LAA49731
for <hackers@postgresql.org>; Tue, 19 Oct 1999 11:13:28 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 826 invoked by uid 1001); 19 Oct 1999 15:13:27 -0000
Date: Tue, 19 Oct 1999 11:13:27 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: webmaster@postgresql.org, Lamar Owen <lamar.owen@wgcr.org>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: Need refresh on main page...
In-Reply-To: <380C84FF.40B12272@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.05.9910191111430.282-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Oct 1999, Thomas Lockhart wrote:

The following is the next-to-last paragraph on our main news page:

RedHat RPMs for v6.5.1 on i386 machines are now available at
ftp://postgresql.org/pub/RPMS/ Please report any questions or problems
to pgsql-ports@postgresql.org. For details check out the Latest News.

RPMs for v6.5.2 are available, built by Lamar, and we need to get
these posted at postgresql.org (they are shipping with the latest RH
release already). Lamar, I dropped the ball on this; where would I
pick up the RPMs?

Actually that's on our main page, which is just announcements. The news
page (Latest News on the menu bar) gets quite involved. Would someone
care to give me some updated text for that as well?

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Tue Oct 19 11:18:55 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA51623;
Tue, 19 Oct 1999 11:18:32 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id LAA11407;
Tue, 19 Oct 1999 11:18:18 -0400
Message-ID: <380C8BB4.3B78704D@wgcr.org>
Date: Tue, 19 Oct 1999 11:18:12 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Vince Vielhaber <vev@michvhf.com>, webmaster@postgresql.org,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: Need refresh on main page...
References: <380C84FF.40B12272@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

RPMs for v6.5.2 are available, built by Lamar, and we need to get
these posted at postgresql.org (they are shipping with the latest RH
release already). Lamar, I dropped the ball on this; where would I
pick up the RPMs?

There are now many sites -- the best connected of which is rufus.w3.org.

If you use wget, try
wget ftp://rufus.w3.org/linux/redhat/redhat-6.1/SRPMS/SRPMS/postgr*
to get the source rpm.

Binaries for RedHat 6.1 are in
ftp://rufus.w3.org/linux/redhat/redhat-6.1/i386/RedHat/RPMS/postg*

Binaries for RedHat 6.0 and RedHat 5.2 are only available on my site so
far:
wget -r http://www.ramifordistat.net/postgres/RPMS

All binaries mentioned are Intel. RedHat 6.1, of course, also shipped
for sparc and Alpha -- rufus is a good mirror.

I would like to hear from someone who will try the RedHat 6.1 RPMS on a
RedHat 6._0_ system -- if they work fine, I'll remove the 6.0 rpms, and
replace with the 6.1 RPM's. I had already updated my systems, quite
foolishly, to 6.1, when I realized that RPMS built on 6.1 _might_ not
run on 6.0. I should have run the 6.1 RPMset on 6.0 first, but I
didn't. 6.1 is too nice to downgrade from, IMO.

If, OTOH, they don't work fine, well, I'll cross that bridge when I come
to it. That bridge will involve me blowing RedHat 6.0 back into one
partition on my dev box, just like 5.2 has its own partition.

If any developers who want to try the RPM's, but do not have RedHat and
don't want to pay $30 for a set of CD's, check out www.cheapbytes.com --
cheapest place on the Internet for Linux and *BSD CD's. $1.99 US will
get you a RedHat 6.1 CD (plus shipping). Of course, you can download the
ISO images and burn your own CD....

BTW: Only one bug in the 6.5.2-1 RPMS has been reported to Bugzilla
(developer.redhat.com/bugzilla) -- and that was the lack of
postgresql-clients (needless to say, the bug was quickly resolved ;-)).

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Oct 19 11:23:55 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA53445
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 11:22:55 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id LAA11415;
Tue, 19 Oct 1999 11:22:50 -0400
Message-ID: <380C8CC4.7DC8D78F@wgcr.org>
Date: Tue, 19 Oct 1999 11:22:44 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
References: <9237.940344241@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

So it's no issue for source distributions, but I wonder about RPMs.
Our RPMs do not include the actual libreadline file, do they?

No.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Oct 19 11:45:56 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA60599;
Tue, 19 Oct 1999 11:45:06 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id LAA11449;
Tue, 19 Oct 1999 11:44:59 -0400
Message-ID: <380C91F6.8383E6A1@wgcr.org>
Date: Tue, 19 Oct 1999 11:44:54 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Vince Vielhaber <vev@michvhf.com>
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>, webmaster@postgresql.org,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: Need refresh on main page...
References: <Pine.BSF.4.05.9910191111430.282-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vince Vielhaber wrote:

Actually that's on our main page, which is just announcements. The news
page (Latest News on the menu bar) gets quite involved. Would someone
care to give me some updated text for that as well?

"RPM's for PostgreSQL 6.5.2 are now available, and shipped with RedHat
Linux version 6.1. Included in these RPMS:

* Functional pgAccess 0.98
* Patches to support the Alpha under RedHat Linux
* The regression tests (postgresql-test*.rpm)
* Updated man pages from Thomas Lockhart
* Patches from Thomas Lockhart to gram.y
* Migration scripts to aid in moving between database file formats
* The PostgreSQL-HOWTO.

To install, simply use 'rpm -i' to install each RPM you want. A minimal
server installation is postgresql and postgresql-server. The first time
the init script is run, the database structure will automatically be
created if one doesn't already exist.

To upgrade, simply use 'rpm -U' to upgrade each rpm. The
postgresql-clients rpm found in versions prior to 6.5 has been split up
into several different packages, and will be removed in the upgrade.
After performing 'rpm -U', please read the file
'/usr/doc/postgresql-6.5.2/README.rpm' for instructions on completing
the upgrade.

If you make heavy use of large objects and other structures that are
difficult to dump with pg_dump, you will need to make other upgrade
provisions.

More detailed documentation is also available at
http://www.ramifordistat.net&quot;

???

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Oct 19 11:52:55 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA61979
for <pgsql-hackers@postgresql.org>;
Tue, 19 Oct 1999 11:52:26 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id LAA11464;
Tue, 19 Oct 1999 11:52:21 -0400
Message-ID: <380C93AF.EACA0AF7@wgcr.org>
Date: Tue, 19 Oct 1999 11:52:15 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: peter_e@gmx.net, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: New developer globe
References: <m11dXR5-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Wieck wrote:

Peter Eisentraut wrote:

I think that we have by far the coolest developers page of any
open-source'ish project out there. What I miss is something like a line
what people do in their Real Life. From what I gather most people around
here are probably one of programmer, system admin, or in academia. But it
would put a refreshing realistic context to the whole thing.

Exactly that is something NOT to put on this page. Don't make
the job of headhunters too easy!

I don't mind people knowing that in 'real life' I'm a broadcast
engineer/webmaster/network admin/preacher....

*** puts on asbestos suit ***

Looser, that's not bullet proof :-)

Nomex/Kevlar is.... And fire-resistant too.... ;-)

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Oct 19 11:54:55 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id LAA62328
for <hackers@postgresql.org>; Tue, 19 Oct 1999 11:54:48 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 986 invoked by uid 1001); 19 Oct 1999 15:54:48 -0000
Date: Tue, 19 Oct 1999 11:54:48 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>, webmaster@postgresql.org,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: Need refresh on main page...
In-Reply-To: <380C91F6.8383E6A1@wgcr.org>
Message-ID: <Pine.BSF.4.05.9910191154230.282-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Oct 1999, Lamar Owen wrote:

Vince Vielhaber wrote:

Actually that's on our main page, which is just announcements. The news
page (Latest News on the menu bar) gets quite involved. Would someone
care to give me some updated text for that as well?

"RPM's for PostgreSQL 6.5.2 are now available, and shipped with RedHat
Linux version 6.1. Included in these RPMS:

Perfect! Thank you!

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Tue Oct 19 12:28:59 1999
Received: from meryl.csd.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA68561
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 12:28:21 -0400 (EDT)
(envelope-from e99re41@csd.uu.se)
Received: from enequist.csd.uu.se (e99re41@enequist.csd.uu.se [130.238.15.83])
by meryl.csd.uu.se (8.8.5/8.8.5) with SMTP id SAA12966;
Tue, 19 Oct 1999 18:24:25 +0200 (MET DST)
Date: Tue, 19 Oct 1999 18:24:24 +0200 (MET DST)
From: Peter Eisentraut <e99re41@csd.uu.se>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <199910191341.JAA23790@candle.pha.pa.us>
Message-ID: <Pine.GSO.3.96.991019181546.24574A-100000@enequist.csd.uu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

From GPL, section 0:

"Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope."

We are not copying, distributing, or modifying readline.

"The act of running the Program is not restricted, ..."

Writing
char * foo = readline("");
is the same as writing
int bar = system("/bin/gzip");
just that they chose to create their product in a way that you have to use
the former method rather than the latter.

"... and the output from the Program is covered only if its contents
constitute a work based on the Program"

I always thunk that the output of readline is a work based on the user.

Anyway, when the BSD folks get their libedit act together, we can easily
replace one with the other. That was one of the requests by the folks out
there, and I got it done.

-Peter

On Tue, 19 Oct 1999, Bruce Momjian wrote:

Here is something I read as part of the Alladin Ghostscript 6.0 beta
release. I must admit I don't understand the logic of the issue. It
seems the issue is that you can link non-GPL to GPL libraries, but you
can't distribute the result. Maybe it doesn't apply to us because we
don't copyright our code.

It seems to suggest that we could be prevented from distributing
readline in the future. Not sure though.

It sounds like the old US crypto restriction where you couldn't
distribute software that had hooks in it to add crypto.

Removal of readline would certainly affect psql users.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Wed Oct 20 00:40:04 1999
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA80923;
Wed, 20 Oct 1999 00:39:09 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA23786;
Tue, 19 Oct 1999 16:27:51 GMT
Sender: lockhart@hub.org
Message-ID: <380C9C07.FE26CBBD@alumni.caltech.edu>
Date: Tue, 19 Oct 1999 16:27:51 +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>, Lamar Owen <lamar.owen@wgcr.org>
CC: webmaster@postgresql.org, Postgres Hackers List <hackers@postgresql.org>
Subject: Re: Need refresh on main page...
References: <Pine.BSF.4.05.9910191154230.282-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Perfect! Thank you!

I've fetched the RPMs from rufus.org and from Lamar's own site to give
a complete set of RPMs at ftp://postgresql.org/pub/{RPMS,SRPMS}.

Lamar, there is a slight difference in sizes of srpm files fetched
using wget from rufus.org and from your site:

From ramisartpuyaartelh:

... 7456019 Sep 27 13:52 postgresql-6.5.2-1.src.rpm

From rufus (via wget):

... 7456234 Sep 26 23:01 postgresql-6.5.2-1.src.rpm

I've put your srpm on postgresql.org, but I'm not sure if it is the
right choice. Why the difference??

- Thomas

btw, I didn't know about wget; it solves all the problems I was
worried about wrt updating postgresql.org from your site. Nice
utility...

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Tue Oct 19 12:46:55 1999
Received: from meryl.csd.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA72332
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 12:46:24 -0400 (EDT)
(envelope-from e99re41@csd.uu.se)
Received: from enequist.csd.uu.se (e99re41@enequist.csd.uu.se [130.238.15.83])
by meryl.csd.uu.se (8.8.5/8.8.5) with SMTP id SAA13491;
Tue, 19 Oct 1999 18:34:32 +0200 (MET DST)
Date: Tue, 19 Oct 1999 18:34:32 +0200 (MET DST)
From: Peter Eisentraut <e99re41@csd.uu.se>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <9237.940344241@sss.pgh.pa.us>
Message-ID: <Pine.GSO.3.96.991019182852.24574B-100000@enequist.csd.uu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Oct 1999, Tom Lane wrote:

Huh? We certainly do --- or have you missed that
* Copyright (c) 1994, Regents of the University of California
that's plastered across all the source files?

Regarding which I have a question: at other locations I see (c) 1994-7
Univ. of California, or even (c) 1996-9 PostgreSQL Global Development
Team.

I am not an expert in any of this, but I'm just wondering: when did the
involvement of the U of C end, when was the Global Development Team (tm)
formed and do both copyrights exits in parallel? What if someone
contributes something really major and fairly independent (say like
pg_access) and wants to keep his own copyright (with compatible license of
course)?

And is the PostgreSQL Global Development Team any real entity that could
theoretically enforce that copyright or is it just an alias for "whoever
contributed"?

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Oct 19 12:39:55 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id MAA70922
for <hackers@postgresql.org>; Tue, 19 Oct 1999 12:39:34 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 1101 invoked by uid 1001); 19 Oct 1999 16:39:35 -0000
Date: Tue, 19 Oct 1999 12:39:35 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Lamar Owen <lamar.owen@wgcr.org>, webmaster@postgresql.org,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: Need refresh on main page...
In-Reply-To: <380C9C07.FE26CBBD@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.05.9910191238500.282-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Oct 1999, Thomas Lockhart wrote:

Perfect! Thank you!

I've fetched the RPMs from rufus.org and from Lamar's own site to give
a complete set of RPMs at ftp://postgresql.org/pub/{RPMS,SRPMS}.

Website's updated as well.

[snip]

btw, I didn't know about wget; it solves all the problems I was
worried about wrt updating postgresql.org from your site. Nice
utility...

Yeah it is. I use it all the time.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Tue Oct 19 14:03:57 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA85485
for <hackers@postgreSQL.org>; Tue, 19 Oct 1999 14:03:22 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id OAA11747;
Tue, 19 Oct 1999 14:03:26 -0400
Message-ID: <380CB263.B784CE33@wgcr.org>
Date: Tue, 19 Oct 1999 14:03:15 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Zakkr <zakkr@zf.jcu.cz>
CC: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Need refresh on main page...
References: <Pine.LNX.3.96.991019170258.22482A-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Zakkr wrote:

Hmm RedHat, and for Debian (and people which needn't Hat for comp-work:-) exists
package with 6.5.2?

I don't know if Oliver has updated the Debian packages (which he
maintains) for PostgreSQL to 6.5.2.

As for RPM's for other than RedHat, I'm working on that problem.

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Oct 19 14:06:57 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA86025;
Tue, 19 Oct 1999 14:06:15 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id OAA11766;
Tue, 19 Oct 1999 14:05:59 -0400
Message-ID: <380CB2FC.EAC6B8F4@wgcr.org>
Date: Tue, 19 Oct 1999 14:05:48 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Vince Vielhaber <vev@michvhf.com>
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>, webmaster@postgresql.org,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Need refresh on main page...
References: <Pine.BSF.4.05.9910191154230.282-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vince Vielhaber wrote:

"RPM's for PostgreSQL 6.5.2 are now available, and shipped with RedHat
Linux version 6.1. Included in these RPMS:

Perfect! Thank you!

Glad to help.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Oct 19 14:12:56 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA87139;
Tue, 19 Oct 1999 14:12:47 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id OAA11779;
Tue, 19 Oct 1999 14:12:04 -0400
Message-ID: <380CB46C.5ABE007A@wgcr.org>
Date: Tue, 19 Oct 1999 14:11:56 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Vince Vielhaber <vev@michvhf.com>
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>, webmaster@postgresql.org,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: Need refresh on main page...
References: <Pine.BSF.4.05.9910191238500.282-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vince Vielhaber wrote:

On Tue, 19 Oct 1999, Thomas Lockhart wrote:

I've fetched the RPMs from rufus.org and from Lamar's own site to give
a complete set of RPMs at ftp://postgresql.org/pub/{RPMS,SRPMS}.

Website's updated as well.

And looks good.

[snip]

btw, I didn't know about wget; it solves all the problems I was
worried about wrt updating postgresql.org from your site. Nice
utility...

Yeah it is. I use it all the time.

Runs great within cron -- the -q switch is your friend ;-). I mirror
via cron using wget the update repository on rufus -- another great part
of wget is the ability to infinitely retry (-t 0).

For some reason I didn't get the reply from Thomas. I don't _think_ I
had a network glitch (he says while firing up a log analyzer...)...

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Wed Oct 20 01:50:06 1999
Received: from tanja.fam-meskes.de (root@p3E9D3E28.dip0.t-ipconnect.de
[62.157.62.40]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA89525
for <pgsql-hackers@postgresql.org>;
Wed, 20 Oct 1999 01:49:17 -0400 (EDT)
(envelope-from michael@fam-meskes.de)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id UAA01160;
Tue, 19 Oct 1999 20:29:46 +0200
Date: Tue, 19 Oct 1999 20:29:46 +0200
From: Michael Meskes <meskes@postgresql.org>
To: Jan Wieck <wieck@debis.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: New developer globe
Message-ID: <19991019202946.B1137@fam-meskes.de>
Mail-Followup-To: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgresql.org
References: <Pine.GSO.4.02A.9910191243390.9537-100000@Svan.DoCS.UU.SE>
<m11dXR5-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0pre4i
In-Reply-To: <m11dXR5-0003kLC@orion.SAPserv.Hamburg.dsh.de>;
from wieck@debis.com on Tue, Oct 19, 1999 at 01:28:11PM +0200

On Tue, Oct 19, 1999 at 01:28:11PM +0200, Jan Wieck wrote:

Exactly that is something NOT to put on this page. Don't make
the job of headhunters too easy!

Why not? Personally I have no problem with a headhunter offering me a good
job.

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 Oct 19 15:18:57 1999
Received: from web2103.mail.yahoo.com (web2103.mail.yahoo.com [128.11.68.247])
by hub.org (8.9.3/8.9.3) with SMTP id PAA96679
for <pgsql-hackers@postgresql.org>;
Tue, 19 Oct 1999 15:18:13 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19991019191835.25569.rocketmail@web2103.mail.yahoo.com>
Received: from [24.26.132.204] by web2103.mail.yahoo.com;
Tue, 19 Oct 1999 12:18:35 PDT
Date: Tue, 19 Oct 1999 12:18:35 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] Re: [BUGS] Postgres problems with 6.4 / 6.5 (fwd)
To: Andrew@cat-it.co.nz
Cc: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

And, of course, in the next release (or in current),
you'll be able to do a:

TRUNCATE TABLE frequentlyusedtable;
INSERT INTO frequentlyusedtable SELECT...;

and not have to worry about ever-growing indexes,
grants, etc.

;-)

Mike Mascari
(mascarim@yahoo.com)

--- Tom Lane <tgl@sss.pgh.pa.us> wrote:

Hi Andrew,

1) Doing a pg_dump and psql -f on a database I get

lots of errors saying

"query buffer max length of 16384 exceeded" and

then (eventually) I get

a segmentation fault. The load lines don't seem

to be that large (the

full insert statement, including error, is maybe

220 bytes. It seems

that if I split the dumped file into 40-line

chunks and do a vacuum

after each one, I can get the whole thing to load

without the errors.

I think there must be some specific peculiarity in
your data that's
causing this; certainly lots of people rely on
pg_dump for backup
without problems. Can you provide a sample script
that triggers the
problem?

Further investigation reveals that if I do a

VACUUM immediately after

the DROP TABLE that things are OK, but otherwise

the pg_attribute* files

in the database directory just get bigger and

bigger. This is even the

case when I do a VACUUM after every second 'DROP

TABLE' - for the space

to be recovered, I have to VACUUM immediately

after a DROP TABLE, which

doesn't seem right somehow.

That does seem odd. If you just create and drop
tables like mad then
I'd expect pg_class, pg_attribute, etc to grow ---
the rows in them
that describe your dropped tables don't get recycled
until you vacuum.
But vacuum should reclaim the space.

Actually, wait a minute. Is it pg_attribute itself
that fails to shrink
after vacuum, or is it the indexes on pg_attribute?
IIRC we have a known
problem with vacuum failing to reclaim space in
indexes. There is a
patch available that improves the behavior for
6.5.*, and I believe that
improving it further is on the TODO list for 7.0.

I think you can find that patch in the patch mailing
list archives at
www.postgresql.org, or it may already be in 6.5.2
(or failing that,
in the upcoming 6.5.3). [Anyone know for sure?]

For user tables it's possible to work around the
problem by dropping and
rebuilding indexes every so often, but DO NOT try
that on pg_attribute.
As a stopgap solution you might consider not
dropping and recreating
your temp table; leave it around and just delete all
the rows in it
between uses.

regards, tom lane

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

From bouncefilter Tue Oct 19 15:39:57 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA99648
for <pgsql-hackers@postgresql.org>;
Tue, 19 Oct 1999 15:39:47 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:4739 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s1AXr244030>;
Tue, 19 Oct 1999 21:39:35 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2) id 11df8u-0000Gp-00
for pgsql-hackers@postgresql.org; Tue, 19 Oct 1999 21:41:56 +0200
Date: Tue, 19 Oct 1999 21:41:55 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgresql.org
Subject: psql Week 3
Message-ID: <Pine.LNX.4.10.9910192107580.981-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

For external reasons I didn't get as much done as I wanted. Originally, I
planned for 4 weeks and I think I can keep that.

The source is posted at http://www.pathwaynet.com/~peter/psql3.tar.gz

CHANGELOG
* Accommodated object descriptions in \d* commands.
* Re-wrote \dd
* Re-wrote \d "table"
* \pset command as generic way for setting printing options (e.g.,
\pset format html, \pset null "(null)")
* Proliferated use of const char * and enums
* Rewrote \di, \dt, \ds, \dS. Say hello to \dv for views, which are
now recognized correctly. You can also call, e.g., \dtvi for a list
of indices, tables, and views. The possibilities are endless ...
(where "endless" = 325)

Also I wrote new printing routines which are better abstracted so that one
could easily throw in new formats. Here are some examples. Let me know if
you hate them.

(Sorry that this is a little long.)

peter@localhost:5432 play=> \pset format aligned
peter@localhost:5432 play=> \pset border 0
peter@localhost:5432 play=> select * from foo;
first second
-------- ------------
2
0 -----
0 hi
34
-1 -2
yo &&& <> ho
99999999 this is text
(7 rows)
peter@localhost:5432 play=> \pset border 1
peter@localhost:5432 play=> select * from foo;
first | second
----------+--------------
2 |
0 | -----
0 | hi
34 |
-1 | -2
| yo &&& <> ho
99999999 | this is text
(7 rows)
peter@localhost:5432 play=> \pset border 2
peter@localhost:5432 play=> select * from foo;
+----------+--------------+
| first | second |
+----------+--------------+
| 2 | |
| 0 | ----- |
| 0 | hi |
| 34 | |
| -1 | -2 |
| | yo &&& <> ho |
| 99999999 | this is text |
+----------+--------------+
(7 rows)
peter@localhost:5432 play=> \pset format unaligned
peter@localhost:5432 play=> \pset fieldsep ",,"
peter@localhost:5432 play=> select * from foo;
first,,second
2,,
0,,-----
0,,hi
34,,
-1,,-2
,,yo &&& <> ho
99999999,,this is text
(7 rows)
peter@localhost:5432 play=> \t
Turned on only tuples
peter@localhost:5432 play=> \x
Turned on expanded table representation
peter@localhost:5432 play=> select * from foo;

first,,2
second,,

first,,0
second,,-----

first,,0
second,,hi

first,,34
second,,

first,,-1
second,,-2

first,,
second,,yo &&& <> ho

first,,99999999
second,,this is text
peter@localhost:5432 play=> \pset border 1
peter@localhost:5432 play=> \pset format html
peter@localhost:5432 play=> \pset expanded
Turned off expanded display
peter@localhost:5432 play=> select * from foo;
<table border=1>
<tr valign=top>
<td align=right>2</td>
<td align=left>&nbsp;</td>
</tr>
<tr valign=top>
<td align=right>0</td>
<td align=left>-----</td>
</tr>
<tr valign=top>
<td align=right>0</td>
<td align=left>hi</td>
</tr>
<tr valign=top>
<td align=right>34</td>
<td align=left>&nbsp;</td>
</tr>
<tr valign=top>
<td align=right>-1</td>
<td align=left>-2</td>
</tr>
<tr valign=top>
<td align=right>&nbsp;</td>
<td align=left>yo &amp;&amp;&amp; &lt;&gt; ho</td>
</tr>
<tr valign=top>
<td align=right>99999999</td>
<td align=left>this is text</td>
</tr>
</table>
peter@localhost:5432 play=> \t
Turned off only tuples
peter@localhost:5432 play=> \pset border 2
peter@localhost:5432 play=> \pset null "(null)"
peter@localhost:5432 play=> \pset format latex
peter@localhost:5432 play=> select * from foo;
\begin{tabular}{|r|l|}
\hline
first & second \\
\hline
2 & (null) \\
0 & ----- \\
0 & hi \\
34 & (null) \\
-1 & -2 \\
(null) & yo &&& <> ho \\ % Yes, this needs to be escaped.
99999999 & this is text \\
\hline
\end{tabular}

(7 rows) \\
peter@localhost:5432 play=> \pset null
Current null display is "(null)".
peter@localhost:5432 play=> \pset fieldsep
Current field separator is ",,".

(Oh, you actually read all the way down to here? Good.)

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Oct 19 17:58:59 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA21090
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 17:58:35 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA14166;
Tue, 19 Oct 1999 17:32:36 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910192132.RAA14166@candle.pha.pa.us>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <m11daME-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 19, 1999 04:35:22 pm"
To: Jan Wieck <wieck@debis.com>
Date: Tue, 19 Oct 1999 17:32:36 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Removal of readline would certainly affect psql users.

Now the time has come that the FSF has grown that big that
they try to redefine the meaning of "Free". Next they claim
"Free" is their trademark :-(

I think readline isn't our biggest problem. What about if
they notice that our parser can only be compiled when using
bison, and that we ship the generated output for the case
someone doesn't has bison installed?

I always thought that was OK because we distribute full source code,
right?

-- 
  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 Tue Oct 19 17:59:06 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA21099
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 17:58:40 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA14366;
Tue, 19 Oct 1999 17:38:33 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910192138.RAA14366@candle.pha.pa.us>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <9237.940344241@sss.pgh.pa.us> from Tom Lane at "Oct 19,
1999 10:44:01 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 19 Oct 1999 17:38:33 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Here is something I read as part of the Alladin Ghostscript 6.0 beta
release. I must admit I don't understand the logic of the issue. It
seems the issue is that you can link non-GPL to GPL libraries, but you
can't distribute the result. Maybe it doesn't apply to us because we
don't copyright our code.

Huh? We certainly do --- or have you missed that
* Copyright (c) 1994, Regents of the University of California
that's plastered across all the source files?

Oh. I remember that now. :-)

The GPL does restrict the conditions under which GPL'd code can be
distributed; in particular it can't be distributed as part of a program
that is not all GPL'd (more or less --- I have not read the terms lately).
So, because we use BSD license rather than GNU, we cannot *include in
our distribution* any library that is under GPL.

But Alladin wasn't doing that either. They were just distributing
source code that could use readline, like we do.

Any end user who does not intend to redistribute the result can
certainly obtain our distribution and readline and build them together.
So it's no issue for source distributions, but I wonder about RPMs.
Our RPMs do not include the actual libreadline file, do they?

I think we dynamically load libreadline, which is OK, maybe.

Even though the GNU License (GPL) allows linking GPL'ed code (such as
the GNU readline library package) with non-GPL'ed code (such as all
the rest of Ghostscript) if one doesn't distribute the result, the
Free Software Foundation, creators of the GPL, have told us that in
their opinion, the GPL forbids distributing non-GPL'ed code that is
merely intended to be linked with GPL'ed code.

As stated, this is ridiculous on its face. The FSF has no possible
right to prevent the distribution of software that they didn't write
and that doesn't fall under the GPL.

Totally true, as far I an can figure. The US government stupidly tries
to do this under an existing export law. Don't know of any FSF laws.

Although I haven't been paying close attention to the Ghostscript
situation, I suspect that the real story is either that the readline
interface code that someone contributed to Ghostscript was contributed
with GPL terms already attached to it, or that Aladdin is concerned

Oh, that is an interesting issue that I never considered. Reminds us we
can't use GPL code.

about being able to distribute full-featured precompiled binaries of
Ghostscript. (BTW, Peter Deutsch has a history of forcing the issue
when he thinks that someone else is being unreasonable, and I suspect
that he's deliberately overreacting in hopes of making FSF change
their position.)

Good for him.

My inclination is to ignore the issue until and unless we hear a
complaint from the libreadline authors --- and if we do, we yank all
trace of readline support from psql. End of story.

Agreed.

-- 
  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 Tue Oct 19 17:59:04 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA21094
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 17:58:39 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA14388;
Tue, 19 Oct 1999 17:39:54 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910192139.RAA14388@candle.pha.pa.us>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <380C8672.6F2CA41@alumni.caltech.edu> from Thomas Lockhart at
"Oct
19, 1999 02:55:46 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Tue, 19 Oct 1999 17:39:54 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I think readline isn't our biggest problem. What about if
they notice that our parser can only be compiled when using
bison, and that we ship the generated output for the case
someone doesn't has bison installed?

afaik this is explicitly covered as "conforming behavior" in the GNU
license for bison. It was not always so, but the license for bison was
recently updated to allow distributing generated code.

I should point out that rms himself is on speaking terms with us; he
recently referred someone here to ask about Postgres vis a vis Oracle
compatibility. I'm pretty sure we are one of "the good guys" in Open
Source. ;)

Wait until you read my preface. It makes us sound like heros. Maybe we
are.

-- 
  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 Tue Oct 19 17:58:59 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA21080
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 17:58:31 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA14432;
Tue, 19 Oct 1999 17:42:28 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910192142.RAA14432@candle.pha.pa.us>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <9349.940345871@sss.pgh.pa.us> from Tom Lane at "Oct 19,
1999 11:11:11 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 19 Oct 1999 17:42:28 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yes, I head hear this. They basically said, "Our leverage isn't working."

As of Bison version 1.24, we have changed the distribution terms for
`yyparse' to permit using Bison's output in non-free programs.
Formerly, Bison parsers could be used only in programs that were free
software.

-- 
  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 Tue Oct 19 17:59:59 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA21279
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 17:59:38 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA14533;
Tue, 19 Oct 1999 17:45:54 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910192145.RAA14533@candle.pha.pa.us>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <Pine.GSO.3.96.991019182852.24574B-100000@enequist.csd.uu.se>
from
Peter Eisentraut at "Oct 19, 1999 06:34:32 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 19 Oct 1999 17:45:54 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 19 Oct 1999, Tom Lane wrote:

Huh? We certainly do --- or have you missed that
* Copyright (c) 1994, Regents of the University of California
that's plastered across all the source files?

Regarding which I have a question: at other locations I see (c) 1994-7
Univ. of California, or even (c) 1996-9 PostgreSQL Global Development
Team.

I am not an expert in any of this, but I'm just wondering: when did the
involvement of the U of C end, when was the Global Development Team (tm)
formed and do both copyrights exits in parallel? What if someone
contributes something really major and fairly independent (say like
pg_access) and wants to keep his own copyright (with compatible license of
course)?

And is the PostgreSQL Global Development Team any real entity that could
theoretically enforce that copyright or is it just an alias for "whoever
contributed"?

Now there's a good question. How long does the BSD imprint remain. I
assume forever. It is still on BSD/OS files. Only the ones they right
from scrath get a BSDI imprint.

-- 
  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 Tue Oct 19 17:56:59 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA20815
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 17:56:51 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA14602;
Tue, 19 Oct 1999 17:49:58 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910192149.RAA14602@candle.pha.pa.us>
Subject: Re: [HACKERS] psql Week 3
In-Reply-To: <Pine.LNX.4.10.9910192107580.981-100000@peter-e.yi.org> from
Peter
Eisentraut at "Oct 19, 1999 09:41:55 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 19 Oct 1999 17:49:58 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

For external reasons I didn't get as much done as I wanted. Originally, I
planned for 4 weeks and I think I can keep that.

The source is posted at http://www.pathwaynet.com/~peter/psql3.tar.gz

CHANGELOG
* Accommodated object descriptions in \d* commands.
* Re-wrote \dd
* Re-wrote \d "table"
* \pset command as generic way for setting printing options (e.g.,
\pset format html, \pset null "(null)")
* Proliferated use of const char * and enums
* Rewrote \di, \dt, \ds, \dS. Say hello to \dv for views, which are
now recognized correctly. You can also call, e.g., \dtvi for a list
of indices, tables, and views. The possibilities are endless ...
(where "endless" = 325)

Very cool. Nice new formats. Man, I will have to add them to this
book. I am going to have to have pre-7.0 psql backslash command
listings, and 7.0 backslash listings. This improvement is long overdue.
psql has always been one of our nifty features. It just got niftier.

-- 
  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 Tue Oct 19 18:13:59 1999
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA26070
for <hackers@postgreSQL.org>; Tue, 19 Oct 1999 18:13:52 -0400 (EDT)
(envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max05-006.enterprise.net [194.72.197.6])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id XAA19079;
Tue, 19 Oct 1999 23:13:46 +0100 (GMT/BST)
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 XAA19501;
Tue, 19 Oct 1999 23:13:36 +0100
Message-Id: <199910192213.XAA19501@linda.lfix.co.uk>
X-Mailer: exmh version 2.0.2 2/24/98 (debian)
To: Zakkr <zakkr@zf.jcu.cz>
cc: Lamar Owen <lamar.owen@wgcr.org>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Need refresh on main page...
In-Reply-To: Message from Zakkr <zakkr@zf.jcu.cz> of "Tue,
19 Oct 1999 17:13:02 +0200."
<Pine.LNX.3.96.991019170258.22482A-100000@ara.zf.jcu.cz>
References: <Pine.LNX.3.96.991019170258.22482A-100000@ara.zf.jcu.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 19 Oct 1999 23:13:35 +0100
From: "Oliver Elphick" <olly@lfix.co.uk>

Zakkr wrote:

On Tue, 19 Oct 1999, Lamar Owen wrote:

Vince Vielhaber wrote:

Actually that's on our main page, which is just announcements. The news
page (Latest News on the menu bar) gets quite involved. Would someone
care to give me some updated text for that as well?

"RPM's for PostgreSQL 6.5.2 are now available, and shipped with RedHat
Linux version 6.1. Included in these RPMS:

Hmm RedHat, and for Debian (and people which needn't Hat for comp-work:-) ex
ists
package with 6.5.2?

The 6.5.2-2 packages for Debian have just been installed and should be on
the Debian mirrors within the next day. They are to be found in the
unstable ("potato") distribution at ftp.debian.org/debian/ (or mirrors)
as follows:

Binary packages for i386:
dists/potato/main/binary-i386/misc/postgresql_6.5.2-2.deb
dists/potato/main/binary-i386/misc/postgresql-client_6.5.2-2.deb
dists/potato/main/binary-i386/misc/postgresql-contrib_6.5.2-2.deb
dists/potato/main/binary-i386/libs/ecpg_6.5.2-2.deb
dists/potato/main/binary-i386/libs/postgresql-pl_6.5.2-2.deb
dists/potato/main/binary-i386/libs/libpgsql2_6.5.2-2.deb
dists/potato/main/binary-i386/devel/postgresql-dev_6.5.2-2.deb
dists/potato/main/binary-all/doc/postgresql-doc_6.5.2-2.deb
dists/potato/main/binary-all/misc/pgaccess_6.5.2-2.deb
dists/potato/main/binary-i386/libs/libpgtcl_6.5.2-2.deb
dists/potato/main/binary-i386/libs/libpgperl_6.5.2-2.deb
dists/potato/main/binary-i386/libs/python-pygresql_6.5.2-2.deb
dists/potato/main/binary-i386/libs/odbc-postgresql_6.5.2-2.deb
dists/potato/main/binary-i386/misc/postgresql-test_6.5.2-2.deb

Source package:
dists/potato/main/source/misc/postgresql_6.5.2.orig.tar.gz
dists/potato/main/source/misc/postgresql_6.5.2-2.diff.gz
dists/potato/main/source/misc/postgresql_6.5.2-2.dsc

Binary packages for other architectures should start to appear shortly;
substitute the appropriate architecture for `i386' in the above paths.

Standard caution:
Note that these packages are not part of the released stable Debian
distribution. They may have dependencies on other unreleased software,
or other instabilities. Please take care if you wish to install them.
The updates will eventually make their way into the next released Debian
distribution.

--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Commit thy way unto the LORD; trust also in him and
he shall bring it to pass." Psalms 37:5

From bouncefilter Tue Oct 19 18:33:59 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA29728
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 18:33:19 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id SAA15825;
Tue, 19 Oct 1999 18:20:52 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910192220.SAA15825@candle.pha.pa.us>
Subject: book status
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Tue, 19 Oct 1999 18:20:52 -0400 (EDT)
CC: paul.becker@awl.com
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

OK, yesterday I signed contracts from Addison, Wesley, Longman for a
book on PostgreSQL. I got approval from Marc, Thomas, Vadim, and Tom
Lane. I also sent them a resume which was approved by the core group.

I have redesigned the outline because some of the chapters were too
long, and have written about 30 pages so far. With the missing
chapters, it comes to 64 pages. I am waiting for some text from the
publisher, just stating that the book is being written under contract
for them, and I will make the book available in PDF and HTML formats on
the web as soon as possible.

I plan to add the PostgreSQL manual pages as an appendix to the book.

Yes, I am being payed for the book, at some future date. I realize
other developers are using PostgreSQL in their work or in consulting,
but this is a much more public involvement. All I can say is that I
have always been ready to throw money into the PostgreSQL project, and
will continue to do so when possible.

Can't wait for everyone to see it. Shouldn't be too long now. I will
post when it is ready.

---------------------------------------------------------------------------

BTW, where do people want the PDF and HTML files? My idea is to update
them every night.

FYI, I just cleaned up my PDF version. Seems that ps2pdf requires me to
use Latin1 font encoding, or all my fonts in the PDF file are bitmapped
fonts and not spline/curved fonts. This is mentioned in the ps2pdf
manual pages. I just never realized the LyX's default encoding is ASCII
and not Latin1.

Bitmapped fonts don't matter if you print out the PDF, but if you view
it on the screen, Adobe Acrobat Reader showed the text looking terrible.
Ghostview was much better at rendering the bitmapped fonts, but I am
sure there are many people who want to view the PDF file with Acrobat,
so I have that fixed. xpdf couldn't render the bitmapped fonts either.
I have switched to Palatino, and upgraded to Alladin Ghostscript
5.94beta, so the PDF problems people reported with the previous PDF
should be fixed now.

-- 
  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 Tue Oct 19 18:52:59 1999
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA33234
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 18:52:17 -0400 (EDT) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max04-072.enterprise.net
[194.72.196.192])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id XAA26643;
Tue, 19 Oct 1999 23:52:14 +0100 (GMT/BST)
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 XAA23345;
Tue, 19 Oct 1999 23:52:04 +0100
Message-Id: <199910192252.XAA23345@linda.lfix.co.uk>
X-Mailer: exmh version 2.0.2 2/24/98 (debian)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql Week 3
In-Reply-To: Message from Bruce Momjian <maillist@candle.pha.pa.us> of "Tue,
19 Oct 1999 17:49:58 EDT." <199910192149.RAA14602@candle.pha.pa.us>
References: <199910192149.RAA14602@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 19 Oct 1999 23:52:04 +0100
From: "Oliver Elphick" <olly@lfix.co.uk>

Bruce Momjian wrote:

For external reasons I didn't get as much done as I wanted. Originally, I
planned for 4 weeks and I think I can keep that.

The source is posted at http://www.pathwaynet.com/~peter/psql3.tar.gz

CHANGELOG
* Accommodated object descriptions in \d* commands.
* Re-wrote \dd
* Re-wrote \d "table"
* \pset command as generic way for setting printing options (e.g.,
\pset format html, \pset null "(null)")
* Proliferated use of const char * and enums
* Rewrote \di, \dt, \ds, \dS. Say hello to \dv for views, which are
now recognized correctly. You can also call, e.g., \dtvi for a list
of indices, tables, and views. The possibilities are endless ...
(where "endless" = 325)

Very cool. Nice new formats. Man, I will have to add them to this
book. I am going to have to have pre-7.0 psql backslash command
listings, and 7.0 backslash listings. This improvement is long overdue.
psql has always been one of our nifty features. It just got niftier.

My previous database experience was with PICK, where the data dictionaries
include an output format and the command language allows for column
formatting 'on the fly'. This is something that I have missed with
PostgreSQL, though I believe the SQL standard does not cover it.

What I would like would be the ability to attach a format to a column, so
that text could be truncated at 25 characters or floats lined up with a
specified number of decimal places. (May be we can already and I've missed
it?) I would particularly like to be able to do text wrapping within a
column and totalling of numeric columns:

-----+---------------------+--------
id | description | qty
-----+---------------------+--------
abc1 | text that rambles | 35.43
| on and on about |
| something or other |
def2 | more useless text | 2.00
hgf3 | and yet more text | 355.10
| to read |
-----+---------------------+--------
| | 392.53
-----+---------------------+--------
(3 rows)

Do you think there's any place for this in PostgreSQL? Perhaps it needs a
separate front-end tool.

--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Commit thy way unto the LORD; trust also in him and
he shall bring it to pass." Psalms 37:5

From bouncefilter Tue Oct 19 22:00:02 1999
Received: from binky.de.uu.net (binky.de.uu.net [192.76.144.28])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA56596
for <pgsql-general@postgresql.org>;
Tue, 19 Oct 1999 21:59:53 -0400 (EDT)
(envelope-from CHUETTL@ahorn.sgh.uunet.de)
Received: from huettl (pec-19-1.tnt2.b.uunet.de [149.225.19.1])
by binky.de.uu.net (5.5.5/5.5.5) with ESMTP id DAA00135
for <pgsql-general@postgresql.org>;
Wed, 20 Oct 1999 03:59:22 +0200 (MET DST)
Received: from Spooler by huettl (Mercury/32 v2.16); 20 Oct 99 04:00:25 +0200
Received: from spooler by ahorn.sgh.uunet.de (Mercury/32 v2.16);
20 Oct 99 01:01:31 +0200
From: "Carsten Huettl" <CHUETTL@ahorn.sgh.uunet.de>
Organization: ahorn.Net
To: pgsql-general@postgresql.org, pgsql-novice@postgresql.org,
jim@reptiles.org (Jim Mercer)
Date: Wed, 20 Oct 1999 01:01:24 +0200
Subject: Re: [GENERAL] ld.so failed
Priority: normal
In-reply-to: <m11c7sz-00080dC@mailbox.reptiles.org>
References: <111F0F713069@ahorn.sgh.uunet.de> from Carsten Huettl at "Oct 15,
99 06:21:11 am"
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-ID: <6CF4B3E5928@ahorn.sgh.uunet.de>

From: jim@reptiles.org (Jim Mercer)
Subject: Re: [GENERAL] ld.so failed
To: CHUETTL@ahorn.sgh.uunet.de (Carsten Huettl)
Date sent: Fri, 15 Oct 1999 09:59:09 -0400 (EDT)
Copies to: hitesh@presys.com, pgsql-general@postgresql.org

you can make the change permanent by adding the path to the ldconfig
parameter int /etc/rc.conf.

How do I make this permanent if I need the "-aout" option with
ldconfig ?

C.

--
Carsten Huettl - <http://www.ahorn-Net.de&gt;
pgp-key on request

From bouncefilter Tue Oct 19 19:09:00 1999
Received: from genisys.gtv.ca (h-207-228-97-106.gen.cadvision.com
[207.228.97.106]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA35590
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 19:08:24 -0400 (EDT) (envelope-from aaron@gtv.ca)
Received: from stilborne (h-207-228-97-110.gen.cadvision.com [207.228.97.110])
by genisys.gtv.ca (8.9.3/8.8.7) with SMTP id RAA23837;
Tue, 19 Oct 1999 17:10:24 -0600
From: "Aaron J. Seigo" <aaron@gtv.ca>
To: "Oliver Elphick" <olly@lfix.co.uk>,
Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] psql Week 3
Date: Tue, 19 Oct 1999 17:06:12 -0600
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
References: <199910192149.RAA14602@candle.pha.pa.us>
<199910192252.XAA23345@linda.lfix.co.uk>
In-Reply-To: <199910192252.XAA23345@linda.lfix.co.uk>
MIME-Version: 1.0
Message-Id: <9910191707360E.00654@stilborne>
Content-Transfer-Encoding: 8bit

hi...

What I would like would be the ability to attach a format to a column, so
that text could be truncated at 25 characters or floats lined up with a
specified number of decimal places. (May be we can already and I've missed
it?) I would particularly like to be able to do text wrapping within a
column and totalling of numeric columns:

i miss this from oracle as well...

Do you think there's any place for this in PostgreSQL? Perhaps it needs a
separate front-end tool.

psql would seem the proper place for this?

--
Aaron J. Seigo
Sys Admin

From bouncefilter Tue Oct 19 19:20:00 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA38018
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 19:19:43 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id TAA17036;
Tue, 19 Oct 1999 19:10:04 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910192310.TAA17036@candle.pha.pa.us>
Subject: Re: [HACKERS] psql Week 3
In-Reply-To: <199910192252.XAA23345@linda.lfix.co.uk> from Oliver Elphick at
"Oct 19, 1999 11:52:04 pm"
To: Oliver Elphick <olly@lfix.co.uk>
Date: Tue, 19 Oct 1999 19:10:04 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Very cool. Nice new formats. Man, I will have to add them to this
book. I am going to have to have pre-7.0 psql backslash command
listings, and 7.0 backslash listings. This improvement is long overdue.
psql has always been one of our nifty features. It just got niftier.

My previous database experience was with PICK, where the data dictionaries
include an output format and the command language allows for column
formatting 'on the fly'. This is something that I have missed with
PostgreSQL, though I believe the SQL standard does not cover it.

I had that with Progress. Yes, it was handy.

What I would like would be the ability to attach a format to a column, so
that text could be truncated at 25 characters or floats lined up with a

char(25)?

specified number of decimal places. (May be we can already and I've missed

numeric(16,2)?

it?) I would particularly like to be able to do text wrapping within a
column and totalling of numeric columns:

-----+---------------------+--------
id | description | qty
-----+---------------------+--------
abc1 | text that rambles | 35.43
| on and on about |
| something or other |
def2 | more useless text | 2.00
hgf3 | and yet more text | 355.10
| to read |
-----+---------------------+--------
| | 392.53
-----+---------------------+--------
(3 rows)

Do you think there's any place for this in PostgreSQL? Perhaps it needs a
separate front-end tool.

That's a job for pgaccess. I thought it did stuff like that. If you
want printing like that, we need a report-writer, which is an important
application.

-- 
  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 Tue Oct 19 19:21:00 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA38320
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 19:20:28 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id TAA18133
for pgsql-hackers@postgreSQL.org; Tue, 19 Oct 1999 19:17:46 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910192317.TAA18133@candle.pha.pa.us>
Subject: book
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Tue, 19 Oct 1999 19:17:46 -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

OK, I have the needed text, and it is ready to go in both PDF and HTML.

Where do people want 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 19026

From bouncefilter Tue Oct 19 20:45:01 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA47382
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 20:43:59 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id UAA21251;
Tue, 19 Oct 1999 20:35:54 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910200035.UAA21251@candle.pha.pa.us>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <Pine.BSF.4.10.9910192133550.404-100000@thelab.hub.org> from The
Hermit Hacker at "Oct 19, 1999 09:35:56 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 19 Oct 1999 20:35:54 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

And is the PostgreSQL Global Development Team any real entity that could
theoretically enforce that copyright or is it just an alias for "whoever
contributed"?

Now there's a good question. How long does the BSD imprint remain. I
assume forever. It is still on BSD/OS files. Only the ones they right
from scrath get a BSDI imprint.

So, should we be extending the Date of the BSD license? Like, is there no
copyright *after* 1997? Or, can we do something like:

* Copyright (c) 1997-9
* PostgreSQL Global Development Team
* Copyright (c) 1994-7
* The Regents of the University of California. All rights reserved.

Beats me. BSDI stdio.h has:

/*-
* Copyright (c) 1990, 1993
* The Regents of the University of California. All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* Chris Torek.

-- 
  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 Tue Oct 19 20:41:01 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA46891
for <pgsql-hackers@postgresql.org>;
Tue, 19 Oct 1999 20:40:07 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA61199;
Tue, 19 Oct 1999 21:35:56 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 19 Oct 1999 21:35:56 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <199910192145.RAA14533@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910192133550.404-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Oct 1999, Bruce Momjian wrote:

On Tue, 19 Oct 1999, Tom Lane wrote:

Huh? We certainly do --- or have you missed that
* Copyright (c) 1994, Regents of the University of California
that's plastered across all the source files?

Regarding which I have a question: at other locations I see (c) 1994-7
Univ. of California, or even (c) 1996-9 PostgreSQL Global Development
Team.

I am not an expert in any of this, but I'm just wondering: when did the
involvement of the U of C end, when was the Global Development Team (tm)
formed and do both copyrights exits in parallel? What if someone
contributes something really major and fairly independent (say like
pg_access) and wants to keep his own copyright (with compatible license of
course)?

And is the PostgreSQL Global Development Team any real entity that could
theoretically enforce that copyright or is it just an alias for "whoever
contributed"?

Now there's a good question. How long does the BSD imprint remain. I
assume forever. It is still on BSD/OS files. Only the ones they right
from scrath get a BSDI imprint.

So, should we be extending the Date of the BSD license? Like, is there no
copyright *after* 1997? Or, can we do something like:

* Copyright (c) 1997-9
* PostgreSQL Global Development Team
* Copyright (c) 1994-7
* The Regents of the University of California. All rights reserved.

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 19 20:38:01 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA46560
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 20:37:10 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA61203;
Tue, 19 Oct 1999 21:37:24 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 19 Oct 1999 21:37:23 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] book
In-Reply-To: <199910192317.TAA18133@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910192137090.404-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Oct 1999, Bruce Momjian wrote:

OK, I have the needed text, and it is ready to go in both PDF and HTML.

Where do people want it?

Upcoming PostgreSQL Book section in our documentation?

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 19 20:43:01 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA47206
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 20:42:20 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id UAA21267;
Tue, 19 Oct 1999 20:37:45 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910200037.UAA21267@candle.pha.pa.us>
Subject: Re: [HACKERS] book
In-Reply-To: <Pine.BSF.4.10.9910192137090.404-100000@thelab.hub.org> from The
Hermit Hacker at "Oct 19, 1999 09:37:23 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Tue, 19 Oct 1999 20:37:45 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 19 Oct 1999, Bruce Momjian wrote:

OK, I have the needed text, and it is ready to go in both PDF and HTML.

Where do people want it?

Upcoming PostgreSQL Book section in our documentation?

Sounds good. Just under our existing docs in html and pdf format as a
new item in the list, or do you want a new 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 19026

From bouncefilter Tue Oct 19 21:06:01 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA50576
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 21:05:21 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA17075;
Wed, 20 Oct 1999 10:05:20 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id KAA23681;
Wed, 20 Oct 1999 10:05:19 +0900 (JST)
Message-Id: <199910200105.KAA23681@srapc451.sra.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Tue, 19 Oct 1999 10:17:06 -0400.
<9100.940342626@sss.pgh.pa.us>
Date: Wed, 20 Oct 1999 10:05:19 +0900
Sender: t-ishii@srapc451.sra.co.jp

Oh dear. I had tested it with smaller files and concluded that it was
no slower than before ... I guess there is some effect I'm not seeing
here. Can you tell whether the extra time is computation or I/O (how
much does the runtime of the backend change between old and new code)?

How can I do this? Maybe I should run the backend in stand alone mode?
---
Tatsuo Ishii

From bouncefilter Tue Oct 19 21:06:01 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA50584
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 21:05:26 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id KAA01715; Wed, 20 Oct 1999 10:05:14 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] mdnblocks is an amazing time sink in huge relations
Date: Wed, 20 Oct 1999 10:09:13 +0900
Message-ID: <000501bf1a97$b925a860$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To:
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

-----Original Message-----
From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
Sent: Tuesday, October 19, 1999 6:45 PM
To: Tom Lane
Cc: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] mdnblocks is an amazing time sink in huge
relations

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

[snip]

Deletion is necessary only not to consume disk space.

For example vacuum could remove not deleted files.

Hmm ... interesting idea ... but I can hear the complaints
from users already...

My idea is only an analogy of PostgreSQL's simple recovery
mechanism of tuples.

And my main point is
"delete fails after commit" doesn't harm the database
except that not deleted files consume disk space.

Of cource,it's preferable to delete relation files immediately
after(or just when) commit.
Useless files are visible though useless tuples are invisible.

Anyway I don't need "DROP TABLE inside transactions" now
and my idea is originally for that issue.

After a thought,I propose the following solution.

1. mdcreate() couldn't create existent relation files.
If the existent file is of length zero,we would overwrite
the file.(seems the comment in md.c says so but the
code doesn't do so).
If the file is an Index relation file,we would overwrite
the file.

2. mdunlink() couldn't unlink non-existent relation files.
mdunlink() doesn't call elog(ERROR) even if the file
doesn't exist,though I couldn't find where to change
now.
mdopen() doesn't call elog(ERROR) even if the file
doesn't exist and leaves the relation as CLOSED.

Comments ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Oct 20 04:58:06 1999
Received: from unknown (225.pool.atl800.gw.eni.net [155.229.7.225])
by hub.org (8.9.3/8.9.3) with SMTP id EAA18972;
Wed, 20 Oct 1999 04:57:03 -0400 (EDT)
(envelope-from art123@visto.com)
From: art123@visto.com
Subject: laser printer toner advertisement
Date: Wed, 20 Oct 1999 01:23:46
Message-Id: <249.870636.450199@>
To: undisclosed-recipients:;

BENCHMARK SUPPLY
7540 BRIDGEGATE COURT
ATLANTA GA 30350

***LASER PRINTER TONER CARTRIDGES***
***FAX AND COPIER TONER***

CHECK OUT OUR NEW CARTRIDGE PRICES :

APPLE

LASER WRITER PRO 600 OR 16/600 $69
LASER WRITER SELECT 300,310.360 $69
LASER WRITER 300, 320 $54
LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54
LASER WRITER 12/640 $79

HEWLETT PACKARD

LASERJET SERIES 2,3 & 3D (95A) $49
LASERJET SERIES 2P AND 3P (75A) $54
LASERJET SERIES 3SI AND 4SI (91A) $75
LASERJET SERIES 4L AND 4P $49
LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59
LASERJET SERIES 4000 HIGH YIELD (27X) $99
LASERJET SERIES 4V $95
LASERJET SERIES 5SI , 8000 $95
LASERJET SERIES 5L AND 6L $49
LASERJET SERIES 5P, 5MP, 6P, 6MP $59
LASERJET SERIES 5000 (29A) $135
LASERJET SERIES 1100 (92A) $49
LASERJET SERIES 2100 (96A) $89
LASERJET SERIES 8100 (82X) $145

HP LASERFAX

LASERFAX 500, 700, FX1, $59
LASERFAX 5000, 7000, FX2, $59
LASERFAX FX3 $69
LASERFAX FX4 $79

LEXMARK

OPTRA 4019, 4029 HIGH YIELD $135
OPTRA R, 4039, 4049 HIGH YIELD $135
OPTRA S 4059 HIGH YIELD $135
OPTRA E $59
OPTRA N $115

EPSON

EPL-7000, 8000 $105
EPL-1000, 1500 $105

CANON

LBP-430 $49
LBP-460, 465 $59
LBP-8 II $54
LBP-LX $54
LBP-MX $95
LBP-AX $49
LBP-EX $59
LBP-SX $49
LBP-BX $95
LBP-PX $49
LBP-WX $95
LBP-VX $59
CANON FAX L700 THRU L790 FX1 $59
CANONFAX L5000 L70000 FX2 $59

CANON COPIERS

PC 20, 25 ETC.... $89
PC 3, 6RE, 7, 11 (A30) $69
PC 320 THRU 780 (E40) $89

NEC

SERIES 2 LASER MODEL 90,95 $105

PLEASE NOTE:

1) ALL OUR CARTRIDGES ARE GENUINE OEM CARTRIDGES.
2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS
3) WE DO NOT FAX QUOTES OR PRICE LISTS.
4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS
5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS
6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS
7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES
8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES
9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS

WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS
JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS

****OUR ORDER LINE IS 770-399-0953 ****

****OUR CUSTOMER SERVICE LINE IS 800-586-0540****
****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-532-7170****

****PLACE YOUR ORDER AS FOLLOWS**** :

BY PHONE 770-399-0953

BY FAX: 770-698-9700
BY MAIL: BENCHMARK PRINT SUPPLY
7540 BRIDGEGATE COURT
, ATLANTA GA 30350

MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER:

1) YOUR PHONE NUMBER
2) COMPANY NAME
3) SHIPPING ADDRESS
4) YOUR NAME
5) ITEMS NEEDED WITH QUANTITIES
6) METHOD OF PAYMENT. (COD OR CREDIT CARD)
7) CREDIT CARD NUMBER WITH EXPIRATION DATE

1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING.
2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST.
2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS.
3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS
4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS.

NOTE NUMBER (1):

PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL
ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD
YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR
COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS
WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE
HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND
COMPLAINT LINE TO DO THAT.

NOTE NUMBER (2):

OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY
QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL
RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT
THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER
OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR
CUSTOMER SERCICE LINE.

NOTE NUMBER (3):

OWNERS OF ANY OF THE DOMAINS THAT APPEAR IN THE HEADER OF
THIS MESSAGE,ARE IN NO WAY ASSOCIATED WITH, PROMOTING,
DISTRIBUTING OR ENDORSING ANY OF THE PRODUCTS ADVERTISED
HEREIN AND ARE NOT LIABLE TO ANY CLAIMS THAT MAY ARISE
THEREOF.

From bouncefilter Tue Oct 19 21:30:01 1999
Received: from thelab.hub.org (nat203.183.mpoweredpc.net [142.177.203.183])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA53324
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 21:29:08 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA61836;
Tue, 19 Oct 1999 22:29:17 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 19 Oct 1999 22:29:16 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] book
In-Reply-To: <199910200037.UAA21267@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910192229080.404-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Oct 1999, Bruce Momjian wrote:

On Tue, 19 Oct 1999, Bruce Momjian wrote:

OK, I have the needed text, and it is ready to go in both PDF and HTML.

Where do people want it?

Upcoming PostgreSQL Book section in our documentation?

Sounds good. Just under our existing docs in html and pdf format as a
new item in the list, or do you want a new section?

Former sounds good to me :)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Tue Oct 19 22:06:01 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id WAA57543
for <hackers@postgresql.org>; Tue, 19 Oct 1999 22:05:30 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 2264 invoked by uid 1001); 20 Oct 1999 02:05:33 -0000
Message-ID: <XFMail.991019220533.vev@michvhf.com>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Tue, 19 Oct 1999 22:05:33 -0400 (EDT)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: hackers@postgresql.org
Subject: current_time?

Now I thought this was discussed recently and this:

create table foo(
x int,
y datetime default current_time);

would put the current date and time into y whenever a new record was
inserted. It appears to give the date and time the stupid table was
created. Is it me or is something broke?

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Tue Oct 19 22:29:02 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA60726
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 22:28:31 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id KAA25022;
Wed, 20 Oct 1999 10:28:25 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380D28C7.15948078@krs.ru>
Date: Wed, 20 Oct 1999 10:28:23 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: pgsql-hackers@postgreSQL.org, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
References: <000801bf1a19$2d88ae20$2801007e@cadzone.tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hiroshi Inoue wrote:

I supposed that each backend will still use own catalog
cache (after reading entries from shared one) and synchronize
shared/private caches on commit - e.g. update reltuples!
relpages will be updated immediately after physical changes -
what's problem with this?

Does this mean the following ?

1. shared cache holds committed system tuples.
2. private cache holds uncommitted system tuples.
3. relpages of shared cache are updated immediately by
phisical change and corresponding buffer pages are
marked dirty.
4. on commit, the contents of uncommitted tuples except
relpages,reltuples,... are copied to correponding tuples

^^^^^^^^^
reltuples in shared catalog cache (SCC) will be updated!
If transaction inserted some tuples then SCC->reltuples
will be incremented, etc.

in shared cache and the combined contents are
committed.

If so,catalog cache invalidation would be no longer needed.

I never liked our invalidation code -:)

But synchronization of the step 4. may be difficult.

What's easy in this life? -:)

Vadim

From bouncefilter Tue Oct 19 22:38:02 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA61931
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 22:37:25 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id KAA25169;
Wed, 20 Oct 1999 10:34:03 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380D2A1A.6429E512@krs.ru>
Date: Wed, 20 Oct 1999 10:34:02 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: peter_e@gmx.net, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: New developer globe
References: <m11dXR5-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Wieck wrote:

Also I think putting the photos below the globe (at least in addition)
might be better because for people digging around in Europe or the North
American east coast it obscures too much and it's also hard to get an
overview.

I could turn the text in the pages body into a table and add
the images there too. But I absolutely like them in the popup
and will let them in.

Me too.

Vadim

From bouncefilter Tue Oct 19 23:48:03 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA70582
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 23:47:28 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id LAA27141;
Wed, 20 Oct 1999 11:47:18 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380D3B43.110ABE52@krs.ru>
Date: Wed, 20 Oct 1999 11:47:16 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
References: <9036.940342155@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

I think the main problem is that relpages and reltuples shouldn't
be kept in pg_class columns at all, because they need to have
very different update behavior from the other pg_class columns.

Yes, but is this reason to move them somewhere else?
Let's update them differently (i.e. update in-place)
but keep in pg_class.
Should we provide read consistency for these internal-use columns?
I'm not sure.

If we want to take reltuples seriously and try to maintain it
on-the-fly, then I think it needs still a third behavior. Clearly

...snip...
I agreed that there is no way to get accurate estimation for
# of rows to be seen by a query...
Well, let's keep up-to-date # of rows present in relation:
in any case a query will have to read them and this is what
we need to estimate cost of simple scans, as for costs of
joins - now way, currently(?) -:(

But please remember that there is another SCC goal -
faster catalog access...

Vadim

From bouncefilter Tue Oct 19 23:59:03 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA71974
for <pgsql-hackers@postgreSQL.org>;
Tue, 19 Oct 1999 23:58:04 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id XAA04714;
Tue, 19 Oct 1999 23:57:44 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910200357.XAA04714@candle.pha.pa.us>
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
In-Reply-To: <380D3B43.110ABE52@krs.ru> from Vadim Mikheev at "Oct 20,
1999 11:47:16 am"
To: Vadim Mikheev <vadim@krs.ru>
Date: Tue, 19 Oct 1999 23:57:44 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I agreed that there is no way to get accurate estimation for
# of rows to be seen by a query...
Well, let's keep up-to-date # of rows present in relation:
in any case a query will have to read them and this is what
we need to estimate cost of simple scans, as for costs of
joins - now way, currently(?) -:(

But please remember that there is another SCC goal -
faster catalog access...

I want to index access more cache entries on cache miss for 7.0.

-- 
  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 Wed Oct 20 00:09:03 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA76143
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 00:09:02 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by trends.net (8.8.8/8.8.8) with ESMTP id AAA23660
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 00:01:27 -0400 (EDT)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id MAA27527;
Wed, 20 Oct 1999 12:01:15 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380D3E8B.DA5966C6@krs.ru>
Date: Wed, 20 Oct 1999 12:01:15 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
References: <199910200357.XAA04714@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

I agreed that there is no way to get accurate estimation for
# of rows to be seen by a query...
Well, let's keep up-to-date # of rows present in relation:
in any case a query will have to read them and this is what
we need to estimate cost of simple scans, as for costs of
joins - now way, currently(?) -:(

But please remember that there is another SCC goal -
faster catalog access...

I want to index access more cache entries on cache miss for 7.0.

Good. But in any case we'll gain faster access from _shared_ cache.

Vadim

From bouncefilter Wed Oct 20 00:09:03 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA76145
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 00:09:02 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by trends.net (8.8.8/8.8.8) with ESMTP id AAA23653
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 00:01:21 -0400 (EDT)
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 NAA01823; Wed, 20 Oct 1999 13:01:07 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Vadim Mikheev" <vadim@krs.ru>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] mdnblocks is an amazing time sink in huge relations
Date: Wed, 20 Oct 1999 13:05:06 +0900
Message-ID: <000701bf1ab0$4b3fc560$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <380D28C7.15948078@krs.ru>
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

Hiroshi Inoue wrote:

I supposed that each backend will still use own catalog
cache (after reading entries from shared one) and synchronize
shared/private caches on commit - e.g. update reltuples!
relpages will be updated immediately after physical changes -
what's problem with this?

Does this mean the following ?

1. shared cache holds committed system tuples.
2. private cache holds uncommitted system tuples.
3. relpages of shared cache are updated immediately by
phisical change and corresponding buffer pages are
marked dirty.
4. on commit, the contents of uncommitted tuples except
relpages,reltuples,... are copied to correponding tuples

^^^^^^^^^
reltuples in shared catalog cache (SCC) will be updated!
If transaction inserted some tuples then SCC->reltuples
will be incremented, etc.

System tuples are only modifiled or (insert and delet)ed like
user tuples when reltuples are updated ?
If only modified,we couldn't use it in SERIALIZABLE mode.

in shared cache and the combined contents are
committed.

If so,catalog cache invalidation would be no longer needed.

I never liked our invalidation code -:)

But synchronization of the step 4. may be difficult.

What's easy in this life? -:)

As for relpages(block count),my first thought was that
PostgreSQL relation files have their control data on their
first page, I was surprised to know there's no such data.

Seems catalog cache sharing is another issue as Tom
says. Of cource it's unnatural to hold separate catalog
cache.

I will be absent this week after now.
I would think for a while.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Oct 20 00:25:03 1999
Received: from mecomb.com (gw.mecomb.com [161.142.249.98])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA78569
for <pgsql-general@postgreSQL.org>;
Wed, 20 Oct 1999 00:24:12 -0400 (EDT)
(envelope-from lylyeoh@mecomb.com)
Received: (from mail@localhost) by mecomb.com (8.8.7/8.8.7) id MAA08458
for <pgsql-general@postgreSQL.org>; Wed, 20 Oct 1999 12:23:59 +0800
Received: from <lylyeoh@mecomb.com> (ilab2.mecomb.po.my [192.168.3.22]) by
ns.mecomb.com via smap (V2.1)
id xma008456; Wed, 20 Oct 99 12:23:57 +0800
Message-Id: <3.0.5.32.19991020122550.008bf780@pop.mecomb.po.my>
X-Sender: lylyeoh@pop.mecomb.po.my
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 20 Oct 1999 12:25:50 +0800
To: pgsql-general@postgreSQL.org
From: Lincoln Yeoh <lylyeoh@mecomb.com>
Subject: Re: [GENERAL] Postgres INSERTs much slower than MySQL?
In-Reply-To: <6CF4B3E5928@ahorn.sgh.uunet.de>
References: <m11c7sz-00080dC@mailbox.reptiles.org>
<111F0F713069@ahorn.sgh.uunet.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hi everyone,

Should inserts be so slow?

I've written a perl script to insert 10 million records for testing
purposes and it looks like it's going to take a LONG time with postgres.
MySQL is about 150 times faster! I don't have any indexes on either. I am
using the DBI and relevant DBD for both.

For Postgres 6.5.2 it's slow with either of the following table structures.
create table central ( counter serial, number varchar (12), name text,
address text );
create table central ( counter serial, number varchar (12), name
varchar(80), address varchar(80));

For MySQL I used:
create table central (counter int not null auto_increment primary key,
number varchar(12), name varchar(80), address varchar(80));

The relevant perl portion is (same for both):
$SQL=<<"EOT";
insert into central (number,name,address) values (?,?,?)
EOT
$cursor=$dbh->prepare($SQL);

while ($c<10000000) {
$number=$c;
$name="John Doe the number ".$c;
$address="$c, Jalan SS$c/$c, Petaling Jaya";
$rv=$cursor->execute($number,$name,$address) or die("Error executing
insert!",$DBI::errstr);
if ($rv==0) {
die("Error inserting a record with database!",$DBI::errstr);
};
$c++;
$d++;
if ($d>1000) {
print "$c\n";
$d=1;
}
}

From bouncefilter Wed Oct 20 00:31:04 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA79860
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 00:30:47 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id AAA11527;
Wed, 20 Oct 1999 00:29:36 -0400 (EDT)
To: Vadim Mikheev <vadim@krs.ru>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
In-reply-to: Your message of Wed, 20 Oct 1999 11:47:16 +0800
<380D3B43.110ABE52@krs.ru>
Date: Wed, 20 Oct 1999 00:29:36 -0400
Message-ID: <11525.940393776@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Vadim Mikheev <vadim@krs.ru> writes:

I agreed that there is no way to get accurate estimation for
# of rows to be seen by a query...
Well, let's keep up-to-date # of rows present in relation:
in any case a query will have to read them and this is what
we need to estimate cost of simple scans, as for costs of
joins - now way, currently(?) -:(

The optimizer is perfectly happy with approximate tuple counts. It has
to make enough other guesstimates that I really doubt an exact tuple
count could help it measurably. So updating the count via VACUUM is an
appropriate solution as far as the optimizer is concerned. The only
good reason I've ever seen for trying to keep an exact tuple count at
all times is to allow short-circuiting of SELECT COUNT(*) queries ---
and even there, it's only useful if there's no WHERE or GROUP BY.

As far as I can see, keeping an exact tuple count couldn't possibly
be worth the overhead it'd take. Keeping an exact block count may
have the same problem, but I'm not sure either way.

regards, tom lane

From bouncefilter Wed Oct 20 00:32:03 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA79864
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 00:30:57 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id MAA28322;
Wed, 20 Oct 1999 12:30:41 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380D456E.B99A7CF8@krs.ru>
Date: Wed, 20 Oct 1999 12:30:38 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
References: <000701bf1ab0$4b3fc560$2801007e@cadzone.tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hiroshi Inoue wrote:

Does this mean the following ?

1. shared cache holds committed system tuples.
2. private cache holds uncommitted system tuples.
3. relpages of shared cache are updated immediately by
phisical change and corresponding buffer pages are
marked dirty.
4. on commit, the contents of uncommitted tuples except
relpages,reltuples,... are copied to correponding tuples

^^^^^^^^^
reltuples in shared catalog cache (SCC) will be updated!
If transaction inserted some tuples then SCC->reltuples
will be incremented, etc.

System tuples are only modifiled or (insert and delet)ed like
user tuples when reltuples are updated ?
If only modified,we couldn't use it in SERIALIZABLE mode.

^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
...this...

I'm not sure that we must provide read consistency
for internal-use columns...
Nevertheless, I agreed that keeping internal-use columns
in table is bad thing, but let's do it for awhile: I believe
that someday we'll re-implement our mdmgr - using separate
file for each table/index is bad thing too, - and move these
columns "somewhere else" in that day.

Vadim

From bouncefilter Wed Oct 20 00:54:04 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA83107
for <hackers@postgreSQL.org>; Wed, 20 Oct 1999 00:53:36 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id AAA11689;
Wed, 20 Oct 1999 00:52:33 -0400 (EDT)
To: Vince Vielhaber <vev@michvhf.com>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] current_time?
In-reply-to: Your message of Tue, 19 Oct 1999 22:05:33 -0400 (EDT)
<XFMail.991019220533.vev@michvhf.com>
Date: Wed, 20 Oct 1999 00:52:32 -0400
Message-ID: <11687.940395152@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Vince Vielhaber <vev@michvhf.com> writes:

Now I thought this was discussed recently and this:
create table foo(
x int,
y datetime default current_time);
would put the current date and time into y whenever a new record was
inserted. It appears to give the date and time the stupid table was
created. Is it me or is something broke?

The behavior for this was changed very recently. Since current sources
refuse the above:

regression=> create table foo(
regression-> x int,
regression-> y datetime default current_time);
ERROR: Attribute 'y' is of type 'datetime' but default expression is of type 'time'
You will need to rewrite or cast the expression

I am guessing you are trying it with 6.5.*, where indeed you will likely
get the time of table creation. Recommended approach is
y datetime default now()
which works the way you want in all Postgres versions AFAIK.

Next question is whether current sources are broken to refuse the above.
Since I get

regression=> create table zz (x datetime);
CREATE
regression=> insert into zz values(current_time);
ERROR: Attribute 'x' is of type 'datetime' but expression is of type 'time'
You will need to rewrite or cast the expression

it seems I managed to make default-expression handling consistent
with the rest of the system, but that doesn't necessarily mean this
behavior is desirable... Thomas, what say you?

regards, tom lane

From bouncefilter Wed Oct 20 01:13:04 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA85433
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 01:12:36 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA11736;
Wed, 20 Oct 1999 01:11:53 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>, paul.becker@awl.com
Subject: Re: [HACKERS] book status
In-reply-to: Your message of Tue, 19 Oct 1999 18:20:52 -0400 (EDT)
<199910192220.SAA15825@candle.pha.pa.us>
Date: Wed, 20 Oct 1999 01:11:53 -0400
Message-ID: <11734.940396313@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Yes, I am being payed for the book, at some future date. I realize
other developers are using PostgreSQL in their work or in consulting,
but this is a much more public involvement. All I can say is that I
have always been ready to throw money into the PostgreSQL project, and
will continue to do so when possible.

Since you'll be doing the bulk of the work that is specific to the book,
I can't see any reason to object to you being the one getting paid for
it. Many (most?) of us are using Postgres for work purposes, or
otherwise deriving some kind of personal/corporate/proprietary benefit
from it. A book project based on Postgres seems no different to me
from the money my company hopes to make from running a Postgres-based
application. Indeed, this book project is considerably more likely
to return tangible benefit to the Postgres group (in the form of new
users/contributors attracted to the project) than most other ways
people might be using Postgres to make money.

In short, you needn't offer the slightest apology for collecting the
book royalties personally. From what I've heard of the book-writing
biz, you're unlikely to get rich off it anyway :-(

Since I didn't see any howls of outrage on the mailing list, I imagine
everyone else thinks the same anyway, but if you need some reassurance
these are my two cents.

BTW, where do people want the PDF and HTML files? My idea is to update
them every night.

Stick 'em on the website/ftpsite somewhere under the docs page. I'd
probably gripe if I found them getting pulled as part of the regular CVS
source module --- those updates are slow enough already --- but if you
want to keep them in CVS I suppose a separate CVS module could be set up.

regards, tom lane

From bouncefilter Wed Oct 20 01:32:04 1999
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA87754
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 01:31:16 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id FAA24900;
Wed, 20 Oct 1999 05:27:29 GMT
Sender: lockhart@hub.org
Message-ID: <380D52C1.D1BF4F23@alumni.caltech.edu>
Date: Wed, 20 Oct 1999 05:27:29 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: Bruce Momjian <maillist@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
References: <Pine.BSF.4.10.9910192133550.404-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Huh? We certainly do --- or have you missed that
* Copyright (c) 1994, Regents of the University of California
that's plastered across all the source files?

Regarding which I have a question: at other locations I see (c) 1994-7
Univ. of California, or even (c) 1996-9 PostgreSQL Global Development
Team.
I am not an expert in any of this, but I'm just wondering: when did the
involvement of the U of C end, when was the Global Development Team (tm)
formed and do both copyrights exits in parallel? What if someone
contributes something really major and fairly independent (say like
pg_access) and wants to keep his own copyright (with compatible license of
course)?

I'm the one who started slapping new copyright notices around (in the
docs, mostly). imho UCB's involvement ended when they released source
code, with copyright provisions designed to retain acknowledgement of
their work while releasing them from any liability resulting from any
and all uses of the code.

We certainly *can't* simply extend UCB's copyright dates, since they
are not involved in that process. imo we *should* apply a new
copyright which enforces UCB's original provisions, which are designed
to keep the code in play while deflecting liability.

And is the PostgreSQL Global Development Team any real entity that could
theoretically enforce that copyright or is it just an alias for "whoever
contributed"?

Now there's a good question. How long does the BSD imprint remain. I
assume forever. It is still on BSD/OS files. Only the ones they right
from scrath get a BSDI imprint.

We'll decide if PostgreSQL Global Development Team is a real entity
for copyright purposes when we need to ;) Really, the BSD-style
license has *no* restrictions, so what are we going to enforce? But we
*should* put some mention of things in the code to avoid cases like
the idiot American yahoo who tried to lay claim to "linux".

So, should we be extending the Date of the BSD license? Like, is there no
copyright *after* 1997? Or, can we do something like:
* Copyright (c) 1997-9
* PostgreSQL Global Development Team
* Copyright (c) 1994-7
* The Regents of the University of California. All rights reserved.

I'm not a lawyer, and I don't even play one on TV. But y'all can't
extend a UCB copyright arbitrarily. We're a work derived from the
original Berkeley distribution, and we are complying with the UCB
copyright in all respects afaik. What happens after that is up to us,
not UCB...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Wed Oct 20 01:49:06 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA89479
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 01:48:22 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA11775;
Wed, 20 Oct 1999 01:47:36 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-reply-to: Your message of Tue, 19 Oct 1999 18:34:32 +0200 (MET DST)
<Pine.GSO.3.96.991019182852.24574B-100000@enequist.csd.uu.se>
Date: Wed, 20 Oct 1999 01:47:36 -0400
Message-ID: <11773.940398456@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <e99re41@csd.uu.se> writes:

Regarding which I have a question: at other locations I see (c) 1994-7
Univ. of California, or even (c) 1996-9 PostgreSQL Global Development
Team.

I am not an expert in any of this, but I'm just wondering: when did the
involvement of the U of C end, when was the Global Development Team (tm)
formed and do both copyrights exits in parallel?

Judging from the historical messages recently posted, Berkeley had
control of the code up to about '96. I suppose '94 was the last major
release made from Berkeley. (Another Berkeley project that I've been
involved with, Ptolemy, has always made a point of updating its
copyright boilerplate to current year just before each major release.
Perhaps the Postgres guys were less punctilious about copyright dates,
but anyway it's clearly been several years since Berkeley was in
charge.)

If we were really doing this with full legal care, we'd probably have
something like this in every source file:

* Copyright (c) 1986-1994
* The Regents of the University of California. All rights reserved.
* Copyright (c) 1996-1999
* PostgreSQL Global Development Team

(or whatever the exact date ranges should be). The Berkeley copyright
will never lapse as long as there is visible Berkeley heritage in the
code, but the Postgres group can also claim copyright on the
modifications and additions we've made. As long as we are happy with
distributing our work under the BSD license terms, there's no conflict.

Now a lawyer would immediately point out that the "PostgreSQL Global
Development Team" is not a legally existent entity and so has no ability
to sue anyone for copyright violation. If we thought we might have to
enforce our wishes legally, we'd need to form an actual corporation.
(Perhaps the core team has already quietly done that, but I sure don't
know about it...)

What if someone contributes something really major and fairly
independent (say like pg_access) and wants to keep his own copyright
(with compatible license of course)?

I've noticed that Jan and a couple of other people have put copyright
notices in their own names on files that they've created from scratch,
but I feel uncomfortable with that practice. The Ghostscript/readline
fiasco illustrates the potential problems you can get into with
divergent copyrights on chunks of code that need to be distributed
together. My personal feeling is that if you're a member of the team,
stick the team copyright on it; don't open a can of legal worms.

(If we were building in a green field it might be profitable to debate
what that team copyright should be --- but unless we want to start from
scratch, BSD is it, for better or worse.)

Disclaimer: I'm not a lawyer, I don't play one on TV, yadda yadda...

regards, tom lane

From bouncefilter Wed Oct 20 01:59:05 1999
Received: from kiln.isn.net (root@kiln.isn.net [198.167.161.1])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA90903
for <pgsql-general@postgreSQL.org>;
Wed, 20 Oct 1999 01:58:46 -0400 (EDT)
(envelope-from ctassell@isn.net)
Received: from niki (ryan06.isn.net [198.167.161.76])
by kiln.isn.net (8.9.3/8.9.3) with SMTP id DAA29588;
Wed, 20 Oct 1999 03:04:31 -0300
Message-Id: <4.1.19991020025131.009949b0@mailer.isn.net>
X-Sender: ctassell@mailer.isn.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Wed, 20 Oct 1999 02:56:56 -0300
To: Lincoln Yeoh <lylyeoh@mecomb.com>, pgsql-general@postgreSQL.org
From: Charles Tassell <ctassell@isn.net>
Subject: Re: [GENERAL] Postgres INSERTs much slower than MySQL?
In-Reply-To: <3.0.5.32.19991020122550.008bf780@pop.mecomb.po.my>
References: <6CF4B3E5928@ahorn.sgh.uunet.de>
<m11c7sz-00080dC@mailbox.reptiles.org>
<111F0F713069@ahorn.sgh.uunet.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Try turning off Autocommit: MySQL doesn't support transactions, so that
might be what's causing the speed boost. Just change the connect line from:
$pg_con=DBI->connect("DBI:Pg:....
to
$pg_con=DBI->connect("DBI:Pg(AutoCommit=>0):....

and add

$pg_con->commit

before you disconnect. I may have the syntax wrong, so double check the
docs for the DBI and PG modules (perldoc DBD::Pg and perldoc DBI)

At 01:25 AM 10/20/99, Lincoln Yeoh wrote:

Hi everyone,

Should inserts be so slow?

I've written a perl script to insert 10 million records for testing
purposes and it looks like it's going to take a LONG time with postgres.
MySQL is about 150 times faster! I don't have any indexes on either. I am
using the DBI and relevant DBD for both.

For Postgres 6.5.2 it's slow with either of the following table structures.
create table central ( counter serial, number varchar (12), name text,
address text );
create table central ( counter serial, number varchar (12), name
varchar(80), address varchar(80));

For MySQL I used:
create table central (counter int not null auto_increment primary key,
number varchar(12), name varchar(80), address varchar(80));

The relevant perl portion is (same for both):
$SQL=<<"EOT";
insert into central (number,name,address) values (?,?,?)
EOT
$cursor=$dbh->prepare($SQL);

while ($c<10000000) {
$number=$c;
$name="John Doe the number ".$c;
$address="$c, Jalan SS$c/$c, Petaling Jaya";
$rv=$cursor->execute($number,$name,$address) or die("Error executing
insert!",$DBI::errstr);
if ($rv==0) {
die("Error inserting a record with database!",$DBI::errstr);
};
$c++;
$d++;
if ($d>1000) {
print "$c\n";
$d=1;
}
}

************

From bouncefilter Wed Oct 20 02:11:04 1999
Received: from ns1.aktrad.ru (ns1.aktrad.ru [195.218.140.4])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA92702
for <pgsql-hackers@postgresql.org>;
Wed, 20 Oct 1999 02:10:52 -0400 (EDT) (envelope-from hook@aktrad.ru)
Received: from sloth (sloth.aktrad.ru [195.218.140.13])
by ns1.aktrad.ru (8.9.3/8.9.3) with SMTP id KAA60690
for <pgsql-hackers@postgresql.org>;
Wed, 20 Oct 1999 10:10:20 +0400 (MSD)
Message-ID: <0a2001bf1ac1$bf46c600$0d8cdac3@aktrad.ru>
From: "Gene Sokolov" <hook@aktrad.ru>
To: <pgsql-hackers@postgresql.org>
Subject: Creating operators
Date: Wed, 20 Oct 1999 10:09:58 +0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211

Since no one replied in pg-general, I am reposting to hackers.

Q1:
Let's say I want to create a '+' operator for <my own type> + int4. Do I
really have to
define two '+' operators, one

<my own type> + int

and the other

int + <my own type>

Q2:

Can I create an operator '::', such as <my own type>::double ?

Gene Sokolov.

From bouncefilter Wed Oct 20 02:18:05 1999
Received: from volcano.DEFUDATA.DK ([195.97.164.2])
by hub.org (8.9.3/8.9.3) with SMTP id CAA93609
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 02:18:00 -0400 (EDT) (envelope-from kar@webline.dk)
Received: from VOLCANO [195.97.164.2] (HELO localhost)
by volcano.DEFUDATA.DK (AltaVista Mail V2.0J/2.0J BL25J listener)
id 0000_00fe_380d_5e89_33b8; Wed, 20 Oct 1999 08:17:45 +0200
Message-ID: <380D5E80.981103BE@webline.dk>
Date: Wed, 20 Oct 1999 08:17:37 +0200
From: Kaare Rasmussen <kar@webline.dk>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] book status
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

application. Indeed, this book project is considerably more likely
to return tangible benefit to the Postgres group (in the form of new
users/contributors attracted to the project) than most other ways
people might be using Postgres to make money.

Exactly! No need to apologize for attracting attention to PostgreSQL.

In short, you needn't offer the slightest apology for collecting the
book royalties personally. From what I've heard of the book-writing
biz, you're unlikely to get rich off it anyway :-(

And if you do get rich, you can retire and spend all your time on
enhancements to PostgreSQL :-)

From bouncefilter Wed Oct 20 02:54:06 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA97721
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 02:53:06 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id CAA12036;
Wed, 20 Oct 1999 02:51:53 -0400 (EDT)
To: "Gene Sokolov" <hook@aktrad.ru>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Creating operators
In-reply-to: Your message of Wed, 20 Oct 1999 10:09:58 +0400
<0a2001bf1ac1$bf46c600$0d8cdac3@aktrad.ru>
Date: Wed, 20 Oct 1999 02:51:53 -0400
Message-ID: <12034.940402313@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Gene Sokolov" <hook@aktrad.ru> writes:

Q1:
Let's say I want to create a '+' operator for <my own type> + int4. Do I
really have to
define two '+' operators, one
<my own type> + int
and the other
int + <my own type>

Yes. There's nothing compelling them to behave the same, after all
(consider '-' instead of '+'). If they do behave the same you
should indicate this with "commutator" links --- see the discussion
in the manual.

Can I create an operator '::', such as <my own type>::double ?

You can't redefine the meaning of the typecast construct '::',
if that's what you meant. But perhaps what you really meant
was that you want to provide a conversion from your type to
double. For that you just make a function named 'double',
yielding double, and taking your type as input. The typecast
code will use it automatically.

(Of course "double" is spelled "float8" in Postgres-land,
but you knew that...)

regards, tom lane

From bouncefilter Wed Oct 20 03:11:05 1999
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 DAA03775
for <pgsql-hackers@postgresql.org>;
Wed, 20 Oct 1999 03:10:32 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11dptC-000LTL-0K; Wed, 20 Oct 1999 07:10:26 +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 JAA26341;
Wed, 20 Oct 1999 09:18:05 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5LW7>; Wed, 20 Oct 1999 08:08:18 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E729@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <maillist@candle.pha.pa.us>, PostgreSQL-development
<pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] Readline use in trouble?
Date: Wed, 20 Oct 1999 08:08:15 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

Tom wrote:

[snip]

I've noticed that Jan and a couple of other people have put copyright
notices in their own names on files that they've created from scratch,
but I feel uncomfortable with that practice. The Ghostscript/readline
fiasco illustrates the potential problems you can get into with
divergent copyrights on chunks of code that need to be distributed
together. My personal feeling is that if you're a member of the team,
stick the team copyright on it; don't open a can of legal worms.

I agree with you. I'm not sure if there are anything like this in the
jdbc or contrib/lo stuff saying my copyright, but if there is, feel free
to change it to the team's copyright - I tend to run in autopilot when
it comes to adding copyrights.

Saying that, I'm doubtful that all of the JDBC source has a copyright
notice of any kind in there. I'll trawl my copy of the source to see if
this is the case.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

From bouncefilter Wed Oct 20 04:19:06 1999
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 EAA13462
for <hackers@postgreSQL.org>; Wed, 20 Oct 1999 04:18:53 -0400 (EDT)
(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 JAA04365;
Wed, 20 Oct 1999 09:09:48 +0200
Date: Wed, 20 Oct 1999 09:09:47 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: Oliver Elphick <olly@lfix.co.uk>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Need refresh on main page...
In-Reply-To: <199910192213.XAA19501@linda.lfix.co.uk>
Message-ID: <Pine.LNX.3.96.991020090141.2664B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Oct 1999, Oliver Elphick wrote:

The 6.5.2-2 packages for Debian have just been installed and should be on
the Debian mirrors within the next day. They are to be found in the
unstable ("potato") distribution at ftp.debian.org/debian/ (or mirrors)
as follows:

Thank! (I'm installing it now.)

------------------------------------------------------------------------------
<zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/

Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
------------------------------------------------------------------------------
...and cathedral dilapidate

From bouncefilter Wed Oct 20 03:15:05 1999
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 DAA04026
for <pgsql-hackers@postgresql.org>;
Wed, 20 Oct 1999 03:14:37 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11dpxE-000M2n-0K; Wed, 20 Oct 1999 07:14:36 +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 JAA26351;
Wed, 20 Oct 1999 09:22:15 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5LW8>; Wed, 20 Oct 1999 08:12:27 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E72A@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Bruce Momjian'" <maillist@candle.pha.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] Readline use in trouble?
Date: Wed, 20 Oct 1999 08:12:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

Bruce wrote:

[snip]

Although I haven't been paying close attention to the Ghostscript
situation, I suspect that the real story is either that the readline
interface code that someone contributed to Ghostscript was

contributed

with GPL terms already attached to it, or that Aladdin is concerned

Oh, that is an interesting issue that I never considered. Reminds us

we

can't use GPL code.

That was why when I merged Adrian's and my JDBC drivers for inclusion, I
used Adrians as the core, and re-wrote the additions I made to mine to
it, as mine was GPL'ed, and his wasn't.

Just a thought: How does this affect anything placed in the contrib
directory? If someone writes a tool under the GPL, can it be included
under the src/contrib directory, or would we fall foul just because it's
included with our source?

I don't think we have a problem with the CD distribution, as they are
clearly separate, but contrib is not that clear cut.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

From bouncefilter Wed Oct 20 03:20:05 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA04672
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 03:19:21 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id PAA02567;
Wed, 20 Oct 1999 15:12:39 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380D6B63.9E7A158@krs.ru>
Date: Wed, 20 Oct 1999 15:12:35 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
References: <11525.940393776@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Vadim Mikheev <vadim@krs.ru> writes:

I agreed that there is no way to get accurate estimation for
# of rows to be seen by a query...
Well, let's keep up-to-date # of rows present in relation:
in any case a query will have to read them and this is what
we need to estimate cost of simple scans, as for costs of
joins - now way, currently(?) -:(

The optimizer is perfectly happy with approximate tuple counts. It has
to make enough other guesstimates that I really doubt an exact tuple
count could help it measurably. So updating the count via VACUUM is an
appropriate solution as far as the optimizer is concerned. The only

I'm not sure: scans read all (visible/unvisible, committed/uncommittd)
tuples before making visibility decision... though, relpages is
primary value for cost estimation.

good reason I've ever seen for trying to keep an exact tuple count at
all times is to allow short-circuiting of SELECT COUNT(*) queries ---
and even there, it's only useful if there's no WHERE or GROUP BY.

...and only in READ COMMITTED mode...

As far as I can see, keeping an exact tuple count couldn't possibly
be worth the overhead it'd take. Keeping an exact block count may
have the same problem, but I'm not sure either way.

relpages is more significant thing to know. Extending relation
by one block at time is bad for insert performance. It would be nice
to have two values per relation in shared cache - # of blocks and
last block used. On the other hand this is mostly mdmgr issue.

But in any case, it seems to me that using shmem for
shared catalog cache is much worther than for
shared cache invalidation...

Vadim

From bouncefilter Wed Oct 20 03:38:05 1999
Received: from frr101.hub.de (frr101.hub.de [192.125.20.67])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA08059
for <pgsql-hackers@postgresql.org>;
Wed, 20 Oct 1999 03:37:58 -0400 (EDT)
(envelope-from gerd@fru19.hub.de)
Received: from fru19.hub.de (fru19.hub.de [192.125.18.42])
by frr101.hub.de (8.9.3/8.9.3) with ESMTP id JAA26801
for <pgsql-hackers@postgresql.org>;
Wed, 20 Oct 1999 09:34:33 -0600 (MDT)
Received: (from gerd@localhost) by fru19.hub.de (8.9.3/8.9.3) id JAA00369
for pgsql-hackers@postgresql.org; Wed, 20 Oct 1999 09:36:55 +0200
From: Gerd Thielemann AEK <gerd@fru19.hub.de>
Message-Id: <199910200736.JAA00369@fru19.hub.de>
Subject:
To: pgsql-hackers@postgresql.org
Date: Wed, 20 Oct 1999 09:36:55 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL47 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

unsubscribe

From bouncefilter Wed Oct 20 03:37:05 1999
Received: from mecomb.com (gw.mecomb.com [161.142.249.98])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA07977
for <pgsql-general@postgreSQL.org>;
Wed, 20 Oct 1999 03:36:52 -0400 (EDT)
(envelope-from lylyeoh@mecomb.com)
Received: (from mail@localhost) by mecomb.com (8.8.7/8.8.7) id PAA10324;
Wed, 20 Oct 1999 15:36:49 +0800
Received: from <lylyeoh@mecomb.com> (ilab2.mecomb.po.my [192.168.3.22]) by
ns.mecomb.com via smap (V2.1)
id xma010320; Wed, 20 Oct 99 15:36:19 +0800
Message-Id: <3.0.5.32.19991020153812.008c4620@pop.mecomb.po.my>
X-Sender: lylyeoh@pop.mecomb.po.my
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 20 Oct 1999 15:38:12 +0800
To: Charles Tassell <ctassell@isn.net>, pgsql-general@postgreSQL.org
From: Lincoln Yeoh <lylyeoh@mecomb.com>
Subject: Re: [GENERAL] Postgres INSERTs much slower than MySQL?
In-Reply-To: <4.1.19991020025131.009949b0@mailer.isn.net>
References: <3.0.5.32.19991020122550.008bf780@pop.mecomb.po.my>
<6CF4B3E5928@ahorn.sgh.uunet.de>
<m11c7sz-00080dC@mailbox.reptiles.org>
<111F0F713069@ahorn.sgh.uunet.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Thanks.

It's now a lot faster. Now only about 5 or so times slower. Cool.

But it wasn't unexpected that I got the following after a while ;).

NOTICE: BufferAlloc: cannot write block 990 for joblist/central

NOTICE: BufferAlloc: cannot write block 991 for joblist/central
DBD::Pg::st execute failed: NOTICE: BufferAlloc: cannot write block 991
for joblist/central
Error executing insert!NOTICE: BufferAlloc: cannot write block 991 for
joblist/central
Database handle destroyed without explicit disconnect.

I don't mind that. I was actually waiting to see what would happen and
my jaw would have dropped if MVCC could handle Multi Versions with
10,000,000 records!

But the trouble is postgres seemed to behave strangely after that error.
The select count(*) from central took so long that I gave up. I tried drop
table central, and so far it hasn't dropped yet. Single record selects
still work tho.

Well next time I'll commit after a few thousand inserts. But still things
shouldn't lock up like that right? It's only inserted a few more thousand
records to the 50000 to 60000 records stage, so it's not a big table I'm
dealing with.

I cancelled the drop, killed postmaster (nicely), restarted it and tried
vacuuming. Vacuuming found some errors, but now it has got stuck too:
NOTICE: Index central_counter_key: pointer to EmptyPage (blk 988 off 52) -
fixing
NOTICE: Index central_counter_key: pointer to EmptyPage (blk 988 off 53) -
fixing
Then nothing for the past 5 minutes.

Looks like I may have to manually clean things up with good ol rm. <sigh>.
Not an urgent problem since this shouldn't happen in production.

By the way, the 999,999th record has been inserted into MySQL already. It's
pretty good at the rather limited stuff it does.

But Postgres' MVCC thing sounds real cool. Not as cool as a 10MegaRecord
MVCC would be tho <grin>.

Must try screwing up Oracle one of these days. I'm pretty good at messing
things up ;).

Cheerio,

Link.

At 02:56 AM 20-10-1999 -0300, Charles Tassell wrote:

Try turning off Autocommit: MySQL doesn't support transactions, so that
might be what's causing the speed boost. Just change the connect line from:
$pg_con=DBI->connect("DBI:Pg:....
to
$pg_con=DBI->connect("DBI:Pg(AutoCommit=>0):....

and add

$pg_con->commit

before you disconnect. I may have the syntax wrong, so double check the
docs for the DBI and PG modules (perldoc DBD::Pg and perldoc DBI)

At 01:25 AM 10/20/99, Lincoln Yeoh wrote:

Hi everyone,

Should inserts be so slow?

I've written a perl script to insert 10 million records for testing
purposes and it looks like it's going to take a LONG time with postgres.
MySQL is about 150 times faster! I don't have any indexes on either. I am
using the DBI and relevant DBD for both.

For Postgres 6.5.2 it's slow with either of the following table structures.
create table central ( counter serial, number varchar (12), name text,
address text );
create table central ( counter serial, number varchar (12), name
varchar(80), address varchar(80));

For MySQL I used:
create table central (counter int not null auto_increment primary key,
number varchar(12), name varchar(80), address varchar(80));

The relevant perl portion is (same for both):
$SQL=<<"EOT";
insert into central (number,name,address) values (?,?,?)
EOT
$cursor=$dbh->prepare($SQL);

while ($c<10000000) {
$number=$c;
$name="John Doe the number ".$c;
$address="$c, Jalan SS$c/$c, Petaling Jaya";
$rv=$cursor->execute($number,$name,$address) or die("Error executing
insert!",$DBI::errstr);
if ($rv==0) {
die("Error inserting a record with database!",$DBI::errstr);
};
$c++;
$d++;
if ($d>1000) {
print "$c\n";
$d=1;
}
}

************

From bouncefilter Wed Oct 20 03:48:05 1999
Received: from pdm.pvt.net (qmailr@pdm.pvt.net [194.149.103.204])
by hub.org (8.9.3/8.9.3) with SMTP id DAA09211
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 03:47:26 -0400 (EDT) (envelope-from pdm@pvt.net)
Received: (qmail 5186 invoked by uid 1000); 20 Oct 1999 07:47:18 -0000
Sender: pdm@pdm.pvt.net
From: Milan Zamazal <mz@pdm.pvt.net>
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
References: <9237.940344241@sss.pgh.pa.us>
X-Face: #G'i>Q>~:^*=!qpsXTU;
iEZ8xcAz+u~Vq0(<P>a6!3ebS/2|\r{9&asz&Qp]~)uF,N"4,jS
T&F>.|='gO6:N<FD-e0EI5.+#BblSdQ!$7ZC'3m/6m4edq-E&nU+R%<!V&MXqR<W5RIISsd?Q6]Ig]
V4|Y_QsT/c$EX1WqSYQizlNDh,krFL=uX6OQU?N[wW(8'3[cMK$w
Date: 20 Oct 1999 09:47:17 +0200
In-Reply-To: Tom Lane's message of "Tue, 19 Oct 1999 10:44:01 -0400"
Message-ID: <87ln8yv5h6.fsf@pdm.pvt.net>
Lines: 27
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:

TL> The GPL does restrict the conditions under which GPL'd code can
TL> be distributed; in particular it can't be distributed as part of
TL> a program that is not all GPL'd (more or less --- I have not
TL> read the terms lately). So, because we use BSD license rather
TL> than GNU, we cannot *include in our distribution* any library
TL> that is under GPL.

[All IMHO, I'm not a lawyer etc. too.]

I think that from the point of GPL there is basically no problem with
PostgreSQL license, since it contains no restriction incompatible with
GPL.

The situation with Aladdin Ghostscript is quite different, it is under
non-free license, its license is in conflict with GPL and so it clearly
can't use GPLed code.

However, including GPLed code into PostgreSQL, though I think it's fully
legal, means that third party can't take the PostgreSQL as a whole and
distribute it under license violating GPL, e.g. as a proprietary product
without available sources. If it is important for you to support *more*
restrictive licensing than GPL, then you should avoid inclusion of GPLed
code into PostgreSQL.

Milan Zamazal

From bouncefilter Wed Oct 20 04:04:06 1999
Received: from pdm.pvt.net (qmailr@pdm.pvt.net [194.149.103.204])
by hub.org (8.9.3/8.9.3) with SMTP id EAA11038
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 04:03:19 -0400 (EDT) (envelope-from pdm@pvt.net)
Received: (qmail 5272 invoked by uid 1000); 20 Oct 1999 08:03:18 -0000
Sender: pdm@pdm.pvt.net
Original-Sender: pdm@debian.cz
From: Milan Zamazal <pdm@debian.cz>
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
References: <9237.940344241@sss.pgh.pa.us>
X-Face: #G'i>Q>~:^*=!qpsXTU;
iEZ8xcAz+u~Vq0(<P>a6!3ebS/2|\r{9&asz&Qp]~)uF,N"4,jS
T&F>.|='gO6:N<FD-e0EI5.+#BblSdQ!$7ZC'3m/6m4edq-E&nU+R%<!V&MXqR<W5RIISsd?Q6]Ig]
V4|Y_QsT/c$EX1WqSYQizlNDh,krFL=uX6OQU?N[wW(8'3[cMK$w
In-Reply-To: Tom Lane's message of "Tue, 19 Oct 1999 10:44:01 -0400"
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
Date: 20 Oct 1999 10:03:17 +0200
Message-ID: <87bt9uv4qi.fsf@pdm.pvt.net>
Lines: 27
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:

TL> The GPL does restrict the conditions under which GPL'd code can
TL> be distributed; in particular it can't be distributed as part of
TL> a program that is not all GPL'd (more or less --- I have not
TL> read the terms lately). So, because we use BSD license rather
TL> than GNU, we cannot *include in our distribution* any library
TL> that is under GPL.

[All IMHO, I'm not a lawyer etc. too.]

I think that from the point of GPL there is basically no problem with
PostgreSQL license, since it contains no restriction incompatible with
GPL.

The situation with Aladdin Ghostscript is quite different, it is under
non-free license, its license is in conflict with GPL and so it clearly
can't use GPLed code.

However, including GPLed code into PostgreSQL, though I think it's fully
legal, means that third party can't take the PostgreSQL as a whole and
distribute it under license violating GPL, e.g. as a proprietary product
without available sources. If it is important for you to support *more*
restrictive licensing than GPL, then you should avoid inclusion of GPLed
code into PostgreSQL.

Milan Zamazal

From bouncefilter Wed Oct 20 04:14:06 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA12343
for <pgsql-general@postgreSQL.org>;
Wed, 20 Oct 1999 04:13:14 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id QAA04317;
Wed, 20 Oct 1999 16:12:51 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380D7982.71DEF932@krs.ru>
Date: Wed, 20 Oct 1999 16:12:50 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Lincoln Yeoh <lylyeoh@mecomb.com>
CC: Charles Tassell <ctassell@isn.net>, pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Postgres INSERTs much slower than MySQL?
References: <3.0.5.32.19991020122550.008bf780@pop.mecomb.po.my>
<6CF4B3E5928@ahorn.sgh.uunet.de>
<m11c7sz-00080dC@mailbox.reptiles.org>
<111F0F713069@ahorn.sgh.uunet.de>
<3.0.5.32.19991020153812.008c4620@pop.mecomb.po.my>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lincoln Yeoh wrote:

It's now a lot faster. Now only about 5 or so times slower. Cool.

But it wasn't unexpected that I got the following after a while ;).

NOTICE: BufferAlloc: cannot write block 990 for joblist/central

NOTICE: BufferAlloc: cannot write block 991 for joblist/central
DBD::Pg::st execute failed: NOTICE: BufferAlloc: cannot write block 991
for joblist/central
Error executing insert!NOTICE: BufferAlloc: cannot write block 991 for
joblist/central
Database handle destroyed without explicit disconnect.

I don't mind that. I was actually waiting to see what would happen and
my jaw would have dropped if MVCC could handle Multi Versions with
10,000,000 records!

It doesn't seem as MVCC problem. MVCC uses transaction ids,
not tuple ones, and so should work with any number of rows
modified by concurrent transaction... In theory... -:))

Vadim

From bouncefilter Wed Oct 20 04:32:06 1999
Received: from mecomb.com (gw.mecomb.com [161.142.249.98])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA15725
for <pgsql-general@postgreSQL.org>;
Wed, 20 Oct 1999 04:31:29 -0400 (EDT)
(envelope-from lylyeoh@mecomb.com)
Received: (from mail@localhost) by mecomb.com (8.8.7/8.8.7) id QAA10703;
Wed, 20 Oct 1999 16:31:26 +0800
Received: from <lylyeoh@mecomb.com> (ilab2.mecomb.po.my [192.168.3.22]) by
ns.mecomb.com via smap (V2.1)
id xma010701; Wed, 20 Oct 99 16:31:25 +0800
Message-Id: <3.0.5.32.19991020163318.0087e140@pop.mecomb.po.my>
X-Sender: lylyeoh@pop.mecomb.po.my
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 20 Oct 1999 16:33:18 +0800
To: Vadim Mikheev <vadim@krs.ru>
From: Lincoln Yeoh <lylyeoh@mecomb.com>
Subject: Re: [GENERAL] Postgres INSERTs much slower than MySQL?
Cc: Charles Tassell <ctassell@isn.net>, pgsql-general@postgreSQL.org
In-Reply-To: <380D7982.71DEF932@krs.ru>
References: <3.0.5.32.19991020122550.008bf780@pop.mecomb.po.my>
<6CF4B3E5928@ahorn.sgh.uunet.de>
<m11c7sz-00080dC@mailbox.reptiles.org>
<111F0F713069@ahorn.sgh.uunet.de>
<3.0.5.32.19991020153812.008c4620@pop.mecomb.po.my>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:12 PM 20-10-1999 +0800, Vadim Mikheev wrote:

It doesn't seem as MVCC problem. MVCC uses transaction ids,
not tuple ones, and so should work with any number of rows
modified by concurrent transaction... In theory... -:))

OK. Dunno what I hit then. I wasn't modifying rows, I was inserting rows.

How many rows (blocks) can I insert before I have to do a commit?

Well anyway the Postgres inserts aren't so much slower if I only commit
once in a while. Only about 3 times slower for the first 100,000 records.
So the subject line is now inaccurate :). Not bad, I like it.

But to fix the resulting problem I had to manually rm the files related to
the table. I also dropped the database to make sure ;). That's not good.

Cheerio,

Link.

From bouncefilter Wed Oct 20 04:39:06 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA16383
for <pgsql-general@postgreSQL.org>;
Wed, 20 Oct 1999 04:38:55 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id QAA05124;
Wed, 20 Oct 1999 16:38:10 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380D7F71.F422AEC4@krs.ru>
Date: Wed, 20 Oct 1999 16:38:09 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Lincoln Yeoh <lylyeoh@mecomb.com>
CC: Charles Tassell <ctassell@isn.net>, pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Postgres INSERTs much slower than MySQL?
References: <3.0.5.32.19991020122550.008bf780@pop.mecomb.po.my>
<6CF4B3E5928@ahorn.sgh.uunet.de>
<m11c7sz-00080dC@mailbox.reptiles.org>
<111F0F713069@ahorn.sgh.uunet.de>
<3.0.5.32.19991020153812.008c4620@pop.mecomb.po.my>
<3.0.5.32.19991020163318.0087e140@pop.mecomb.po.my>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lincoln Yeoh wrote:

At 04:12 PM 20-10-1999 +0800, Vadim Mikheev wrote:

It doesn't seem as MVCC problem. MVCC uses transaction ids,
not tuple ones, and so should work with any number of rows
modified by concurrent transaction... In theory... -:))

OK. Dunno what I hit then. I wasn't modifying rows, I was inserting rows.

You hit buffer manager/disk manager problems or eat all disk space.
As for "modifying" - I meant insertion, deletion, update...

How many rows (blocks) can I insert before I have to do a commit?

Each transaction can have up to 2^32 commands.

Well anyway the Postgres inserts aren't so much slower if I only commit
once in a while. Only about 3 times slower for the first 100,000 records.
So the subject line is now inaccurate :). Not bad, I like it.

Hope that it will be much faster when WAL will be implemented...

Vadim

From bouncefilter Wed Oct 20 05:12:06 1999
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA21927
for <hackers@postgreSQL.org>; Wed, 20 Oct 1999 05:11:18 -0400 (EDT)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id NAA28717
for <hackers@postgreSQL.org>; Wed, 20 Oct 1999 13:11:00 +0400 (MSD)
Date: Wed, 20 Oct 1999 13:11:00 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: hackers@postgreSQL.org
Subject: enabling using index in ORDER BY ... desc
Message-ID: <Pine.GSO.3.96.SK.991020130118.8622S-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

What's the status of patch which enables using indices in
ORDER BY .../ desc ? I use it with 6.5.2 without any problem.
Will it come to upcoming 6.5.3 ?
It seems that it's already applied to current.

Regards,

Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

From bouncefilter Wed Oct 20 05:38:07 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id FAA25498
for pgsql-hackers@postgresql.org; Wed, 20 Oct 1999 05:38:03 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: "HSBC" <@hkstar.com>
X-Newsgroups: alt.japanese.neojapan.hackers.swpw,
alt.japanese.neojapan.hackintosh, alt.nl.binaries.hack,
clinet.list.freebsd-hackers, clinet.list.pgsql-hackers,
cn.bbs.comp.hacker, comp.databases.postgresql.hackers,
es.comp.hackers, fa.freebsd.hackers, fido7.hacker, f
Subject: How to hack Chris Jones Encryption Algorithmn
Date: Wed, 20 Oct 1999 17:27:43 +0800
Organization: HSBC
Lines: 11
Message-ID: <7uk29r$j231@imsp212.netvigator.com>
X-Newsreader: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
To: pgsql-hackers@postgresql.org

Is there anyone knows how to hack 'Chris Jones' Encryption algorithmn or,
whether there are softwares for hacking the key/algorithmn of 'Chris Jones
Encryption'?

Thanks.

Peter

From bouncefilter Wed Oct 20 06:01:07 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id GAA28294
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 06:00:27 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11dsTS-0003kLC; Wed, 20 Oct 99 11:56 MET DST
Message-Id: <m11dsTS-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Readline use in trouble?
To: petermount@it.maidstone.gov.uk (Peter Mount)
Date: Wed, 20 Oct 1999 11:56:01 +0200 (MET DST)
Cc: tgl@sss.pgh.pa.us, maillist@candle.pha.pa.us, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To:
<1B3D5E532D18D311861A00600865478C25E729@exchange1.nt.maidstone.gov.uk>
from "Peter Mount" at Oct 20, 99 08:08:15 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Peter Mount wrote:

Tom wrote:

[snip]

I've noticed that Jan and a couple of other people have put copyright
notices in their own names on files that they've created from scratch,
but I feel uncomfortable with that practice. The Ghostscript/readline
fiasco illustrates the potential problems you can get into with
divergent copyrights on chunks of code that need to be distributed
together. My personal feeling is that if you're a member of the team,
stick the team copyright on it; don't open a can of legal worms.

I agree with you. I'm not sure if there are anything like this in the
jdbc or contrib/lo stuff saying my copyright, but if there is, feel free
to change it to the team's copyright - I tend to run in autopilot when
it comes to adding copyrights.

Saying that, I'm doubtful that all of the JDBC source has a copyright
notice of any kind in there. I'll trawl my copy of the source to see if
this is the case.

Agreed. I consider anything in the CVS actually owned by the
team. I don't have the time, so if someone else would like
to, change all my copyright notices to the team.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Wed Oct 20 06:21:07 1999
Received: from meryl.csd.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA31437
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 06:20:13 -0400 (EDT)
(envelope-from e99re41@csd.uu.se)
Received: from cronstedt.csd.uu.se (e99re41@cronstedt.csd.uu.se
[130.238.15.73])
by meryl.csd.uu.se (8.8.5/8.8.5) with SMTP id MAA28555;
Wed, 20 Oct 1999 12:16:11 +0200 (MET DST)
Date: Wed, 20 Oct 1999 12:16:11 +0200 (MET DST)
From: Peter Eisentraut <e99re41@csd.uu.se>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Oliver Elphick <olly@lfix.co.uk>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] psql Week 3
In-Reply-To: <199910192252.XAA23345@linda.lfix.co.uk>
Message-ID: <Pine.GSO.3.96.991020120338.28782A-100000@cronstedt.csd.uu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Oct 1999, Oliver Elphick wrote:

My previous database experience was with PICK, where the data dictionaries
include an output format and the command language allows for column
formatting 'on the fly'. This is something that I have missed with
PostgreSQL, though I believe the SQL standard does not cover it.

Hmm. Well, the idea of keeping formatting data in the backend doesn't
sound too exciting to me. The data type already contains a fair amount of
formatting information in itself.

But psql is not supposed to be a report generator. It's also not a
typesetting engine. The idea was to sort of write a shell, but one that
doesn't use the OS kernel but a database server.

What I would like would be the ability to attach a format to a column, so
that text could be truncated at 25 characters or floats lined up with a
specified number of decimal places. (May be we can already and I've missed

Okay, lining up floats is sort of on the wish list (as distinct from todo
list). I'll keep that in mind.

it?) I would particularly like to be able to do text wrapping within a
column and totalling of numeric columns:

Wrapping text also seemed like a nice idea to me, but psql is supposed to
be a query interpreter. Wrapping text is a whole different animal and
there are specialty programs out there for that.

And totalling numeric columns is the job of a report generator. All psql
does is send a query and output the results, and it wants to make that job
as fun as possible along the way. It doesn't know anything about what's in
the query results. That is probably an important line to keep.

-----+---------------------+--------
id | description | qty
-----+---------------------+--------
abc1 | text that rambles | 35.43
| on and on about |
| something or other |
def2 | more useless text | 2.00
hgf3 | and yet more text | 355.10
| to read |
-----+---------------------+--------
| | 392.53
-----+---------------------+--------
(3 rows)

Do you think there's any place for this in PostgreSQL? Perhaps it needs a
separate front-end tool.

I hear pg_access has a report generator. If you want a text-based report
generator, then you're seemingly on your own.

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Wed Oct 20 06:35:07 1999
Received: from meryl.csd.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA33447
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 06:34:11 -0400 (EDT)
(envelope-from e99re41@csd.uu.se)
Received: from cronstedt.csd.uu.se (e99re41@cronstedt.csd.uu.se
[130.238.15.73])
by meryl.csd.uu.se (8.8.5/8.8.5) with SMTP id MAA29297;
Wed, 20 Oct 1999 12:26:31 +0200 (MET DST)
Date: Wed, 20 Oct 1999 12:26:30 +0200 (MET DST)
From: Peter Eisentraut <e99re41@csd.uu.se>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <11773.940398456@sss.pgh.pa.us>
Message-ID: <Pine.GSO.3.96.991020121846.28782B-100000@cronstedt.csd.uu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 20 Oct 1999, Tom Lane wrote:

If we were really doing this with full legal care, we'd probably have
something like this in every source file:

* Copyright (c) 1986-1994
* The Regents of the University of California. All rights reserved.
* Copyright (c) 1996-1999
* PostgreSQL Global Development Team

That's what I thought. Perhaps one should also add to the actual copyright
notice, that, besides that U of C, no member of the PostgreSQL Global
Development Team will assume any liability for nuttin', etc.

Now a lawyer would immediately point out that the "PostgreSQL Global
Development Team" is not a legally existent entity and so has no ability
to sue anyone for copyright violation. If we thought we might have to
enforce our wishes legally, we'd need to form an actual corporation.
(Perhaps the core team has already quietly done that, but I sure don't
know about it...)

What about Pgsql, Inc.? Perhaps they should trademark the product name and
act as the legal guardian. Isn't that sort of what the Apache Software
Foundation does?

Of course, I don't recall the project being in legal trouble lately, but
who knows how fast it can happen. The FSF could get anal, or [commercial
db vendor] files senseless claims, or [joe idiot] trademarks "PostgreSQL",
etc. Once you're in the spotlight, the weirdos come out. And we want to be
in the spotlight, don't we?

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Wed Oct 20 06:48:07 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id GAA35403
for <hackers@postgreSQL.org>; Wed, 20 Oct 1999 06:47:36 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 3205 invoked by uid 1001); 20 Oct 1999 10:47:36 -0000
Date: Wed, 20 Oct 1999 06:47:36 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] current_time?
In-Reply-To: <11687.940395152@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.05.9910200643370.3080-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 20 Oct 1999, Tom Lane wrote:

Vince Vielhaber <vev@michvhf.com> writes:

Now I thought this was discussed recently and this:
create table foo(
x int,
y datetime default current_time);
would put the current date and time into y whenever a new record was
inserted. It appears to give the date and time the stupid table was
created. Is it me or is something broke?

The behavior for this was changed very recently. Since current sources
refuse the above:

regression=> create table foo(
regression-> x int,
regression-> y datetime default current_time);
ERROR: Attribute 'y' is of type 'datetime' but default expression is of type 'time'
You will need to rewrite or cast the expression

I am guessing you are trying it with 6.5.*, where indeed you will likely
get the time of table creation. Recommended approach is
y datetime default now()
which works the way you want in all Postgres versions AFAIK.

This works. I had tried something earlier (during the thread a couple
weeks back) DEFAULT TEXT 'now' which didn't work at all for me. A
little playing and I just now figured out why it didn't work.. When I
tried that I had y as a text field - which only put a 'now' in it so I
was avoiding using now under the assumption that it wouldn't work.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Wed Oct 20 06:56:08 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id GAA36939
for <pgsql-hackers@postgresql.org>;
Wed, 20 Oct 1999 06:55:32 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 3223 invoked by uid 1001); 20 Oct 1999 10:55:32 -0000
Date: Wed, 20 Oct 1999 06:55:32 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>, paul.becker@awl.com
Subject: Re: [HACKERS] book status
In-Reply-To: <11734.940396313@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.05.9910200654270.3080-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 20 Oct 1999, Tom Lane wrote:

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Yes, I am being payed for the book, at some future date. I realize
other developers are using PostgreSQL in their work or in consulting,
but this is a much more public involvement. All I can say is that I
have always been ready to throw money into the PostgreSQL project, and
will continue to do so when possible.

Since you'll be doing the bulk of the work that is specific to the book,
I can't see any reason to object to you being the one getting paid for
it. Many (most?) of us are using Postgres for work purposes, or
otherwise deriving some kind of personal/corporate/proprietary benefit
from it. A book project based on Postgres seems no different to me
from the money my company hopes to make from running a Postgres-based
application. Indeed, this book project is considerably more likely
to return tangible benefit to the Postgres group (in the form of new
users/contributors attracted to the project) than most other ways
people might be using Postgres to make money.

In short, you needn't offer the slightest apology for collecting the
book royalties personally. From what I've heard of the book-writing
biz, you're unlikely to get rich off it anyway :-(

Since I didn't see any howls of outrage on the mailing list, I imagine
everyone else thinks the same anyway, but if you need some reassurance
these are my two cents.

Well put Tom. Couldn't have said it better.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Wed Oct 20 07:24:08 1999
Received: from meryl.csd.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA41520
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 07:23:04 -0400 (EDT)
(envelope-from e99re41@csd.uu.se)
Received: from cronstedt.csd.uu.se (e99re41@cronstedt.csd.uu.se
[130.238.15.73])
by meryl.csd.uu.se (8.8.5/8.8.5) with SMTP id NAA01775;
Wed, 20 Oct 1999 13:10:38 +0200 (MET DST)
Date: Wed, 20 Oct 1999 13:10:38 +0200 (MET DST)
From: Peter Eisentraut <e99re41@csd.uu.se>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <maillist@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <380D52C1.D1BF4F23@alumni.caltech.edu>
Message-ID: <Pine.GSO.3.96.991020130844.28782E-100000@cronstedt.csd.uu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 20 Oct 1999, Thomas Lockhart wrote:

We'll decide if PostgreSQL Global Development Team is a real entity
for copyright purposes when we need to ;) Really, the BSD-style

At least the Global Development Team was entity enough to register the
domain postgresql.org:

Registrant:
PostgreSQL Global Development Group (POSTGRESQL-DOM)
203-112 Highland Ave
Wolfville, Nova Scotia B0P 1X0
CA

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Wed Oct 20 07:16:08 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id HAA40705
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 07:15:29 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 3258 invoked by uid 1001); 20 Oct 1999 11:15:30 -0000
Date: Wed, 20 Oct 1999 07:15:30 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>,
Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <11773.940398456@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.05.9910200709200.3080-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 20 Oct 1999, Tom Lane wrote:

Now a lawyer would immediately point out that the "PostgreSQL Global
Development Team" is not a legally existent entity and so has no ability
to sue anyone for copyright violation. If we thought we might have to
enforce our wishes legally, we'd need to form an actual corporation.
(Perhaps the core team has already quietly done that, but I sure don't
know about it...)

I don't know how things work in Canada - where Marc is - but in the US
a simple DBA would be all that's necessary for an entity to copyright
in their own name. Many clubs and user groups do this regularly. A
form that's filled out every five years is all that's needed to maintain
the business name. (DBA = Doing Business As)

Disclaimer: I'm not a lawyer, I don't play one on TV, yadda yadda...

Same here, but I have filed and received a copyright for one of the
above unmentioned clubs when I was a member.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Wed Oct 20 08:52:09 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA59062
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 08:51:55 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id MAA25444;
Wed, 20 Oct 1999 12:51:15 GMT
Sender: lockhart@hub.org
Message-ID: <380DBAC2.42BAC78C@alumni.caltech.edu>
Date: Wed, 20 Oct 1999 12:51:14 +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: Gene Sokolov <hook@aktrad.ru>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Creating operators
References: <12034.940402313@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Can I create an operator '::', such as <my own type>::double ?

This brings up something: I see mention in Date and Darwen of an SQL3
enumerated type. Nice feature, but they show the syntax being:

<type>::<value>

which reuses the "::" operator in a way which may be incompatible with
Postgres' usage (seems to me to have the fields reversed). btw, I
could imagine implementing enumerated types as Postgres arrays or as a
separate table per type.

Has anyone come across this SQL3 feature yet? Any opinions??

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Wed Oct 20 09:11:09 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA61509
for <hackers@postgresql.org>; Wed, 20 Oct 1999 09:10:41 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id NAA25505;
Wed, 20 Oct 1999 13:10:03 GMT
Sender: lockhart@hub.org
Message-ID: <380DBF2B.6D1DC13C@alumni.caltech.edu>
Date: Wed, 20 Oct 1999 13:10: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: "B.V.Dean" <B.V.Dean@ukc.ac.uk>, Lamar Owen <lamar.owen@wgcr.org>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: PostgreSQL Perl Module
References: <19657.940409781@pelican.ukc.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have downloaded and installed your packaged RPM for the Pg.pm module for
PostgreSQL 6.5.1 on RedHat 6.0 i386 linux and cannot be found by perl.
Is my problem unique? When I run a perl script with 'use Pg;' in it I get:
Can't locate Pg.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .) at ../src/Perl/pg.pl line 1.
BEGIN failed--compilation aborted at ../src/Perl/pg.pl line 1.
The Pg.pm has been installed into:
/usr/lib/perl5/site_perl

I haven't had the chance to use much perl in the last year or two, but
it may be that the default @INC does not include the directories we
used for the installation. Also, the RPMs were generated on a RH5.2
system, which may have a slightly different configuration.

On my RH5.2 system, I have the following INC paths:

perl -e 'foreach $i (@INC) { printf "$i\n" }'

/usr/lib/perl5/i386-linux/5.00405
/usr/lib/perl5
/usr/lib/perl5/site_perl/i386-linux
/usr/lib/perl5/site_perl
.

And the RPM puts files in:

[root@golem i386]# rpm -qlp postgresql-perl-6.5.1-2.i386.rpm
/usr/lib/perl5/man/man3/Pg.3
/usr/lib/perl5/site_perl/Pg.pm
/usr/lib/perl5/site_perl/auto/Pg
/usr/lib/perl5/site_perl/auto/Pg/autosplit.ix
/usr/lib/perl5/site_perl/i386-linux/auto
/usr/lib/perl5/site_perl/i386-linux/auto/Pg
/usr/lib/perl5/site_perl/i386-linux/auto/Pg/Pg.bs
/usr/lib/perl5/site_perl/i386-linux/auto/Pg/Pg.so

which seems to be consistant. One thing you can try is to add
/usr/lib/perl5/site_perl to INC at the top of your program and see if
that helps. Try:

unshift(@INC, "/usr/lib/perl5/site_perl");
...

One of the problems with generating RPMs is that unless you have more
than one machine you can't *really* test how they behave, but need
others to try them out.

btw, it would probably be better to focus on new RPMs posted on
ftp://postgresql.org/pub/RPMS/ (and elsewhere), generated by Lamar
Owens who has taken over the RPM development and maintenance. These
include RPMs generated specifically for RH6.0, but Lamar had just put
out a request for someone to test the RH6.1-generated RPMs on a RH6.0
machine to see if they are compatible. If you have time, I'm sure he
would appreciate trying that out.

Good luck.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Wed Oct 20 09:50:09 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA66534
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 09:49:50 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id NAA25552;
Wed, 20 Oct 1999 13:45:48 GMT
Sender: lockhart@hub.org
Message-ID: <380DC78C.6B2173B5@alumni.caltech.edu>
Date: Wed, 20 Oct 1999 13:45: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: Peter Eisentraut <peter_e@gmx.net>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
References: <Pine.GSO.3.96.991020121846.28782B-100000@cronstedt.csd.uu.se>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id JAA66809

something like this in every source file:
* Copyright (c) 1986-1994
* The Regents of the University of California. All rights reserved.
* Copyright (c) 1996-1999
* PostgreSQL Global Development Team

That's what I thought. Perhaps one should also add to the actual copyright
notice, that, besides that U of C, no member of the PostgreSQL Global
Development Team will assume any liability for nuttin', etc.

Here is what we already have in the docs:

(from http://www.postgresql.org/docs/postgres/copyright.htm)

Copyrights and Trademarks

PostgreSQL is Copyright � 1996-9 by the PostgreSQL Global Development
Group, and is distributed under the terms of the Berkeley license.

Postgres95 is Copyright � 1994-5 by the Regents of the University of
California. Permission to use, copy, modify, and distribute this
software and its documentation for any purpose, without fee, and
without a written agreement is hereby granted, provided that the above
copyright notice and this paragraph and the following two paragraphs
appear in all copies.

In no event shall the University of California be liable to any party
for direct, indirect, special, incidental, or consequential damages,
including lost profits, arising out of the use of this software and
its documentation, even if the University of California has been
advised of the possibility of such damage.

The University of California specifically disclaims any warranties,
including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. The software
provided hereunder is on an "as-is" basis, and the University of
California has no obligations to provide maintainance, support,
updates, enhancements, or modifications.

I wrote the minimalist "me too" copyright notice as the first
paragraph above to avoid making claims or statements that the group
would find a problem. But istm that our copyright notice should
probably be a bit more wordy, perhaps mimicing the whole UCB copyright
statement. Comments?

Now a lawyer would immediately point out that the "PostgreSQL Global
Development Team" is not a legally existent entity and so has no ability
to sue anyone for copyright violation. If we thought we might have to
enforce our wishes legally, we'd need to form an actual corporation.
(Perhaps the core team has already quietly done that, but I sure don't
know about it...)

istm that we "operate" in more countries than most any real company,
and it would be prohibitive to preemptively file for legal status
everywhere it might matter. The copyright is intended to keep the code
available *and* to deflect liability; we only need to invoke it if
someone comes after us (maybe we'll all end up living with Marc on
some island in Canada, hiding from the US lawyers :) Perhaps it is
better to do The Right Thing developing software with an appropriate
copyright and leave the rest...

btw, Marc has already run into domain name pirates/speculators, who
snagged postgresql.com. They would be happy to sell the name back to
us :(((

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

From bouncefilter Wed Oct 20 10:00:10 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id KAA68214
for pgsql-hackers@postgresql.org; Wed, 20 Oct 1999 10:00:03 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
Message-ID: <380DCAB9.57EF8C4B@ncinter.net>
From: Intrac Systems Inc <intrac@ncinter.net>
Reply-To: intrac@ncinter.net
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
X-Newsgroups: comp.databases.postgresql.hackers
Subject: Re: [HACKERS] Readline use in trouble?
References: <87bt9uv4qi.fsf@pdm.pvt.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 60
X-Trace: typ11.nn.bcandid.com 940428000 208.1.141.134 (Wed,
20 Oct 1999 10:00:00 EDT)
Organization: bCandid - Powering the world's discussions - http://bCandid.com
Date: Wed, 20 Oct 1999 09:59:23 -0400
To: pgsql-hackers@postgresql.org

Milan Zamazal wrote:

"TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:

TL> The GPL does restrict the conditions under which GPL'd code can
TL> be distributed; in particular it can't be distributed as part of
TL> a program that is not all GPL'd (more or less --- I have not
TL> read the terms lately). So, because we use BSD license rather
TL> than GNU, we cannot *include in our distribution* any library
TL> that is under GPL.

[All IMHO, I'm not a lawyer etc. too.]

I think that from the point of GPL there is basically no problem with
PostgreSQL license, since it contains no restriction incompatible with
GPL.

The situation with Aladdin Ghostscript is quite different, it is under
non-free license, its license is in conflict with GPL and so it clearly
can't use GPLed code.

However, including GPLed code into PostgreSQL, though I think it's fully
legal, means that third party can't take the PostgreSQL as a whole and
distribute it under license violating GPL, e.g. as a proprietary product
without available sources. If it is important for you to support *more*
restrictive licensing than GPL, then you should avoid inclusion of GPLed
code into PostgreSQL.

Please clear this up one way or another.
I was looking to include PostgreSQL into my companies proprietary software
package.
I was going to make all of the arrangements to follow the PostreSQL
Copyright.
I can not include source code of my companies software, since it is to
copyrighted to my company.

Please list the steps i would need to comply with PostgreSQL's Copyright.
(I was under the impression that the Copyright from the Regents of U of CA
was it)
List any modules that is would need to include/execlude to avoid voilating
other Copyrights used by PostgreSQL.

Your scaring me guys.

P.S.

You guys have a great product from what i have seen so far. I am realy
looking forward to release 7.

John Ingram
Senior Software Engineer

Milan Zamazal

From bouncefilter Wed Oct 20 10:37:10 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA74021
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 10:36:34 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA12588;
Wed, 20 Oct 1999 10:34:52 -0400 (EDT)
To: Peter Mount <petermount@it.maidstone.gov.uk>
cc: "'Bruce Momjian'" <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-reply-to: Your message of Wed, 20 Oct 1999 08:12:23 +0100
<1B3D5E532D18D311861A00600865478C25E72A@exchange1.nt.maidstone.gov.uk>
Date: Wed, 20 Oct 1999 10:34:52 -0400
Message-ID: <12586.940430092@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Mount <petermount@it.maidstone.gov.uk> writes:

Just a thought: How does this affect anything placed in the contrib
directory? If someone writes a tool under the GPL, can it be included
under the src/contrib directory, or would we fall foul just because it's
included with our source?

Good question. The GPL contains a clause to the effect that "mere
aggregation" of a GPL'd piece of code in a source distribution with
unrelated pieces of code is OK, even if those other pieces of code
are not GPL'd. But the contrib directory is not exactly unrelated
to the main Postgres distribution, so I'm not sure that we can point
to this clause to justify putting a GPL'd program in contrib. It'd
be a gray area...

I'd be inclined to say "if you want to put your tool under GPL, fine,
but then distributing it is up to you". We don't need to be taking
any legal risks on this point. A safe policy is that everything
distributed by the Postgres group has to carry the same BSD license.

regards, tom lane

From bouncefilter Wed Oct 20 10:50:10 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA75894
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 10:49:17 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA12672;
Wed, 20 Oct 1999 10:48:03 -0400 (EDT)
To: Milan Zamazal <pdm@debian.cz>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-reply-to: Your message of 20 Oct 1999 10:03:17 +0200
<87bt9uv4qi.fsf@pdm.pvt.net>
Date: Wed, 20 Oct 1999 10:48:03 -0400
Message-ID: <12670.940430883@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Milan Zamazal <pdm@debian.cz> writes:

"TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:

TL> The GPL does restrict the conditions under which GPL'd code can
TL> be distributed; in particular it can't be distributed as part of
TL> a program that is not all GPL'd (more or less --- I have not
TL> read the terms lately). So, because we use BSD license rather
TL> than GNU, we cannot *include in our distribution* any library
TL> that is under GPL.

I think that from the point of GPL there is basically no problem with
PostgreSQL license, since it contains no restriction incompatible with
GPL.

Actually it's the other way around: BSD-type license doesn't care about
GPL'd stuff in the same distribution ... but GPL license does. The GPL
insists that all its terms, including its restrictions, apply exactly
to the whole of any program containing any GPL'd code. So we'd be
violating the GPL if we had parts of Postgres under GPL and parts under
BSD, because BSD is *less* restrictive than GPL (it puts fewer
requirements on a recipient of the code than GPL does). And we can't
just arbitrarily change the Berkeley-derived code from BSD to GPL.

In practice this is probably all just nit-picking; the Postgres group
itself isn't doing anything with Postgres that doesn't fall within the
terms of the GPL. But from a legalistic point of view the two licenses
are not compatible.

regards, tom lane

From bouncefilter Wed Oct 20 10:53:10 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id KAA80203
for <pgsql-hackers@postgresql.org>;
Wed, 20 Oct 1999 10:52:12 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 3566 invoked by uid 1001); 20 Oct 1999 14:52:14 -0000
Date: Wed, 20 Oct 1999 10:52:14 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Peter Mount <petermount@it.maidstone.gov.uk>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <12586.940430092@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.05.9910201050230.3530-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 20 Oct 1999, Tom Lane wrote:

Peter Mount <petermount@it.maidstone.gov.uk> writes:

Just a thought: How does this affect anything placed in the contrib
directory? If someone writes a tool under the GPL, can it be included
under the src/contrib directory, or would we fall foul just because it's
included with our source?

Good question. The GPL contains a clause to the effect that "mere
aggregation" of a GPL'd piece of code in a source distribution with
unrelated pieces of code is OK, even if those other pieces of code
are not GPL'd. But the contrib directory is not exactly unrelated
to the main Postgres distribution, so I'm not sure that we can point
to this clause to justify putting a GPL'd program in contrib. It'd
be a gray area...

Items in the contrib section aren't required for the use of PostgreSQL,
however PostgreSQL *is* required to use those items. So shouldn't the
items in contrib have to change to a Berkeley style license? :)

I mean it's only fair!

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Wed Oct 20 11:39:12 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA87844
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 11:38:14 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
JAA15081;
Wed, 20 Oct 1999 09:37:49 -0600 (MDT)
Date: Wed, 20 Oct 1999 09:37:49 -0600 (MDT)
Message-Id: <199910201537.JAA15081@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: petermount@it.maidstone.gov.uk, maillist@candle.pha.pa.us,
pgsql-hackers@postgreSQL.org
In-reply-to: <12586.940430092@sss.pgh.pa.us> (message from Tom Lane on Wed, 20
Oct 1999 10:34:52 -0400)
Subject: Re: [HACKERS] Readline use in trouble?
References: <12586.940430092@sss.pgh.pa.us>

Good question. The GPL contains a clause to the effect that "mere
aggregation" of a GPL'd piece of code in a source distribution with
unrelated pieces of code is OK, even if those other pieces of code
are not GPL'd. But the contrib directory is not exactly unrelated
to the main Postgres distribution, so I'm not sure that we can point
to this clause to justify putting a GPL'd program in contrib. It'd
be a gray area...

The problem only comes if I, for example, want to distribute all of
postgresql (contrib included) in a non-source (i.e., proprietary) way.
That is fine if contrib includes no GPL code; if it does, I need to
distribute the code for that portion only. Thus, if we want to
maintain as broad a potential as possible (including non-source
distributions) we need to encourage adoption of the BSD license for
all source.

To make it easier for those distributing postgresql to keep track of
this stuff, perhaps we need a gnu (or gpl) directory (like or under
contrib) in which would go GPL code. Then it would be crystal clear
which portion of the code has which restrictions. It would also be
clear that this is an aggregation. This is the mechanism used by
NetBSD for their code tree, which does include some gnu software.

Still, encouraging non-GPL contrib stuff is a good thing in order to
maintain future options, because GPL contrib code _cannot_ be added to
the main tree without affecting the distribution of the entire thing.

Cheers,
Brook

From bouncefilter Wed Oct 20 11:39:13 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA87857;
Wed, 20 Oct 1999 11:38:32 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA12953;
Wed, 20 Oct 1999 11:38:01 -0400 (EDT)
To: meskes@postgreSQL.org (Michael Meskes)
cc: pgsql-hackers@postgreSQL.org
Subject: Planning final assault on query length limits
Date: Wed, 20 Oct 1999 11:38:00 -0400
Message-ID: <12950.940433880@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

AFAICT, the last remaining textual length limits in the backend are a
couple of fixed-size buffers in rewriteDefine.c and array support.
In the next few days (probably this weekend) I intend to fix that code
and then remove all #define constants that have anything to do with
string length limits. (Tentative hit list is attached.)

Although the backend is in fairly good shape, there are parts of
interfaces/ and bin/ that are not. In particular:

pg_dump has a lot of uses of MAX_QUERY_SIZE. I believe Michael Ansley
is working on revising pg_dump to use expansible string buffers, so for
now I will leave that code alone (I'll just temporarily stick a
definition of MAX_QUERY_SIZE into pg_dump.h).

ecpg's lexer needs the same fixes recently applied to parser/scan.l to
eliminate a fixed-size literal buffer and allow flex's input buffer to
grow as needed. Michael Meskes usually handles ecpg --- Michael, do
you want to deal with this issue or shall I take a cut at it?

The odbc, python, and cli interfaces will all break because they contain
references to symbols I propose to remove. Since I don't use any of
these, and they aren't built by default, I can face this prospect
without flinching ;-). This is a call for whoever maintains these
modules to get busy.

ODBC will probably need some actual thought, since what it seems to be
doing with these symbols is making their values available to client
programs on request. Does ODBC's API for this function have a concept
of "no specific upper limit"?

regards, tom lane

Say goodnight to:

MAX_PARSE_BUFFER
MAX_QUERY_SIZE
ERROR_MSG_LENGTH
MAX_LINES
MAX_STRING_LENGTH
REMARK_LENGTH
ELOG_MAXLEN
MAX_BUFF_SIZE
PQ_BUFFER_SIZE
MAXPGPATH
MAX_STRING_LENGTH
YY_BUF_SIZE remove hacking in makefiles
YY_READ_BUF_SIZE no need to alter default
MaxHeapTupleSize (not used)
MaxAttributeSize (not used)
MaxAttrSize (where used for buffer sizing)

Suspicious-looking symbols found only in various interfaces/ dirs;
I don't plan to remove these but someone should:

SQL_PACKET_SIZE odbc
MAX_MESSAGE_LEN interfaces/cli, odbc
MAX_STATEMENT_LEN odbc
TEXT_FIELD_SIZE odbc
MAX_VARCHAR_SIZE odbc
DRV_VARCHAR_SIZE odbc
DRV_LONGVARCHAR_SIZE odbc
MAX_CONNECT_STRING odbc
MAX_BUFFER_SIZE interfaces/python
MAX_FIELDS odbc (does this relate to anything real?)

From bouncefilter Wed Oct 20 11:45:11 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA88681
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 11:44:30 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id LAA01184;
Wed, 20 Oct 1999 11:42:33 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910201542.LAA01184@candle.pha.pa.us>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <199910201537.JAA15081@biology.nmsu.edu> from Brook Milligan at
"Oct 20, 1999 09:37:49 am"
To: Brook Milligan <brook@biology.nmsu.edu>
Date: Wed, 20 Oct 1999 11:42:33 -0400 (EDT)
CC: tgl@sss.pgh.pa.us, petermount@it.maidstone.gov.uk,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Good question. The GPL contains a clause to the effect that "mere
aggregation" of a GPL'd piece of code in a source distribution with
unrelated pieces of code is OK, even if those other pieces of code
are not GPL'd. But the contrib directory is not exactly unrelated
to the main Postgres distribution, so I'm not sure that we can point
to this clause to justify putting a GPL'd program in contrib. It'd
be a gray area...

The problem only comes if I, for example, want to distribute all of
postgresql (contrib included) in a non-source (i.e., proprietary) way.
That is fine if contrib includes no GPL code; if it does, I need to
distribute the code for that portion only. Thus, if we want to
maintain as broad a potential as possible (including non-source
distributions) we need to encourage adoption of the BSD license for
all source.

But Alladin Ghostscript is distributed in source form. This GPL legal
stuff is a terrible hassle.

-- 
  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 Wed Oct 20 12:00:12 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA91325
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 11:59:55 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA13030;
Wed, 20 Oct 1999 11:57:24 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Brook Milligan <brook@biology.nmsu.edu>, petermount@it.maidstone.gov.uk,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Readline use in trouble?
In-reply-to: Your message of Wed, 20 Oct 1999 11:42:33 -0400 (EDT)
<199910201542.LAA01184@candle.pha.pa.us>
Date: Wed, 20 Oct 1999 11:57:24 -0400
Message-ID: <13028.940435044@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <maillist@candle.pha.pa.us> writes:

That is fine if contrib includes no GPL code; if it does, I need to
distribute the code for that portion only. Thus, if we want to
maintain as broad a potential as possible (including non-source
distributions) we need to encourage adoption of the BSD license for
all source.

But Alladin Ghostscript is distributed in source form.

But not *only* in source form. Aladdin make their living by selling
Ghostscript to printer manufacturers and so forth. The printer makers
are not about to ship out printers with copies of source code, nor
even with notices explaining where to get the printer source code.
If they obtained Ghostscript under GPL then they'd have to make not
only the PS interpreter source available, but probably the entire
firmware for the printer (it's a derived work, no?) and they are
certainly not about to do that. So they pay Aladdin for the rights
to use Ghostscript with a commercial license instead of GPL.

In the same way, if we distributed Postgres under GPL, it would not be
possible to sell proprietary systems that use Postgres as a component.
That is, in fact, exactly what the GPL is designed to prevent. But it
doesn't strike me as something we want for Postgres. We'd be cutting
off too much of the potential "market" of Postgres users. (Not only
would we lose companies who had an immediate interest in selling
DBMS-based code, but also those who had any thought of possibly doing
so in the future; that could be a lot of people.)

regards, tom lane

From bouncefilter Wed Oct 20 12:11:12 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA93260
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 12:11:00 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA03476;
Wed, 20 Oct 1999 12:09:04 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910201609.MAA03476@candle.pha.pa.us>
Subject: Re: [HACKERS] Readline use in trouble?]
In-Reply-To: <13028.940435044@sss.pgh.pa.us> from Tom Lane at "Oct 20,
1999 11:57:24 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 20 Oct 1999 12:09:04 -0400 (EDT)
CC: Brook Milligan <brook@biology.nmsu.edu>, petermount@it.maidstone.gov.uk,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <maillist@candle.pha.pa.us> writes:

That is fine if contrib includes no GPL code; if it does, I need to
distribute the code for that portion only. Thus, if we want to
maintain as broad a potential as possible (including non-source
distributions) we need to encourage adoption of the BSD license for
all source.

But Alladin Ghostscript is distributed in source form.

But not *only* in source form. Aladdin make their living by selling
Ghostscript to printer manufacturers and so forth. The printer makers
are not about to ship out printers with copies of source code, nor
even with notices explaining where to get the printer source code.
If they obtained Ghostscript under GPL then they'd have to make not
only the PS interpreter source available, but probably the entire
firmware for the printer (it's a derived work, no?) and they are
certainly not about to do that. So they pay Aladdin for the rights
to use Ghostscript with a commercial license instead of GPL.

Oh, I didn't realize they had a binary-only distribution that was
_different_ from the source distribution.

-- 
  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 Wed Oct 20 12:27:11 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA95840
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 12:27:07 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone (ppm167.noc.tokyo.nsk.ne.jp [210.160.233.86])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id BAA02098; Thu, 21 Oct 1999 01:26:50 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Vadim Mikheev" <vadim@krs.ru>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] mdnblocks is an amazing time sink in huge relations
Date: Thu, 21 Oct 1999 01:26:19 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFEEGFCAAA.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: <380D456E.B99A7CF8@krs.ru>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

Hiroshi Inoue wrote:

Does this mean the following ?

1. shared cache holds committed system tuples.
2. private cache holds uncommitted system tuples.
3. relpages of shared cache are updated immediately by
phisical change and corresponding buffer pages are
marked dirty.
4. on commit, the contents of uncommitted tuples except
relpages,reltuples,... are copied to correponding tuples

^^^^^^^^^
reltuples in shared catalog cache (SCC) will be updated!
If transaction inserted some tuples then SCC->reltuples
will be incremented, etc.

System tuples are only modifiled or (insert and delet)ed like
user tuples when reltuples are updated ?
If only modified,we couldn't use it in SERIALIZABLE mode.

^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
...this...

I'm not sure that we must provide read consistency
for internal-use columns...

As for relpages,read consistency has no meaning
because they are out of transaction control.
But as for reltuples,isn't it difficult to commit/rollback
correctly without using insert-delete updation ?
Does your WAL system make it possible ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Oct 20 12:48:12 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA99474
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 12:47:58 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id MAA13421;
Wed, 20 Oct 1999 12:44:35 -0400
Message-ID: <380DF16C.8993F594@wgcr.org>
Date: Wed, 20 Oct 1999 12:44:28 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Vince Vielhaber <vev@michvhf.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>,
Peter Mount <petermount@it.maidstone.gov.uk>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
References: <Pine.BSF.4.05.9910201050230.3530-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vince Vielhaber wrote:

Items in the contrib section aren't required for the use of PostgreSQL,
however PostgreSQL *is* required to use those items. So shouldn't the
items in contrib have to change to a Berkeley style license? :)

I mean it's only fair!

I know of at least two items in contrib that are required to run the
regression tests -- which, arguably, make PostgreSQL require those two
components (autoinc and refint).

And, the GPL is not fair. It is highly restrictive to programmer
freedom in ways (and promotes code freedom in others -- for many things
it makes sense). It's not called the 'GNU Public Virus' without merit.
Lots of great software has been GPL'd -- and that's fine. But
PostgreSQL is not -- and if PostgreSQL wants to remain BSD'd, then GPL'd
code is a real sticky mess that's best left alone.

I am not against either of these two licenses -- but the known issues of
dealing with them have to be understood, or problems may arise.

JMHO, of course.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Wed Oct 20 13:17:12 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA04003
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 13:16:50 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
LAA15401;
Wed, 20 Oct 1999 11:15:43 -0600 (MDT)
Date: Wed, 20 Oct 1999 11:15:43 -0600 (MDT)
Message-Id: <199910201715.LAA15401@biology.nmsu.edu>
X-Authentication-Warning: biology.nmsu.edu: brook set sender to
brook@biology.nmsu.edu using -f
From: Brook Milligan <brook@biology.nmsu.edu>
To: maillist@candle.pha.pa.us
CC: tgl@sss.pgh.pa.us, petermount@it.maidstone.gov.uk,
pgsql-hackers@postgreSQL.org
In-reply-to: <199910201609.MAA03476@candle.pha.pa.us> (message from Bruce
Momjian on Wed, 20 Oct 1999 12:09:04 -0400 (EDT))
Subject: Re: [HACKERS] Readline use in trouble?]
References: <199910201609.MAA03476@candle.pha.pa.us>

Oh, I didn't realize they had a binary-only distribution that was
_different_ from the source distribution.

DIFFERENT is not relevant. I could today ship a binary verion of
postgresql in its present form as a proprietary product with no source
code. No license problems arise from doing so. Allowing GPL code
into the base system causes the problem.

As just said, this is a good thing from the point of view of
encouraging participation and commercial success. As long as the open
source version of postgresql remains a well-designed, solid product it
behooves any commercial distributor to aid in its maintenance rather
than take on the whole thing. Ideally, they will contribute any fixes
they make so that all can benefit and perhaps more importantly so they
don't have to maintain the separate fixes any longer.

Cheers,
Brook

From bouncefilter Wed Oct 20 13:21:12 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA04684;
Wed, 20 Oct 1999 13:20:42 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
LAA15406;
Wed, 20 Oct 1999 11:18:08 -0600 (MDT)
Date: Wed, 20 Oct 1999 11:18:08 -0600 (MDT)
Message-Id: <199910201718.LAA15406@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: meskes@postgresql.org, pgsql-hackers@postgresql.org
In-reply-to: <12950.940433880@sss.pgh.pa.us> (message from Tom Lane on Wed, 20
Oct 1999 11:38:00 -0400)
Subject: Re: [HACKERS] Planning final assault on query length limits
References: <12950.940433880@sss.pgh.pa.us>

AFAICT, the last remaining textual length limits in the backend are a
couple of fixed-size buffers in rewriteDefine.c and array support.
In the next few days (probably this weekend) I intend to fix that code
and then remove all #define constants that have anything to do with
string length limits. (Tentative hit list is attached.)

Great!

Jan, does this mean that we can also lose the "rewrite string too big"
problem with rules?

That would be a huge win.

Cheers,
Brook

From bouncefilter Wed Oct 20 13:45:12 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA08459
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 13:44:53 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id NAA12475;
Wed, 20 Oct 1999 13:41:04 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910201741.NAA12475@candle.pha.pa.us>
Subject: Re: [HACKERS] Readline use in trouble?]
In-Reply-To: <199910201715.LAA15401@biology.nmsu.edu> from Brook Milligan at
"Oct 20, 1999 11:15:43 am"
To: Brook Milligan <brook@biology.nmsu.edu>
Date: Wed, 20 Oct 1999 13:41:04 -0400 (EDT)
CC: tgl@sss.pgh.pa.us, petermount@it.maidstone.gov.uk,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Oh, I didn't realize they had a binary-only distribution that was
_different_ from the source distribution.

DIFFERENT is not relevant. I could today ship a binary verion of
postgresql in its present form as a proprietary product with no source
code. No license problems arise from doing so. Allowing GPL code
into the base system causes the problem.

Does GPL require the source to be included, or just available for free?

-- 
  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 Wed Oct 20 13:45:13 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA08452;
Wed, 20 Oct 1999 13:44:47 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id NAA12484;
Wed, 20 Oct 1999 13:41:27 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910201741.NAA12484@candle.pha.pa.us>
Subject: Re: [HACKERS] Planning final assault on query length limits
In-Reply-To: <199910201718.LAA15406@biology.nmsu.edu> from Brook Milligan at
"Oct 20, 1999 11:18:08 am"
To: Brook Milligan <brook@biology.nmsu.edu>
Date: Wed, 20 Oct 1999 13:41:27 -0400 (EDT)
CC: tgl@sss.pgh.pa.us, meskes@postgreSQL.org, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

AFAICT, the last remaining textual length limits in the backend are a
couple of fixed-size buffers in rewriteDefine.c and array support.
In the next few days (probably this weekend) I intend to fix that code
and then remove all #define constants that have anything to do with
string length limits. (Tentative hit list is attached.)

Great!

Jan, does this mean that we can also lose the "rewrite string too big"
problem with rules?

That would be a huge win.

No. We have to have long tuples.

-- 
  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 Wed Oct 20 13:58:13 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA10755
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 13:57:17 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id NAA13721;
Wed, 20 Oct 1999 13:57:12 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910201757.NAA13721@candle.pha.pa.us>
Subject: Book on web site
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Wed, 20 Oct 1999 13:57:12 -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

OK, the book in on our web site now in HTML and PDF formats. It will be
updated automatically very night.

Go to:

http://www.postgresql.org/docs

Under documentation, you will see the entry "Published Book".

From our main web site, it is under Info Central/Documentation.

Comments welcomed.

-- 
  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 Wed Oct 20 13:59:12 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA10999
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 13:58:56 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
LAA15542;
Wed, 20 Oct 1999 11:58:50 -0600 (MDT)
Date: Wed, 20 Oct 1999 11:58:50 -0600 (MDT)
Message-Id: <199910201758.LAA15542@biology.nmsu.edu>
X-Authentication-Warning: biology.nmsu.edu: brook set sender to
brook@biology.nmsu.edu using -f
From: Brook Milligan <brook@biology.nmsu.edu>
To: maillist@candle.pha.pa.us
CC: tgl@sss.pgh.pa.us, petermount@it.maidstone.gov.uk,
pgsql-hackers@postgreSQL.org
In-reply-to: <199910201741.NAA12475@candle.pha.pa.us> (message from Bruce
Momjian on Wed, 20 Oct 1999 13:41:04 -0400 (EDT))
Subject: Re: [HACKERS] Readline use in trouble?]
References: <199910201741.NAA12475@candle.pha.pa.us>

Does GPL require the source to be included, or just available for free?

Pretty sure just a pointer to location is good enough. The catch is
that it has to be the exact version shipped and there is a time limit
(3 years?) for availability, so pointing to the gnu ftp site probably
doesn't work.

Cheers,
Brook

From bouncefilter Wed Oct 20 14:00:12 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA11451;
Wed, 20 Oct 1999 14:00:06 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
LAA15560;
Wed, 20 Oct 1999 11:59:58 -0600 (MDT)
Date: Wed, 20 Oct 1999 11:59:58 -0600 (MDT)
Message-Id: <199910201759.LAA15560@biology.nmsu.edu>
X-Authentication-Warning: biology.nmsu.edu: brook set sender to
brook@biology.nmsu.edu using -f
From: Brook Milligan <brook@biology.nmsu.edu>
To: maillist@candle.pha.pa.us
CC: tgl@sss.pgh.pa.us, meskes@postgreSQL.org, pgsql-hackers@postgreSQL.org
In-reply-to: <199910201741.NAA12484@candle.pha.pa.us> (message from Bruce
Momjian on Wed, 20 Oct 1999 13:41:27 -0400 (EDT))
Subject: Re: [HACKERS] Planning final assault on query length limits
References: <199910201741.NAA12484@candle.pha.pa.us>

Jan, does this mean that we can also lose the "rewrite string too big"
problem with rules?

No. We have to have long tuples.

Darn. Oh well, I guess this is a major step in that direction.

Cheers,
Brook

From bouncefilter Wed Oct 20 14:23:13 1999
Received: from web2101.mail.yahoo.com (web2101.mail.yahoo.com [128.11.68.245])
by hub.org (8.9.3/8.9.3) with SMTP id OAA15165
for <pgsql-hackers@postgresql.org>;
Wed, 20 Oct 1999 14:22:50 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19991020182335.4182.rocketmail@web2101.mail.yahoo.com>
Received: from [24.26.131.45] by web2101.mail.yahoo.com;
Wed, 20 Oct 1999 11:23:35 PDT
Date: Wed, 20 Oct 1999 11:23:35 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] Book on web site
To: Bruce Momjian <maillist@candle.pha.pa.us>
Cc: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Should we be checking it for any semantic errors?
If we find one, do we win a prize? ;-) On node24,
"Creating Tables" you have:

The words CREATE TABLE have special meaning to the
database server. They indicate that the next request
from the user is to create a database.
^^^^^^^^
Mike Mascari
(mascarim@yahoo.com)

--- Bruce Momjian <maillist@candle.pha.pa.us> wrote:

OK, the book in on our web site now in HTML and PDF
formats. It will be
updated automatically very night.

Go to:

http://www.postgresql.org/docs

Under documentation, you will see the entry
"Published Book".

From our main web site, it is under Info
Central/Documentation.

Comments welcomed.

-- 
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

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

From bouncefilter Wed Oct 20 14:26:13 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA15665
for <pgsql-hackers@postgresql.org>;
Wed, 20 Oct 1999 14:25:30 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id OAA16592;
Wed, 20 Oct 1999 14:25:17 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910201825.OAA16592@candle.pha.pa.us>
Subject: Re: [HACKERS] Book on web site
In-Reply-To: <19991020182335.4182.rocketmail@web2101.mail.yahoo.com> from Mike
Mascari at "Oct 20, 1999 11:23:35 am"
To: Mike Mascari <mascarim@yahoo.com>
Date: Wed, 20 Oct 1999 14:25:17 -0400 (EDT)
CC: pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Should we be checking it for any semantic errors?
If we find one, do we win a prize? ;-) On node24,
"Creating Tables" you have:

The words CREATE TABLE have special meaning to the
database server. They indicate that the next request
from the user is to create a database.
^^^^^^^^

You get your money back on your PostgreSQL purchase. :-)

Thanks. Fix will appear tomorrow.

-- 
  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 Wed Oct 20 14:38:14 1999
Received: from academic.mssm.edu (academic.mssm.edu [146.203.1.9])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA17694
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 14:38:00 -0400 (EDT)
(envelope-from ramirez@doc.mssm.edu)
Received: from doc.mssm.edu (adwr44.mssm.edu [146.203.33.44])
by academic.mssm.edu (8.9.1/8.9.1) with ESMTP id OAA13683
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 14:31:31 -0400 (EDT)
Message-ID: <380E0970.9ADFF8E9@doc.mssm.edu>
Date: Wed, 20 Oct 1999 14:26:56 -0400
From: Edwin Ramirez <ramirez@doc.mssm.edu>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: translate function (BUG?)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello all,

I was looking at the translate function and I think that it does not
behave quite right. I modified the translate function in
oracle_compat.c (included below) to make work more like its Oracle
counterpart. It seems to work but it returns the following message:
NOTICE: PortalHeapMemoryFree: 0x8241fcc not in alloc set!

Below are the Oracle and Postgres session transcripts.

select translate('edwin', 'wi', 'af') from dual;
ORACLE:
TRANS
-----
edafn
1 row selected.

POSTGRES
translate
---------
edain
(1 row)

select translate('edwin', 'wi', 'a') from dual;
ORACLE
TRAN
----
edan
1 row selected.

POSTGRES
translate
---------
edain
(1 row)

select length(translate('edwin', 'wi', 'a')) from dual;
ORACLE
LENGTH(TRA
----------
4
1 row selected.

POSTGRES
length
------
5
(1 row)

-----------------------NEW
FUNCTION--------------------------------------
text *
translate(text *string, text *from, text *to)
{
text *ret;
char *ptr_ret, *from_ptr, *to_ptr, *source, *target, *temp, rep;
int m, fromlen, tolen, retlen, i;

if ((string == (text *) NULL) ||
((m = VARSIZE(string) - VARHDRSZ) <= 0))
return string;

target = (char *) palloc(VARSIZE(string) - VARHDRSZ);
source = VARDATA(string);
temp = target;

fromlen = VARSIZE(from) - VARHDRSZ;
from_ptr = VARDATA(from);
tolen = VARSIZE(to) - VARHDRSZ;
to_ptr = VARDATA(to);
retlen = 0;
while (m--)
{
rep = *source;
for(i=0;i<fromlen;i++) {
if(from_ptr[i] == *source) {
if(i < tolen) {
rep = to_ptr[i];
} else {
rep = 0;
}
break;
}
}
if(rep != 0) {
*target++ = rep;
retlen++;
}
source++;
}

ret = (text *) palloc(retlen + VARHDRSZ);
VARSIZE(ret) = retlen + VARHDRSZ;
ptr_ret = VARDATA(ret);
for(i=0;i<retlen;i++) {
*ptr_ret++ = temp[i];
}
pfree(target);
return ret;
}

Thanks,
Edwin S. Ramirez

From bouncefilter Wed Oct 20 14:38:19 1999
Received: from mail.texoma.net (mail.texoma.net [209.151.96.3])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA17669
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 14:37:40 -0400 (EDT)
(envelope-from jhouchin@texoma.net)
Received: from texoma.net (ppp-151-100-119.texoma.net [209.151.100.119])
by mail.texoma.net (Postfix) with ESMTP
id 56A8715ECED; Wed, 20 Oct 1999 13:37:37 -0500 (CDT)
Message-ID: <380E0BC7.EA62E9B3@texoma.net>
Date: Wed, 20 Oct 1999 13:36:55 -0500
From: Jimmie Houchin <jhouchin@texoma.net>
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: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] book status
References: <11734.940396313@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I will have to agree whole heartily with the sentiments here. This a
work that your are doing and should rightly be appropriately
compensated. All within the PostgreSQL community will benefit.

The community will benefit with increased documentation, increased
exposure and visibility and increasing credibility. Philosophically, I
believe all who use PostgreSQL benefit economically simply by keeping
untold numbers of dollars (or other currency) in their pocket. Like you
I think those who do use PostgreSQL and can contribute should. But it is
nice to know that a quality option is available for those who can't
contribute financially.

I don't think you should feel obligated to contribute any of the
earnings to PostgreSQL. Let your giving be by choice and joy not
obligation due to pressure from any part of the community.

Absolutely no apology required. Your contribution is a blessing to the
community, not a burden. :)

Personally, I am ready to buy. Where can I get my copy. :)

I also hope have more books for PostgreSQL cooking on the back burner.

Jimmie Houchin

Tom Lane wrote:

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Yes, I am being payed for the book, at some future date. I realize
other developers are using PostgreSQL in their work or in consulting,
but this is a much more public involvement. All I can say is that I
have always been ready to throw money into the PostgreSQL project, and
will continue to do so when possible.

Since you'll be doing the bulk of the work that is specific to the book,
I can't see any reason to object to you being the one getting paid for
it. Many (most?) of us are using Postgres for work purposes, or
otherwise deriving some kind of personal/corporate/proprietary benefit
from it. A book project based on Postgres seems no different to me
from the money my company hopes to make from running a Postgres-based
application. Indeed, this book project is considerably more likely
to return tangible benefit to the Postgres group (in the form of new
users/contributors attracted to the project) than most other ways
people might be using Postgres to make money.

In short, you needn't offer the slightest apology for collecting the
book royalties personally. From what I've heard of the book-writing
biz, you're unlikely to get rich off it anyway :-(

Since I didn't see any howls of outrage on the mailing list, I imagine
everyone else thinks the same anyway, but if you need some reassurance
these are my two cents.

BTW, where do people want the PDF and HTML files? My idea is to update
them every night.

Stick 'em on the website/ftpsite somewhere under the docs page. I'd
probably gripe if I found them getting pulled as part of the regular CVS
source module --- those updates are slow enough already --- but if you
want to keep them in CVS I suppose a separate CVS module could be set up.

regards, tom lane

************

From bouncefilter Wed Oct 20 14:50:14 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA19545;
Wed, 20 Oct 1999 14:49:34 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id OAA13726;
Wed, 20 Oct 1999 14:47:46 -0400 (EDT)
To: Brook Milligan <brook@biology.nmsu.edu>
cc: maillist@candle.pha.pa.us, meskes@postgreSQL.org,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Planning final assault on query length limits
In-reply-to: Your message of Wed, 20 Oct 1999 11:59:58 -0600 (MDT)
<199910201759.LAA15560@biology.nmsu.edu>
Date: Wed, 20 Oct 1999 14:47:46 -0400
Message-ID: <13724.940445266@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Brook Milligan <brook@biology.nmsu.edu> writes:

Jan, does this mean that we can also lose the "rewrite string too big"
problem with rules?

No. We have to have long tuples.

Darn. Oh well, I guess this is a major step in that direction.

I'm hoping that once this is done, someone who knows the guts of the
storage managers better than I will feel motivated to work on letting
stored tuples cross block boundaries. (Paging Vadim...) That seems
to be the last piece of the puzzle.

regards, tom lane

From bouncefilter Wed Oct 20 15:22:13 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA24838
for <hackers@postgresql.org>; Wed, 20 Oct 1999 15:21:52 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id PAA13701;
Wed, 20 Oct 1999 15:21:15 -0400
Message-ID: <380E1622.17C100A8@wgcr.org>
Date: Wed, 20 Oct 1999 15:21:06 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: "B.V.Dean" <B.V.Dean@ukc.ac.uk>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: PostgreSQL Perl Module
References: <19657.940409781@pelican.ukc.ac.uk>
<380DBF2B.6D1DC13C@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

I have downloaded and installed your packaged RPM for the Pg.pm module for
PostgreSQL 6.5.1 on RedHat 6.0 i386 linux and cannot be found by perl.
Is my problem unique? When I run a perl script with 'use Pg;' in it I get:
Can't locate Pg.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .) at ../src/Perl/pg.pl line 1.
BEGIN failed--compilation aborted at ../src/Perl/pg.pl line 1.
The Pg.pm has been installed into:
/usr/lib/perl5/site_perl

I haven't had the chance to use much perl in the last year or two, but
it may be that the default @INC does not include the directories we
used for the installation. Also, the RPMs were generated on a RH5.2
system, which may have a slightly different configuration.

[snip]

which seems to be consistant. One thing you can try is to add
/usr/lib/perl5/site_perl to INC at the top of your program and see if
that helps. Try:

Won't help. RedHat 5.2's perl is much older than RedHat 6.0's, and
there are other major incompatibilities for compiled modules. Not to
mention the directory differences in the install. I recommend that
anyone who wants to use the RPM's with non-standard perl versions
rebuild from the source RPM, since the perl client is highly sensitive
to versioning problems.

include RPMs generated specifically for RH6.0, but Lamar had just put
out a request for someone to test the RH6.1-generated RPMs on a RH6.0
machine to see if they are compatible. If you have time, I'm sure he
would appreciate trying that out.

Yes, that would be NICE. The perl version is the same for 6.1 as for
6.0.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Wed Oct 20 19:57:16 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id TAA40212
for <hackers@postgresql.org>; Wed, 20 Oct 1999 19:56:45 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 4643 invoked by uid 1001); 20 Oct 1999 23:56:49 -0000
Message-ID: <XFMail.991020195649.vev@michvhf.com>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Wed, 20 Oct 1999 19:56:49 -0400 (EDT)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: hackers@postgresql.org
Subject: distinct. Is this the correct behaviour?

Is this the way distinct is supposed to work? My intent is to give
only one for each different value of x - like it does in the first
distinct example. But when order by is added for the date/time sort
I get what you see in the second distinct example.

pop4=> select * from foo;
x|y
-+----------------------------
1|Wed Oct 20 06:29:41 1999 EDT
1|Wed Oct 20 06:29:42 1999 EDT
1|Wed Oct 20 06:29:43 1999 EDT
1|Wed Oct 20 06:29:48 1999 EDT
(4 rows)

pop4=> select distinct x from foo;
x
-
1
(1 row)

pop4=> select distinct x from foo order by y;
x
-
1
1
1
1
(4 rows)

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Wed Oct 20 20:43:17 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA45311
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 20:43:14 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id UAA04085
for pgsql-hackers@postgreSQL.org; Wed, 20 Oct 1999 20:42:25 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910210042.UAA04085@candle.pha.pa.us>
Subject: New psql startup banner
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Wed, 20 Oct 1999 20:42:25 -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

psql now shows new text on startup. The old one just looked bad.
Hope the psql upgrader can merge these changes in. I know we weren't
supposed to touch psql, but I suspect he is not touching the banner.

---------------------------------------------------------------------------

OLD:

Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL

NEW:

Welcome to the PostgreSQL interactive terminal.
(Please read the copyright file for legal issues.)

-- 
  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 Wed Oct 20 21:07:17 1999
Received: from mecomb.com (gw.mecomb.com [161.142.249.98])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA48093
for <pgsql-general@postgreSQL.org>;
Wed, 20 Oct 1999 21:07:08 -0400 (EDT)
(envelope-from lylyeoh@mecomb.com)
Received: (from mail@localhost) by mecomb.com (8.8.7/8.8.7) id JAA13098
for <pgsql-general@postgreSQL.org>; Thu, 21 Oct 1999 09:06:50 +0800
Received: from <lylyeoh@mecomb.com> (ilab2.mecomb.po.my [192.168.3.22]) by
ns.mecomb.com via smap (V2.1)
id xma013085; Thu, 21 Oct 99 09:06:25 +0800
Message-Id: <3.0.5.32.19991021090815.008cb370@pop.mecomb.po.my>
X-Sender: lylyeoh@pop.mecomb.po.my
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Thu, 21 Oct 1999 09:08:15 +0800
To: (Postgres people)
From: Lincoln Yeoh <lylyeoh@mecomb.com>
Subject: Re: [GENERAL] Postgres INSERTs much slower than MySQL?
Cc: pgsql-general@postgreSQL.org
In-Reply-To: <380D7F71.F422AEC4@krs.ru>
References: <3.0.5.32.19991020122550.008bf780@pop.mecomb.po.my>
<6CF4B3E5928@ahorn.sgh.uunet.de>
<m11c7sz-00080dC@mailbox.reptiles.org>
<111F0F713069@ahorn.sgh.uunet.de>
<3.0.5.32.19991020153812.008c4620@pop.mecomb.po.my>
<3.0.5.32.19991020163318.0087e140@pop.mecomb.po.my>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:38 PM 20-10-1999 +0800, Vadim Mikheev wrote:

You hit buffer manager/disk manager problems or eat all disk space.
As for "modifying" - I meant insertion, deletion, update...

There was enough disk space (almost another gig more). So it's probably
some buffer manager problem. Is that the postgres buffer manager or is it a
Linux one?

Are you able to duplicate that problem? All I did was to turn off
autocommit and start inserting.

How many rows (blocks) can I insert before I have to do a commit?

Each transaction can have up to 2^32 commands.

Wow, that's cool.. Should be enough for everyone. I can't imagine anybody
making 4 billion statements without committing anything, not even politicians!

Well anyway the Postgres inserts aren't so much slower if I only commit
once in a while. Only about 3 times slower for the first 100,000 records.
So the subject line is now inaccurate :). Not bad, I like it.

Hope that it will be much faster when WAL will be implemented...

What's WAL? Is postgres going to be faster than MySQL? That would be pretty
impressive- transactions and all. Woohoo!

Hope it doesn't stand for Whoops, All's Lost :).

Cheerio,

Link.

From bouncefilter Wed Oct 20 21:11:17 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA48592
for <hackers@postgreSQL.org>; Wed, 20 Oct 1999 21:11:06 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA15109;
Wed, 20 Oct 1999 21:10:04 -0400 (EDT)
To: Vince Vielhaber <vev@michvhf.com>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] distinct. Is this the correct behaviour?
In-reply-to: Your message of Wed, 20 Oct 1999 19:56:49 -0400 (EDT)
<XFMail.991020195649.vev@michvhf.com>
Date: Wed, 20 Oct 1999 21:10:04 -0400
Message-ID: <15107.940468204@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Vince Vielhaber <vev@michvhf.com> writes:

Is this the way distinct is supposed to work? My intent is to give
only one for each different value of x - like it does in the first
distinct example. But when order by is added for the date/time sort
I get what you see in the second distinct example.

Yeah, I think it's a bug too. It's not quite clear what to change,
though.

The "problem" is that nodeUnique is doing a bitwise compare across the
whole tuple, including the hidden ('junk') y column that is needed to do
the sorting. So, because you have four different y values, you get four
rows out.

However, if we fix nodeUnique to ignore junk columns, then the result
becomes nondeterministic. Consider

x y

1 3
1 5
2 4

If we do "select distinct x from foo order by y" on this data, then the
order of the result depends on which of the two tuples with x=1 happens
to get chosen by the Unique filter. This is not good.

SQL92 gets around this by allowing ORDER BY only on columns of the
targetlist, so that you are not allowed to specify this query in the
first place.

I think it is useful to allow ORDER BY on hidden columns, but maybe we
need to forbid it when DISTINCT is present. If we do that then the
implementation of nodeUnique is OK as it stands, and the bug is that
the parser accepts an invalid query.

This is pretty closely related to the semantic problems of DISTINCT ON,
once you see that the trouble is having columns in the query that aren't
being used for (or aren't supposed to be used for) the DISTINCT check.

regards, tom lane

From bouncefilter Wed Oct 20 21:17:17 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA49401
for <pgsql-hackers@postgreSQL.org>;
Wed, 20 Oct 1999 21:16:25 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA15132;
Wed, 20 Oct 1999 21:15:20 -0400 (EDT)
To: Edwin Ramirez <ramirez@doc.mssm.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] translate function (BUG?)
In-reply-to: Your message of Wed, 20 Oct 1999 14:26:56 -0400
<380E0970.9ADFF8E9@doc.mssm.edu>
Date: Wed, 20 Oct 1999 21:15:20 -0400
Message-ID: <15130.940468520@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

You're trying to pfree(target) after having altered the target
pointer inside the main loop of the function...

regards, tom lane

From bouncefilter Wed Oct 20 21:48:17 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id VAA53515
for <hackers@postgreSQL.org>; Wed, 20 Oct 1999 21:47:49 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 4800 invoked by uid 1001); 21 Oct 1999 01:47:52 -0000
Message-ID: <XFMail.991020214752.vev@michvhf.com>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <15107.940468204@sss.pgh.pa.us>
Date: Wed, 20 Oct 1999 21:47:52 -0400 (EDT)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] distinct. Is this the correct behaviour?
Cc: hackers@postgreSQL.org

On 21-Oct-99 Tom Lane wrote:

Vince Vielhaber <vev@michvhf.com> writes:

If we do "select distinct x from foo order by y" on this data, then the
order of the result depends on which of the two tuples with x=1 happens
to get chosen by the Unique filter. This is not good.

What seems logical to me tho is that it should first select all of the
x cols that are equal, put them in y order, then pick the first one for
the distinct. At least this is the behaviour that I'm looking for; perhaps
I'm going to need to make a more complex call. I also wonder how other
RDBMS are handling it... I'll hafta see what sybase does (if I remember
*and* get a chance).

SQL92 gets around this by allowing ORDER BY only on columns of the
targetlist, so that you are not allowed to specify this query in the
first place.

I can understand the reason, yet also fail to understand.

I think it is useful to allow ORDER BY on hidden columns, but maybe we
need to forbid it when DISTINCT is present. If we do that then the
implementation of nodeUnique is OK as it stands, and the bug is that
the parser accepts an invalid query.

This is pretty closely related to the semantic problems of DISTINCT ON,
once you see that the trouble is having columns in the query that aren't
being used for (or aren't supposed to be used for) the DISTINCT check.

Ok, well what I'm trying to do is write a web-based discussion forum. I
wanted to list the subjects in any particular forum, but also want them
to be in the order in which they were first posted. So if I have 10
comments on one subject which first started last month and the subject
begun with a 'z', and another that was started today with the subject
beginning with an 'A', I want the end result to be:

zebras have stripes
Always cross at the light

as opposed to 10 lines about the zebras and only one on Always. It
seems elementary, but at the same time it seems complex. Must mean
it's time for bed.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Wed Oct 20 22:41:18 1999
Received: from megazone.bigpanda.com ([209.218.81.130])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA59641
for <hackers@postgreSQL.org>; Wed, 20 Oct 1999 22:40:27 -0400 (EDT)
(envelope-from acroyear@megazone.bigpanda.com)
Received: from megazone.bigpanda.com (localhost.bigpanda.com [127.0.0.1])
by megazone.bigpanda.com (8.8.8/8.8.5) with ESMTP id WAA12470;
Wed, 20 Oct 1999 22:40:01 -0400 (EDT)
Message-Id: <199910210240.WAA12470@megazone.bigpanda.com>
To: Vince Vielhaber <vev@michvhf.com>
cc: hackers@postgreSQL.org
From: sszabo@bigpanda.com
Subject: Re: [HACKERS] distinct. Is this the correct behaviour?
In-reply-to: Your message of "Wed, 20 Oct 1999 21:47:52 EDT."
<XFMail.991020214752.vev@michvhf.com>
Date: Wed, 20 Oct 1999 22:40:00 -0400
Sender: acroyear@bigpanda.com

This seems to generally work in postgres for the simple cases I tried:
select x from foo group by x order by min(y)

Now I don't know if there are any hidden gotchas in that (or wierdness
with the spec), but it also feels better to me than using distinct in this
case as well, because it seems to explicitly describe how you want y
ordered.

Ok, well what I'm trying to do is write a web-based discussion forum. I
wanted to list the subjects in any particular forum, but also want them
to be in the order in which they were first posted. So if I have 10
comments on one subject which first started last month and the subject
begun with a 'z', and another that was started today with the subject
beginning with an 'A', I want the end result to be:

zebras have stripes
Always cross at the light

as opposed to 10 lines about the zebras and only one on Always. It
seems elementary, but at the same time it seems complex. Must mean
it's time for bed.

From bouncefilter Wed Oct 20 23:50:19 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA68215;
Wed, 20 Oct 1999 23:49:59 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id XAA12496;
Wed, 20 Oct 1999 23:49:25 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910210349.XAA12496@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <3804AAC9.FE9FEF75@wgcr.org> from Lamar Owen at "Oct 13,
1999 11:52:41 am"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Wed, 20 Oct 1999 23:49:25 -0400 (EDT)
CC: Dmitry Samersoff <dms@wplus.net>, Vince Vielhaber <vev@michvhf.com>,
Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-documentation <docs@postgreSQL.org>,
"PostgreSQL-development"@candle.pha.pa.us,
pgsql-hackers@postgreSQL.org, Jan Wieck <jwieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Actually, I want to make sure the book is accessible on the web. I will
keep your translation idea in mind. Good point.

Talk to Philip Greenspun. Morgan-Kaufman cut him a deal where his book,
"Philip and Alex's Guide to Web Publishing" is also available free on
the web (http://photo.net/wtr/thebook). His e-mail is philg@mit.edu.

I have this from Addison Wesley. It is online now.

And you gotta see the quality of his book! Amazon carries it.
(although, I must say, some of his choices for pictures were a little
over the top....)

Much thanks for sending me this suggestion.

I read it at:

http://photo.net/wtr/dead-trees/story.html

First, it is very long, so let me give you a quick summary. He did his
first book for MacMillan, which is like Sams, Waite, etc. Basically your
fat book for dummies, and had a pretty terrible experience. You have to
read it to appreciate it. This reminds me of Thomas's comment that we
need a good, quality publisher for our books. If the first book that
came out on PostgreSQL was "PostgreSQL for Dummies", Marc would have a
fit. And I have seen him in fits -- it is not pretty.

He did his second book for Morgan Kaufmann, who is a quality publisher
like Addison Wesley. Totally different experience, and a different
quality book.

This is required reading for anyone who is interested in the book
writing experience or is considering writing a book. People, we need to
stay with the quality publishers, if possible.

I am sure there will be a "PostgreSQL Unleashed" book one day, with tons
of graphic arrows and very little content, but let's put it off as long
as we can.

-- 
  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 Thu Oct 21 02:53:22 1999
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 CAA99703
for <pgsql-hackers@postgresql.org>;
Thu, 21 Oct 1999 02:53:06 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11eC5x-0000hC-0K
for pgsql-hackers@postgreSQL.org; Thu, 21 Oct 1999 06:53:05 +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 JAA30639
for <pgsql-hackers@postgreSQL.org>; Thu, 21 Oct 1999 09:01:12 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5MAD>; Thu, 21 Oct 1999 07:50:56 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E746@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Readline use in trouble?]
Date: Thu, 21 Oct 1999 07:50:46 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

I've just found this on the cygwin list - may be of interest with this
thread.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Earnie Boyd [mailto:earnie_boyd@yahoo.com]
Sent: 20 October 1999 20:39
To: Jim.Fairchild@IndSys.ge.com; cygwin@sourceware.cygnus.com
Subject: Re: Licensing question

--- Jim.Fairchild@IndSys.ge.com wrote:

I have a question regarding the statement, "if you intend to port a
commercial
(non-GPL'd) application using Cygwin, you will need the commercial

license to

Cygwin that comes with the supported native Win32 GNUPro product".

What

licensing restrictions apply if you plan on using the Unix utilities

only,

and
will not be developing applications that use the cygwin? The Unix

utilities

would be used in a commercial application to enable the customer to
transition
from a UNIX system to a Windows NT system.

Notice: This is _not_ Legal Advice. I shall not be held liable for
damages
caused by this response.

IMO, your use of a GPL binary does not cause your commercial package
problems.
If you include a GPL library in your commercial package such as
libreadline.a
then your package must then also be covered by the GPL.

If you distribute a GPL binary then YOU must agree to have the source
available
upon request for three years after the distribution for the version of
the
binary distributed or also distribute the source when you distribute the
binary.

Please, refer to the COPYING document at the http://www.fsf.org site or
should
be found with any GPL distribution. It _is_ the legal document for the
GPL.

=====
Earnie Boyd <mailto:earnie_boyd@yahoo.com>

Newbies, please visit
<http://www.freeyellow.com/members5/gw32/index.html&gt;

(If you respond to the list, then please don't cc me)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

From bouncefilter Thu Oct 21 03:15:21 1999
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 DAA06356
for <pgsql-hackers@postgresql.org>;
Thu, 21 Oct 1999 03:15:09 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11eCRF-0003Ea-0K
for pgsql-hackers@postgreSQL.org; Thu, 21 Oct 1999 07:15:05 +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 JAA30747
for <pgsql-hackers@postgreSQL.org>; Thu, 21 Oct 1999 09:23:12 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5MAK>; Thu, 21 Oct 1999 08:12:55 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E749@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] Readline use in trouble?]
Date: Thu, 21 Oct 1999 08:12:48 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

After sending this, I noticed that here they are not mentioning the LGPL
(used be called the Library GPL, now the Lesser GPL), which covers
linking GPL'ed libraries into non-GPL'ed binaries.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Peter Mount [mailto:petermount@it.maidstone.gov.uk]
Sent: 21 October 1999 07:51
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Readline use in trouble?]

I've just found this on the cygwin list - may be of interest with this
thread.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Earnie Boyd [mailto:earnie_boyd@yahoo.com]
Sent: 20 October 1999 20:39
To: Jim.Fairchild@IndSys.ge.com; cygwin@sourceware.cygnus.com
Subject: Re: Licensing question

--- Jim.Fairchild@IndSys.ge.com wrote:

I have a question regarding the statement, "if you intend to port a
commercial
(non-GPL'd) application using Cygwin, you will need the commercial

license to

Cygwin that comes with the supported native Win32 GNUPro product".

What

licensing restrictions apply if you plan on using the Unix utilities

only,

and
will not be developing applications that use the cygwin? The Unix

utilities

would be used in a commercial application to enable the customer to
transition
from a UNIX system to a Windows NT system.

Notice: This is _not_ Legal Advice. I shall not be held liable for
damages
caused by this response.

IMO, your use of a GPL binary does not cause your commercial package
problems.
If you include a GPL library in your commercial package such as
libreadline.a
then your package must then also be covered by the GPL.

If you distribute a GPL binary then YOU must agree to have the source
available
upon request for three years after the distribution for the version of
the
binary distributed or also distribute the source when you distribute the
binary.

Please, refer to the COPYING document at the http://www.fsf.org site or
should
be found with any GPL distribution. It _is_ the legal document for the
GPL.

=====
Earnie Boyd <mailto:earnie_boyd@yahoo.com>

Newbies, please visit
<http://www.freeyellow.com/members5/gw32/index.html&gt;

(If you respond to the list, then please don't cc me)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

************

From bouncefilter Thu Oct 21 03:34:21 1999
Received: from fep132.fep.ru (mail@[195.230.89.88])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA08326
for <pgsql-hackers@postgresql.org>;
Thu, 21 Oct 1999 03:33:42 -0400 (EDT) (envelope-from phd@phd.russ.ru)
Received: from localhost [127.0.0.1] (phd)
by fep132.fep.ru with esmtp (Exim 2.05 #1 (Debian))
id 11eCin-0003om-00; Thu, 21 Oct 1999 11:33:13 +0400
Date: Thu, 21 Oct 1999 07:33:12 +0000 (GMT)
From: Oleg Broytmann <phd@phd.russ.ru>
X-Sender: phd@fep132.fep.ru
Reply-To: phd2@earthling.net
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Readline use in trouble?]
In-Reply-To: <199910201741.NAA12475@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.20.9910210731020.14659-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 20 Oct 1999, Bruce Momjian wrote:

Does GPL require the source to be included, or just available for free?

Require sources to be available. It is enough to distribute a binary and
provide a pointer to sources. (There are some obscured words that the
pointer should be available for general public...)

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

From bouncefilter Thu Oct 21 05:53:23 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id FAA32577
for <hackers@postgreSQL.org>; Thu, 21 Oct 1999 05:52:55 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 5611 invoked by uid 1001); 21 Oct 1999 09:52:55 -0000
Date: Thu, 21 Oct 1999 05:52:55 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: sszabo@bigpanda.com
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] distinct. Is this the correct behaviour?
In-Reply-To: <199910210240.WAA12470@megazone.bigpanda.com>
Message-ID: <Pine.BSF.4.05.9910210543140.5578-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 20 Oct 1999 sszabo@bigpanda.com wrote:

This seems to generally work in postgres for the simple cases I tried:
select x from foo group by x order by min(y)

Now I don't know if there are any hidden gotchas in that (or wierdness
with the spec), but it also feels better to me than using distinct in this
case as well, because it seems to explicitly describe how you want y
ordered.

Hey! That works! Thanks! Just checked sybase and the original query
acts identical to ours.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Fri Oct 22 14:30:52 1999
Received: from tanja.fam-meskes.de (root@p3E9C146C.dip0.t-ipconnect.de
[62.156.20.108]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA66284
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 14:29:55 -0400 (EDT)
(envelope-from michael@fam-meskes.de)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id PAA00400;
Thu, 21 Oct 1999 15:16:58 +0200
Date: Thu, 21 Oct 1999 15:16:57 +0200
From: Michael Meskes <meskes@postgreSQL.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: Planning final assault on query length limits
Message-ID: <19991021151657.A390@fam-meskes.de>
Mail-Followup-To: Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
References: <12950.940433880@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0pre4i
In-Reply-To: <12950.940433880@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Wed, Oct 20, 1999 at 11:38:00AM -0400

On Wed, Oct 20, 1999 at 11:38:00AM -0400, Tom Lane wrote:

ecpg's lexer needs the same fixes recently applied to parser/scan.l to
eliminate a fixed-size literal buffer and allow flex's input buffer to

I see.

grow as needed. Michael Meskes usually handles ecpg --- Michael, do
you want to deal with this issue or shall I take a cut at it?

I'm currently very busy, so I guess it will take some some until I can
tackle this problem. So if you have some spare time left I have no problem
if you make these changes. Otherwise I will once I find time.

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 Oct 21 09:35:25 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA59415
for <hackers@postgreSQL.org>; Thu, 21 Oct 1999 09:34:29 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA16466;
Thu, 21 Oct 1999 09:32:53 -0400 (EDT)
To: Vince Vielhaber <vev@michvhf.com>
cc: sszabo@bigpanda.com, hackers@postgreSQL.org
Subject: Re: [HACKERS] distinct. Is this the correct behaviour?
In-reply-to: Your message of Thu, 21 Oct 1999 05:52:55 -0400 (EDT)
<Pine.BSF.4.05.9910210543140.5578-100000@paprika.michvhf.com>
Date: Thu, 21 Oct 1999 09:32:53 -0400
Message-ID: <16464.940512773@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Vince Vielhaber <vev@michvhf.com> writes:

Just checked sybase and the original query
acts identical to ours.

Hmph, so sybase hasn't thought through the implications of ORDER BY on
a hidden column vs. DISTINCT either. Can anyone try it on some other
DBMSes?

regards, tom lane

From bouncefilter Thu Oct 21 09:38:26 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA59948
for <hackers@postgreSQL.org>; Thu, 21 Oct 1999 09:38:25 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA16496;
Thu, 21 Oct 1999 09:36:54 -0400 (EDT)
To: sszabo@bigpanda.com
cc: Vince Vielhaber <vev@michvhf.com>, hackers@postgreSQL.org
Subject: Re: [HACKERS] distinct. Is this the correct behaviour?
In-reply-to: Your message of Wed, 20 Oct 1999 22:40:00 -0400
<199910210240.WAA12470@megazone.bigpanda.com>
Date: Thu, 21 Oct 1999 09:36:54 -0400
Message-ID: <16494.940513014@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

sszabo@bigpanda.com writes:

This seems to generally work in postgres for the simple cases I tried:
select x from foo group by x order by min(y)

Now I don't know if there are any hidden gotchas in that (or wierdness
with the spec), but it also feels better to me than using distinct in this
case as well, because it seems to explicitly describe how you want y
ordered.

Yes, I like that better too.

I wonder if we could/should rewrite all uses of DISTINCT into GROUP
BY under-the-hood...

regards, tom lane

From bouncefilter Thu Oct 21 09:50:25 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA61859
for <hackers@postgreSQL.org>; Thu, 21 Oct 1999 09:50:05 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <4YCB08VJ>; Thu, 21 Oct 1999 15:49:16 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C196@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>, sszabo@bigpanda.com
Cc: Vince Vielhaber <vev@michvhf.com>, hackers@postgreSQL.org
Subject: RE: [HACKERS] distinct. Is this the correct behaviour?
Date: Thu, 21 Oct 1999 15:44:40 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Afternoon, all

I just tried this on Oracle, and it wouldn't accept the query. It seems
that once you mention DISTINCT, it won't expand the target list. The actual
message was:

--------------------------------------------------------
SQL> select distinct x from mikea_test order by y;
select distinct x from mikea_test order by y
*
ERROR at line 1:
ORA-01791: not a SELECTed expression
--------------------------------------------------------

So, there we have it. I think this is probably the best solution, because
it means that when you do something where the result is not what you would
expect, it forces you to do it another way.

MikeA

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thursday, October 21, 1999 3:37 PM
To: sszabo@bigpanda.com
Cc: Vince Vielhaber; hackers@postgreSQL.org
Subject: Re: [HACKERS] distinct. Is this the correct behaviour?

sszabo@bigpanda.com writes:

This seems to generally work in postgres for the simple

cases I tried:

select x from foo group by x order by min(y)

Now I don't know if there are any hidden gotchas in that

(or wierdness

with the spec), but it also feels better to me than using

distinct in this

case as well, because it seems to explicitly describe how

you want y

ordered.

Yes, I like that better too.

I wonder if we could/should rewrite all uses of DISTINCT into GROUP
BY under-the-hood...

regards, tom lane

************

From bouncefilter Thu Oct 21 10:44:26 1999
Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net
[207.217.120.22]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA70018;
Thu, 21 Oct 1999 10:43:36 -0400 (EDT)
(envelope-from paul.becker@awl.com)
Received: from georgec (dialup-209.246.84.247.NewYork2.Level3.net
[209.246.84.247])
by hawk.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id HAA21115;
Thu, 21 Oct 1999 07:36:37 -0700 (PDT)
From: "Paul Becker" <paul.becker@awl.com>
To: "'Bruce Momjian'" <maillist@candle.pha.pa.us>,
"'Lamar Owen'" <lamar.owen@wgcr.org>
Cc: "'Dmitry Samersoff'" <dms@wplus.net>,
"'Vince Vielhaber'" <vev@michvhf.com>,
"'Oliver Elphick'" <olly@lfix.co.uk>,
"'PostgreSQL-documentation'" <docs@postgreSQL.org>,
<"PostgreSQL-development"@candle.pha.pa.us>,
<pgsql-hackers@postgreSQL.org>, "'Jan Wieck'" <jwieck@debis.com>
Subject: RE: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
Date: Thu, 21 Oct 1999 10:06:16 -0400
Message-ID: <000101bf1bd1$bf28cc20$f754f6d1@prenhall.com>
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: <199910210349.XAA12496@candle.pha.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

If I may add..

I would highly recommend that you all read Phil Greenspun's story about his
experience in publishing his book with MacMillan. Read between the lines,
however. Where ever reference is made to MacMillan you could substitue
almost <any publisher>. Greenspun is a great story teller so the material is
a good read. I'm sure he embellished a lot on his experiences. He strikes
me as being a puckish kind of guy, somewhat rare amongst engineers. Read
some of his other material. A Day at the Zoo is a good one.

Paul

Paul W. Becker
Addison Wesley Longman
671 Andover Road
Valley Cottage, NY 10989

914-268-8003 (v)
914-268-3874 (f)

Assistant: Ross Venables 781-944-3700 x2501

-----Original Message-----
From: Bruce Momjian [mailto:maillist@candle.pha.pa.us]
Sent: Wednesday, October 20, 1999 11:49 PM
To: Lamar Owen
Cc: Dmitry Samersoff; Vince Vielhaber; Oliver Elphick;
PostgreSQL-documentation; "PostgreSQL-development"@candle.pha.pa.us;
pgsql-hackers@postgreSQL.org; Jan Wieck
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book

Bruce Momjian wrote:

Actually, I want to make sure the book is accessible on the web. I will
keep your translation idea in mind. Good point.

Talk to Philip Greenspun. Morgan-Kaufman cut him a deal where his book,
"Philip and Alex's Guide to Web Publishing" is also available free on
the web (http://photo.net/wtr/thebook). His e-mail is philg@mit.edu.

I have this from Addison Wesley. It is online now.

And you gotta see the quality of his book! Amazon carries it.
(although, I must say, some of his choices for pictures were a little
over the top....)

Much thanks for sending me this suggestion.

I read it at:

http://photo.net/wtr/dead-trees/story.html

First, it is very long, so let me give you a quick summary. He did his
first book for MacMillan, which is like Sams, Waite, etc. Basically your
fat book for dummies, and had a pretty terrible experience. You have to
read it to appreciate it. This reminds me of Thomas's comment that we
need a good, quality publisher for our books. If the first book that
came out on PostgreSQL was "PostgreSQL for Dummies", Marc would have a
fit. And I have seen him in fits -- it is not pretty.

He did his second book for Morgan Kaufmann, who is a quality publisher
like Addison Wesley. Totally different experience, and a different
quality book.

This is required reading for anyone who is interested in the book
writing experience or is considering writing a book. People, we need to
stay with the quality publishers, if possible.

I am sure there will be a "PostgreSQL Unleashed" book one day, with tons
of graphic arrows and very little content, but let's put it off as long
as we can.

--
  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 Thu Oct 21 10:50:26 1999
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA70731
for <hackers@postgresql.org>; Thu, 21 Oct 1999 10:49:29 -0400 (EDT)
(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 QAA27098
for <hackers@postgresql.org>; Thu, 21 Oct 1999 16:48:45 +0200
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXMVN8>; Thu, 21 Oct 1999 16:48:46 +0200
Message-ID:
<219F68D65015D011A8E000006F8590C60339E14C@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas IZ5 <ZeugswetterA@wien.spardat.at>
To: "'hackers@postgresql.org'" <hackers@postgresql.org>
Subject: AW: [HACKERS] distinct. Is this the correct behaviour?
Date: Thu, 21 Oct 1999 16:48:38 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

select distinct f1 from t1 order by f2;

Returned the following message under Oracle8 on NT:
ORA-01791: not a SELECTed expression

Informix: 309: ORDER BY column (f2) must be in SELECT list.

Andreas

From bouncefilter Thu Oct 21 11:10:27 1999
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 LAA73602
for <pgsql-hackers@postgresql.org>;
Thu, 21 Oct 1999 11:09:28 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11eJok-0004bd-0K
for pgsql-hackers@postgreSQL.org; Thu, 21 Oct 1999 15:07:50 +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 RAA32165
for <pgsql-hackers@postgreSQL.org>; Thu, 21 Oct 1999 17:14:52 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5MD1>; Thu, 21 Oct 1999 16:04:26 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E759@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "Pgsql-Hackers (E-mail)" <pgsql-hackers@postgresql.org>
Subject: GPL vs BSD licencing - a new twist
Date: Thu, 21 Oct 1999 16:04:20 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

This was posted on the cygwin list (and cc'd to me) about the GPL and
CygWin:

<quote>
If you use cygwin1.dll in your application then your
application must be made available as open source. The way to avoid
this is to compile your program using the -mno-cygwin option.

If you are only releasing parts of a cygwin release such as cygwin1.dll,
ls.exe, gcc.exe, etc. and you are not compiling any of your own
applications using the DLL then those parts must be made available under
the GPL.
</quote>

How would this affect our Win32 port?

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

From bouncefilter Thu Oct 21 11:11:27 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA74022;
Thu, 21 Oct 1999 11:11:03 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id LAA14899;
Thu, 21 Oct 1999 11:09:43 -0400
Message-ID: <380F2CB1.27DE3A2@wgcr.org>
Date: Thu, 21 Oct 1999 11:09:37 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Becker <paul.becker@awl.com>
CC: "'Bruce Momjian'" <maillist@candle.pha.pa.us>,
"'Dmitry Samersoff'" <dms@wplus.net>,
"'Vince Vielhaber'" <vev@michvhf.com>,
"'Oliver Elphick'" <olly@lfix.co.uk>,
"'PostgreSQL-documentation'" <docs@postgreSQL.org>,
PostgreSQL-development@candle.pha.pa.us, pgsql-hackers@postgreSQL.org,
"'Jan Wieck'" <jwieck@debis.com>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
References: <000101bf1bd1$bf28cc20$f754f6d1@prenhall.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Becker wrote:

a good read. I'm sure he embellished a lot on his experiences. He strikes
me as being a puckish kind of guy, somewhat rare amongst engineers. Read
some of his other material. A Day at the Zoo is a good one.

And "Travels with Samantha" is a hoot. His coding style is very similar
to his writing style -- lispish. But, then again, he's an old-hand MIT
LISP hacker. You should read his tcl one day -- I've laughed till I've
cried over some of his code. (I don't know if that's more of a
statement about his coding style, or about my reading habits.....)

Philip is certainly an interesting writer.

Oh, BTW, Bruce, "You're Welcome."

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Thu Oct 21 11:10:27 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id LAA73628
for <hackers@postgreSQL.org>; Thu, 21 Oct 1999 11:09:51 -0400 (EDT)
(envelope-from vev@michvhf.com)
Received: (qmail 366 invoked by uid 1001); 21 Oct 1999 15:09:50 -0000
Date: Thu, 21 Oct 1999 11:09:50 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: "'hackers@postgresql.org'" <hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] distinct. Is this the correct behaviour?
In-Reply-To:
<219F68D65015D011A8E000006F8590C60339E14C@sdexcsrv1.f000.d0188.sd.spardat.at>
Message-ID: <Pine.BSF.4.05.9910211108470.314-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 21 Oct 1999, Zeugswetter Andreas IZ5 wrote:

select distinct f1 from t1 order by f2;

Returned the following message under Oracle8 on NT:
ORA-01791: not a SELECTed expression

Informix: 309: ORDER BY column (f2) must be in SELECT list.

The version of sybase I tried earlier was 4.9.2. I just tried it
again on 11.5 -- same thing.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Thu Oct 21 11:32:37 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id LAA77530
for <pgsql-hackers@postgreSQL.org>;
Thu, 21 Oct 1999 11:31:58 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 419 invoked by uid 1001); 21 Oct 1999 15:31:57 -0000
Date: Thu, 21 Oct 1999 11:31:56 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Peter Mount <petermount@it.maidstone.gov.uk>
cc: "Pgsql-Hackers \(E-mail\)" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] GPL vs BSD licencing - a new twist
In-Reply-To:
<1B3D5E532D18D311861A00600865478C25E759@exchange1.nt.maidstone.gov.uk>
Message-ID: <Pine.BSF.4.05.9910211131070.314-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 21 Oct 1999, Peter Mount wrote:

If you use cygwin1.dll in your application then your
application must be made available as open source. The way to avoid
this is to compile your program using the -mno-cygwin option.

Out of curiousity, is cygwin open source?

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

From bouncefilter Thu Oct 21 11:38:37 1999
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 LAA78518
for <pgsql-hackers@postgresql.org>;
Thu, 21 Oct 1999 11:38:10 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11eKGB-0007bS-0K; Thu, 21 Oct 1999 15:36:11 +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 RAA32293;
Thu, 21 Oct 1999 17:43:23 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5MDT>; Thu, 21 Oct 1999 16:32:56 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E75C@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Vince Vielhaber'" <vev@michvhf.com>, Peter Mount
<petermount@it.maidstone.gov.uk>
Cc: "Pgsql-Hackers (E-mail)" <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] GPL vs BSD licencing - a new twist
Date: Thu, 21 Oct 1999 16:32:47 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

Most of it, as I've downloaded the source. I think there are some parts
they don't release, but I'm not sure.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Vince Vielhaber [mailto:vev@michvhf.com]
Sent: 21 October 1999 16:32
To: Peter Mount
Cc: Pgsql-Hackers (E-mail)
Subject: Re: [HACKERS] GPL vs BSD licencing - a new twist

On Thu, 21 Oct 1999, Peter Mount wrote:

If you use cygwin1.dll in your application then your
application must be made available as open source. The way to avoid
this is to compile your program using the -mno-cygwin option.

Out of curiousity, is cygwin open source?

Vince.
--
========================================================================
==
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail:
/dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
========================================================================
==

From bouncefilter Thu Oct 21 11:37:37 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA78380
for <hackers@postgreSQL.org>; Thu, 21 Oct 1999 11:36:53 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA17083;
Thu, 21 Oct 1999 11:36:16 -0400 (EDT)
To: "Damond Walker" <dwalker@black-oak.com>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] distinct. Is this the correct behaviour?
In-reply-to: Your message of Thu, 21 Oct 1999 09:57:16 -0700
<00ef01bf1be5$567e4600$af63a8c0@walkers.org>
Date: Thu, 21 Oct 1999 11:36:16 -0400
Message-ID: <17081.940520176@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Damond Walker" <dwalker@black-oak.com> writes:

Returned the following message under MS SQL Server 7.0:
ORDER BY items must appear in the select list if SELECT DISTINCT is
specified.

Sure looks like that is the consensus answer to the semantics problem...
guess we should do the same.

regards, tom lane

From bouncefilter Thu Oct 21 11:56:37 1999
Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar
[200.10.100.10]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA81571
for <pgsql-hackers@postgresql.org>;
Thu, 21 Oct 1999 11:55:59 -0400 (EDT)
(envelope-from fpscha@ns1.via-net-works.net.ar)
Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.8.5/8.8.4)
id MAA00160 for pgsql-hackers@postgresql.org;
Thu, 21 Oct 1999 12:57:11 -0300 (GMT)
From: Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar>
Message-Id: <199910211557.MAA00160@ns1.via-net-works.net.ar>
Subject: [GENERAL] Neverending query on 6.5.0 over Solaris 2.5.1
To: pgsql-hackers@postgresql.org
Date: Thu, 21 Oct 1999 12:57:11 -0300 (GMT)
Reply-To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
X-Mailer: ELM [version 2.4ME+ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hello:
(This is a repost from a mail to -general, as nobody could
answer me, and acording to the Mailing Lists home page, I'm sending it
here.)
Maybe somebody could give some clue about what is happening:

I have 6.5.0 running over Solaris 2.5.1 SPARC. I have a
database with 5 tables, 3 of them < 100 regs. and 2 ("usuarios" and
"passwd") with >10000. When querying for:

SELECT u.nombre_cuenta, per.nombre, pas.clave_cifrada,
pas.clave_plana, u.estado FROM usuarios u, perfiles per, passwd pas
WHERE (u.perfil=per.id_perfil) and (u.id_usr=pas.id_usr) and
(u.activa) \g

postmaster starts eating a lot of CPU and it doesn't finish to
process the query in +20 minutes.

Postmaster shows:
[3]: ns2:/>su - pgsql Sun Microsystems Inc. SunOS 5.5.1 Generic May 1996
Sun Microsystems Inc. SunOS 5.5.1 Generic May 1996
[1]: + Done nohup postmaster -i > pserver.log 2>&1 & $ cat pserver.log IpcMemoryCreate: shmget failed (Invalid argument) key=5432001, size=1073152, permission=600 FATAL 1: ShmemCreate: cannot create region $
/usr/local/pgsql
/data
FindExec: found "/usr/local/pgsql/bin/postgres" using argv[0]
binding ShmemCreate(key=52e2c1, size=359424)
bin/postmaster: ServerLoop: handling reading 5
bin/postmaster: ServerLoop: handling reading 5
bin/postmaster: ServerLoop: handling writing 5
bin/postmaster child[2934]: starting with
(/usr/local/pgsql/bin/postgres -d2
-B 16 -v131072 -p operaciones )
FindExec: found "/usr/local/pgsql/bin/postgres" using argv[0]
debug info:
User = admin
RemoteHost = localhost
RemotePort = 0
DatabaseName = operaciones
Verbose = 2
Noversion = f
timings = f
dates = Normal
bufsize = 16
sortmem = 512
query echo = f
InitPostgres
StartTransactionCommand
bin/postmaster: BackendStartup: pid 2934 user admin db operaciones
socket 5
query: select version();
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: SELECT u.nombre_cuenta, per.nombre, pas.clave_cifrada,
pas.clave_plana, u.estado FROM usuarios u, perfiles per, passwd pas WHERE
(u.perfil=per.id_perfil) and (u.id_usr=pas.id_usr) and (u.activa)
ProcessQuery
bin/postmaster: dumpstatus:
sock 5
bin/postmaster: dumpstatus:
sock 5

Any hints?

TIA and kind regards.

Fernando P. Schapachnik
Administraci�n de la red
VIA Net Works Argentina SA
Diagonal Roque S�enz Pe�a 971, 4� y 5� piso.
1035 - Capital Federal, Argentina.
(54-11) 4323-3333
http://www.via-net-works.net.ar

From bouncefilter Thu Oct 21 12:12:37 1999
Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar
[200.10.100.10]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA84035
for <pgsql-hackers@postgresql.org>;
Thu, 21 Oct 1999 12:12:11 -0400 (EDT)
(envelope-from fpscha@ns1.via-net-works.net.ar)
Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.8.5/8.8.4)
id NAA08685 for pgsql-hackers@postgresql.org;
Thu, 21 Oct 1999 13:13:37 -0300 (GMT)
From: Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar>
Message-Id: <199910211613.NAA08685@ns1.via-net-works.net.ar>
Subject: Neverending query on 6.5.2 over Solaris 2.5.1
To: pgsql-hackers@postgresql.org
Date: Thu, 21 Oct 1999 13:13:37 -0300 (GMT)
Reply-To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
X-Mailer: ELM [version 2.4ME+ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hello:
(This is a repost from a mail to -general, as nobody could
answer me, and acording to the Mailing Lists home page, I'm sending it
here.)
Maybe somebody could give some clue about what is happening:

I have 6.5.0 running over Solaris 2.5.1 SPARC. I have a
database with 5 tables, 3 of them < 100 regs. and 2 ("usuarios" and
"passwd") with >10000. When querying for:

SELECT u.nombre_cuenta, per.nombre, pas.clave_cifrada,
pas.clave_plana, u.estado FROM usuarios u, perfiles per, passwd pas
WHERE (u.perfil=per.id_perfil) and (u.id_usr=pas.id_usr) and
(u.activa) \g

postmaster starts eating a lot of CPU and it doesn't finish to
process the query in +20 minutes.

Postmaster shows:
[3]: ns2:/>su - pgsql Sun Microsystems Inc. SunOS 5.5.1 Generic May 1996
Sun Microsystems Inc. SunOS 5.5.1 Generic May 1996
[1]: + Done nohup postmaster -i > pserver.log 2>&1 & $ cat pserver.log IpcMemoryCreate: shmget failed (Invalid argument) key=5432001, size=1073152, permission=600 FATAL 1: ShmemCreate: cannot create region $
/usr/local/pgsql
/data
FindExec: found "/usr/local/pgsql/bin/postgres" using argv[0]
binding ShmemCreate(key=52e2c1, size=359424)
bin/postmaster: ServerLoop: handling reading 5
bin/postmaster: ServerLoop: handling reading 5
bin/postmaster: ServerLoop: handling writing 5
bin/postmaster child[2934]: starting with
(/usr/local/pgsql/bin/postgres -d2
-B 16 -v131072 -p operaciones )
FindExec: found "/usr/local/pgsql/bin/postgres" using argv[0]
debug info:
User = admin
RemoteHost = localhost
RemotePort = 0
DatabaseName = operaciones
Verbose = 2
Noversion = f
timings = f
dates = Normal
bufsize = 16
sortmem = 512
query echo = f
InitPostgres
StartTransactionCommand
bin/postmaster: BackendStartup: pid 2934 user admin db operaciones
socket 5
query: select version();
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: SELECT u.nombre_cuenta, per.nombre, pas.clave_cifrada,
pas.clave_plana, u.estado FROM usuarios u, perfiles per, passwd pas WHERE
(u.perfil=per.id_perfil) and (u.id_usr=pas.id_usr) and (u.activa)
ProcessQuery
bin/postmaster: dumpstatus:
sock 5
bin/postmaster: dumpstatus:
sock 5

Any hints?

TIA and kind regards.

Fernando P. Schapachnik
Administraci�n de la red
VIA Net Works Argentina SA
Diagonal Roque S�enz Pe�a 971, 4� y 5� piso.
1035 - Capital Federal, Argentina.
(54-11) 4323-3333
http://www.via-net-works.net.ar

From bouncefilter Thu Oct 21 12:57:39 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA92544;
Thu, 21 Oct 1999 12:56:54 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA28495;
Thu, 21 Oct 1999 12:55:56 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910211655.MAA28495@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <380F2CB1.27DE3A2@wgcr.org> from Lamar Owen at "Oct 21,
1999 11:09:37 am"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Thu, 21 Oct 1999 12:55:56 -0400 (EDT)
CC: Paul Becker <paul.becker@awl.com>, "'Dmitry Samersoff'" <dms@wplus.net>,
"'Vince Vielhaber'" <vev@michvhf.com>,
"'Oliver Elphick'" <olly@lfix.co.uk>,
"'PostgreSQL-documentation'" <docs@postgreSQL.org>,
PostgreSQL-development@candle.pha.pa.us, pgsql-hackers@postgreSQL.org,
"'Jan Wieck'" <jwieck@debis.com>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Paul Becker wrote:

a good read. I'm sure he embellished a lot on his experiences. He strikes
me as being a puckish kind of guy, somewhat rare amongst engineers. Read
some of his other material. A Day at the Zoo is a good one.

And "Travels with Samantha" is a hoot. His coding style is very similar
to his writing style -- lispish. But, then again, he's an old-hand MIT
LISP hacker. You should read his tcl one day -- I've laughed till I've
cried over some of his code. (I don't know if that's more of a
statement about his coding style, or about my reading habits.....)

Philip is certainly an interesting writer.

Yes, he was interesting. He clearly caused some of his own problems
with MacMillan, and I agreed with MacMillan on a number of issues.

What I found interesting is something I had suspected for quite some
time. I found that I have some great computer books, but when I go to
the computer section of a book store, most books there are junk.

Then I ordered Knuth's "Art of Computer Programming" directly from
Addison Wesley, and I started receiving their quarterly book bulletins.
I said, "Hey, I read that book, and that one, and that one..." I
realized that most of my books are from a handful of book publishers,
Addison Wesley being the most popular in my bookshelf.

Basically, I realized that not all the publishers are the same. Some
produce quality, and others take a much more marketing slant in book
production, usually producing poor quality books.

One of the reasons I am posting this to the list is so people
considering book writing ( and I know some publishers have been lurking
in the past months), be careful who you sign with. It can affect your
whole outlook on the process, and in the end, it is your name that is on
the cover of the book, not the publisher.

-- 
  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 Thu Oct 21 09:59:26 1999
Received: from bocs170n.black-oak.COM ([38.149.137.131])
by hub.org (8.9.3/8.9.3) with SMTP id JAA63340;
Thu, 21 Oct 1999 09:58:27 -0400 (EDT)
(envelope-from dwalker@black-oak.com)
Received: from gcx80([151.196.99.113]) by BOCS170N.BLACK-OAK.COM (IBM OS/400
SMTP V04R03M00) with TCP; Thu, 21 Oct 1999 09:57:39 -0500
Message-ID: <00ef01bf1be5$567e4600$af63a8c0@walkers.org>
From: "Damond Walker" <dwalker@black-oak.com>
To: <owner-pgsql-hackers@postgreSQL.org>
Cc: <hackers@postgreSQL.org>
References: <2AEBC3A05940F0F685256811004B9692.004BA08485256811@black-oak.com>
Subject: Re: [HACKERS] distinct. Is this the correct behaviour?
Date: Thu, 21 Oct 1999 09:57:16 -0700
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.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

----- Original Message -----

Hmph, so sybase hasn't thought through the implications of ORDER BY on
a hidden column vs. DISTINCT either. Can anyone try it on some other
DBMSes?

Using the following script...

create table t1(f1 int, f2 int);
insert into t1(f1, f2) values(1,1);
insert into t1(f1, f2) values(1,2);
insert into t1(f1, f2) values(1,3);
insert into t1(f1, f2) values(2,4);
select distinct f1 from t1 order by f2;

Returned the following message under Oracle8 on NT:
ORA-01791: not a SELECTed expression

Returned the following message under MS SQL Server 7.0:
ORDER BY items must appear in the select list if SELECT DISTINCT is
specified.

I could try it on Oracle8i but I suspect the result will be the same.

From bouncefilter Thu Oct 21 13:01:38 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA93253
for <hackers@postgreSQL.org>; Thu, 21 Oct 1999 13:00:55 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA28593;
Thu, 21 Oct 1999 12:58:32 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910211658.MAA28593@candle.pha.pa.us>
Subject: Re: [HACKERS] distinct. Is this the correct behaviour?
In-Reply-To: <17081.940520176@sss.pgh.pa.us> from Tom Lane at "Oct 21,
1999 11:36:16 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 21 Oct 1999 12:58:32 -0400 (EDT)
CC: Damond Walker <dwalker@black-oak.com>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

"Damond Walker" <dwalker@black-oak.com> writes:

Returned the following message under MS SQL Server 7.0:
ORDER BY items must appear in the select list if SELECT DISTINCT is
specified.

Sure looks like that is the consensus answer to the semantics problem...
guess we should do the same.

Added to TODO:

* require SELECT DISTINCT target list to have all ORDER BY columns

-- 
  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 Thu Oct 21 13:52:38 1999
Received: from bsdd.regensburg.com (root@bsdd.regensburg.com [194.120.65.5])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA13669
for <pgsql-hackers@hub.org>; Thu, 21 Oct 1999 13:52:11 -0400 (EDT)
(envelope-from darkwing@bsdd.regensburg.com)
Received: from bsdd.regensburg.com (darkwing@localhost)
by bsdd.regensburg.com (8.8.8/8.8.8) with ESMTP id TAA08172
for <pgsql-hackers@hub.org>; Thu, 21 Oct 1999 19:26:21 +0200
X-Mailer: exmh version 2.0.2 2/24/98
To: pgsql-hackers@hub.org
X-Face: >}nUl71id6=N4G1Rc+-C-1[R7(G:I@"Uy'8%\CQ8E&>
-hgd_\@|tS|nn.QKg!q.ew+b@t$N/wG{0GdwJ=&Fk3HwM}'*o6tPc':]-j$;
@+pUSfzja-$"[vyZF`mPgzEyAl'k~,WHq5ZQCX)PmBX8?|x,Xh3wOVL]USn.a{6Bo2SS@lQA%tskThq9eiN#Z>@$MZ5Fw!@|3W~~p!RW^VrnTAJ'|Xx"*Ur("{L$4
Subject: Re: [HACKERS] Readline use in trouble?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 21 Oct 1999 19:26:21 +0200
Message-ID: <8171.940526781@bsdd.regensburg.com>
From: Christoph Hoegl <darkwing@bsdd.regensburg.com>

This discussion really scares me in two ways:
1. U of C licences aren't to be removed or extended (they are still a
copyrighted part themselves)
2. GNU readline is a optional (though convenient) part of postgreSQL
(If someone wants to make money with postgreSQL he simply must not link with
readline)
Best Postgresql Develgroup could do is to mention this fact in INSTALL as well
as README and a configure option called --without-readline (already there)

regards,
Christoph

PS: It really hurts to see UCB and GPL Licences so misunderstood.
Just take them as what they are:
Agreements of the sort: you get something (here: readline) you give sth.
(sourceaccess(GPL)/mention us(UCB/BSD/GPL))
If some people can't agree to some clauses/options it's their problem.

Don't try to find problems when solutions are already implemented
[Stonebraker late 80's]

--
Christoph Hoegl / darkwing@bsdd.regensburg.com
Computer Science and Principle Research (ASNS: darkwing@berkeley.edu)
Siedlungsstr. 18 93128 Regenstauf Germany
12a Tellerrd. 94720 Berkeley CA USA
=> OOOOOOOOOOOOOO = NOW in the "TUNNEL IN NO TIME"-team = OOOOOOOOOOOOOOO =>

From bouncefilter Thu Oct 21 13:43:38 1999
Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA12316
for <pgsql-hackers@postgreSQL.org>;
Thu, 21 Oct 1999 13:43:02 -0400 (EDT)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
LAA00692;
Thu, 21 Oct 1999 11:43:01 -0600 (MDT)
Date: Thu, 21 Oct 1999 11:43:01 -0600 (MDT)
Message-Id: <199910211743.LAA00692@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: Re: [HACKERS] Readline use in trouble?]

As just said, this is a good thing from the point of view of
encouraging participation and commercial success. As long as the open
source version of postgresql remains a well-designed, solid product it
behooves any commercial distributor to aid in its maintenance rather
than take on the whole thing. Ideally, they will contribute any fixes
they make so that all can benefit and perhaps more importantly so they
don't have to maintain the separate fixes any longer.

this assumes an ideal world.

Not entirely. It really assumes that people do a cost-benefit
analysis and recognize that the cost of maintaining a separate
distribution with patches, etc. of something as complex as PostgreSQL
generally far outweighs the benefit of having a global network of
programmers do it for you. Simple economics, not idealism.

look at BSD itself and how it has fragmented, or the plethora of unices and how
the forking there nearly closed the door on wide spread use. the fact of the
matter is, eventually someone/someidiot feels slighted by the community or feels
their ideas are better, no matter WHAT. so they go their own way. they decide to
take the BSD'd source and wander off to their little corner of the world, taking
some of the developers with them.

Look also at Linux and how it has fragmented despite the GPL. There
is not one Linux release, at all, despite the common usage of the term
"Linux" as if that referred to a single entitity. In contrast, the
term "NetBSD", for example, refers to exactly one public release, a
standard and well defined entity that can be readily duplicated.
Indeed, there are likely many more versions of Linux in standard
distribution and use (at least 17 in a recent count) than ALL of the
publicly-released *BSD OSes combined (3).

whilst BSD is less restrictive, its so unrestrictive that it allows people to
set up barriers to the furtherance of the source.

But as long as the publicly available source remains a viable
enterprise (e.g., people see strengths in it and are willing to
contribute time rather than pay for a commercial version) it doesn't
matter if there exist other versions that have been commercialized.

The issue is whether or not PostgreSQL should ALLOW release of binary
versions or not. There are many viable situations in which it is not
feasible or desireable to ship source code, even if the product is
identical to the public source. For example, clients may not care and
may not want to be burdened with it. Or the database may be embedded
within something else in a streamlined system for which there is no
space for source. With the GPL, the producer is required to either
ship the source or maintain all the relevant copies for at least 3
years. That is quite a burden when no one cares to have the source.
In this case the GPL ultimately restricts what can be done in an
economically realistic manner and can lead to stagnation.

In the interests of maximizing the potential marketplace for
PostgreSQL, it seems like the BSD license is in fact superior.

finally, does the BSD liscence further the possibility of commercial adoption?
well. look at Apache. apache has commercial products built on top of
it. PHP4 w/commercial optimizer leaps to mind. and commercial acceptance (e.g.
bundling with other packages that are closed, open, free, for sale, etc) is
quite high.

Both Apache and PHP (both 3 and 4) have BSD-style (not GPL) licences
(though you can choose to abide by the GPL for PHP4, if you want, you
are not required to). Hence, commercial vendors can release binary
products built upon either of these without also releasing the source.
That is likely the main reason these products have been adopted in the
commercial world (given the prerequisite that they are both extremely
high quality products to start with).

the ability to sell a core product directly does NOT create commercial
success. instead, i feel it encourages forking and the removal of that product
from the user base. which is us. remember: greed and pride cause people to do
stupid things.

Clearly the ability to sell something does not create a success. Nor
does it necessarily encourage the forking you seem to think is
inevitable. Your examples above both counter this claim.

that being said.... is it possible to GPL postgresql? probably not, i'd
imagine. how much of the original Berkley source code is there left?

Nor is it desireable, I would argue.

Cheers,
Brook

From bouncefilter Thu Oct 21 15:19:39 1999
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA32309
for <pgsql-hackers@hub.org>; Thu, 21 Oct 1999 15:19:14 -0400 (EDT)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id XAA08607
for <pgsql-hackers@hub.org>; Thu, 21 Oct 1999 23:19:05 +0400 (MSD)
Date: Thu, 21 Oct 1999 23:19:04 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: pgsql-hackers@hub.org
Subject: pq_recvbuf: unexpected EOF on client connection
Message-ID: <Pine.GSO.3.96.SK.991021225654.8622n-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

today I decided to look at postgres log file ( -d 2).
We use postgres as a database backend to apache+modperl server.
I notice messages like:
pq_recvbuf: unexpected EOF on client connection
What does it means ?

StartTransactionCommand
query: select a.msg_id, h.status_set_date, a.title, a.msg_path, c.name from mes
ProcessQuery
CommitTransactionCommand
pq_recvbuf: unexpected EOF on client connection
~~~~~~~~~~~~~~

Also I'm curious about postmaster's activity:

proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
/usr/local/pgsql/bin/postmaster: reaping dead processes...
/usr/local/pgsql/bin/postmaster: CleanupProc: pid 21507 exited with status 0

This message appears too often - I have in httpd.conf
MaxRequestsPerChild 5000, so I expect new httpd children after 5000 requests
and new postgress process accordingly (I use persistent connection
between httpd and postgres).

Regards,

Oleg

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

From bouncefilter Thu Oct 21 15:38:39 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA35534
for <pgsql-hackers@postgreSQL.org>;
Thu, 21 Oct 1999 15:37:52 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id PAA17826;
Thu, 21 Oct 1999 15:31:50 -0400 (EDT)
To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
In-reply-to: Your message of Thu, 21 Oct 1999 13:13:37 -0300 (GMT)
<199910211613.NAA08685@ns1.via-net-works.net.ar>
Date: Thu, 21 Oct 1999 15:31:50 -0400
Message-ID: <17824.940534310@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar> writes:

I have 6.5.0 running over Solaris 2.5.1 SPARC. I have a
database with 5 tables, 3 of them < 100 regs. and 2 ("usuarios" and
"passwd") with >10000. When querying for:

SELECT u.nombre_cuenta, per.nombre, pas.clave_cifrada,
pas.clave_plana, u.estado FROM usuarios u, perfiles per, passwd pas
WHERE (u.perfil=per.id_perfil) and (u.id_usr=pas.id_usr) and
(u.activa) \g

postmaster starts eating a lot of CPU and it doesn't finish to
process the query in +20 minutes.

Have you vacuumed the database lately? What does "explain ..." show
for the query plan being used?

You might be well advised to create indexes on usarios.id_usr and
passwd.id_usr, if you don't have them already. I'd expect this
query to run reasonably quickly using a mergejoin, but mergejoin
needs indexes on the fields being joined. (The system will also
consider doing an explicit sort and then a mergejoin, but obviously
the sort step takes extra time.)

If you haven't vacuumed since filling the tables then the optimizer
may believe that the tables only contain a few rows, in which case
it's likely to use a plain nested-loop join (ie, compare every usarios
row to every passwd row to find matching id_usr fields). That's nice
and fast for little tables, but a big loser on big ones...

regards, tom lane

From bouncefilter Thu Oct 21 16:35:40 1999
Received: from mail.texoma.net (mail.texoma.net [209.151.96.3])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA43762
for <pgsql-general@postgreSQL.org>;
Thu, 21 Oct 1999 16:34:56 -0400 (EDT)
(envelope-from jhouchin@texoma.net)
Received: from texoma.net (ppp-151-100-072.texoma.net [209.151.100.72])
by mail.texoma.net (Postfix) with ESMTP id 2D5B015ED63
for <pgsql-general@postgreSQL.org>;
Thu, 21 Oct 1999 15:34:54 -0500 (CDT)
Message-ID: <380F78C7.6976A819@texoma.net>
Date: Thu, 21 Oct 1999 15:34:15 -0500
From: Jimmie Houchin <jhouchin@texoma.net>
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-general@postgreSQL.org" <pgsql-general@postgreSQL.org>
Subject: What's WAL (wasRe: [GENERAL] Postgres INSERTs much slower than
MySQL?)
References: <3.0.5.32.19991020122550.008bf780@pop.mecomb.po.my>
<6CF4B3E5928@ahorn.sgh.uunet.de>
<m11c7sz-00080dC@mailbox.reptiles.org>
<111F0F713069@ahorn.sgh.uunet.de>
<3.0.5.32.19991020153812.008c4620@pop.mecomb.po.my>
<3.0.5.32.19991020163318.0087e140@pop.mecomb.po.my>
<3.0.5.32.19991021090815.008cb370@pop.mecomb.po.my>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've seen WAL mentioned several times, but have yet to see anything
about what it is.

Help! :)

What is WAL? Or is it something that is only known by the Illuminati? :)

I did a search in the archives and came up empty, no hits. Not even the
messages which only mention it. Nothing, nada, zip, no "gee I'm banging
my head against the wall trying..." or anything else.

After having read some of the messages in the archives today I have a
confession.

I am very much pro Linux, *BSDs, et al, but I do most of my web browsing
at work on a Win95 machine using Netscape. I know it's scary, but I am
not trying to be. Please forgive me. If at all possible I will try to
atone by installing RH 6.x on my machine at work, if I can do it where
my boss can boot (from a shutdown machine) into windows without knowing
Linux exists. :)

Thanks,

Jimmie Houchin

Lincoln Yeoh wrote:

At 04:38 PM 20-10-1999 +0800, Vadim Mikheev wrote:

Hope that it will be much faster when WAL will be implemented...

What's WAL? Is postgres going to be faster than MySQL? That would be pretty
impressive- transactions and all. Woohoo!

Hope it doesn't stand for Whoops, All's Lost :).

Cheerio,

Link.

From bouncefilter Thu Oct 21 18:49:42 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA61853
for <pgsql-hackers@hub.org>; Thu, 21 Oct 1999 18:49:18 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA18564;
Thu, 21 Oct 1999 18:47:54 -0400 (EDT)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] pq_recvbuf: unexpected EOF on client connection
In-reply-to: Your message of Thu, 21 Oct 1999 23:19:04 +0400 (MSD)
<Pine.GSO.3.96.SK.991021225654.8622n-100000@ra>
Date: Thu, 21 Oct 1999 18:47:54 -0400
Message-ID: <18562.940546074@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Oleg Bartunov <oleg@sai.msu.su> writes:

I notice messages like:
pq_recvbuf: unexpected EOF on client connection
What does it means ?

Means your client closed the connection without sending a "terminate"
message first, ie, you didn't close down libpq gracefully. It's harmless
enough, although I think having the log message is a good idea. (If you
use clients that are careful to do PQfinish() then you can use the
postmaster log to check for client crashes.)

Also I'm curious about postmaster's activity:

proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
/usr/local/pgsql/bin/postmaster: reaping dead processes...
/usr/local/pgsql/bin/postmaster: CleanupProc: pid 21507 exited with status 0

This message appears too often - I have in httpd.conf
MaxRequestsPerChild 5000, so I expect new httpd children after 5000 requests
and new postgress process accordingly (I use persistent connection
between httpd and postgres).

Well, that's certainly the trace of a backend quitting. I'd say your
httpd stuff isn't working the way you think it is...

regards, tom lane

PS: I didn't hear back from you about INTERSECT/LIMIT --- is that still
broken for you? I can't find anything wrong with it here.

From bouncefilter Fri Oct 22 20:14:56 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA11270
for <pgsql-hackers@postgresql.org>;
Fri, 22 Oct 1999 20:14:12 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:2597 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s2Dr341281>;
Sat, 23 Oct 1999 02:13:57 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11eShO-0000j8-00; Fri, 22 Oct 1999 02:36:50 +0200
Date: Fri, 22 Oct 1999 02:36:50 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] New psql startup banner
In-Reply-To: <199910210042.UAA04085@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.9910220228200.1833-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 20, Bruce Momjian mentioned:

psql now shows new text on startup. The old one just looked bad.
Hope the psql upgrader can merge these changes in. I know we weren't
supposed to touch psql, but I suspect he is not touching the banner.

Hah!

$ ./psql template1
Welcome to psql, the PostgreSQL interactive query shell.
(Please type \copyright to see the distribution terms of PostgreSQL.)
PostgreSQL 6.5.2 on i586-pc-linux-gnu, compiled by egcs

Type \h for help with SQL commands,
\? for help on internal slash commands,
\q to quit,
\g or terminate with semicolon to execute query.
template1=> \copyright
memory clobbered before allocated blockAborted (core dumped)

Oops! :)

Okay, I guess the motivation behind this was the question "Where is that
damn COPYRIGHT file?", or maybe I've just been reading the appendix to the
GPL too often.

Anyway, I guess I'll let the balance of the suggestions apply.

-Peter

---------------------------------------------------------------------------

OLD:

Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL

NEW:

Welcome to the PostgreSQL interactive terminal.
(Please read the copyright file for legal issues.)

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Thu Oct 21 22:25:43 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA18508;
Thu, 21 Oct 1999 22:24:52 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id KAA06197;
Fri, 22 Oct 1999 10:17:21 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380FC931.EB9DDFA5@krs.ru>
Date: Fri, 22 Oct 1999 10:17:21 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Brook Milligan <brook@biology.nmsu.edu>, maillist@candle.pha.pa.us,
meskes@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Planning final assault on query length limits
References: <13724.940445266@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Brook Milligan <brook@biology.nmsu.edu> writes:

Jan, does this mean that we can also lose the "rewrite string too big"
problem with rules?

No. We have to have long tuples.

Darn. Oh well, I guess this is a major step in that direction.

I'm hoping that once this is done, someone who knows the guts of the
storage managers better than I will feel motivated to work on letting
stored tuples cross block boundaries. (Paging Vadim...) That seems
to be the last piece of the puzzle.

You know that I'm busy with WAL...
And I already made some step in big tuples dirrection
when made memory/disk tuple presentations different -:)

typedef struct HeapTupleData
{
uint32 t_len; /* length of *t_data */
ItemPointerData t_self; /* SelfItemPointer */
HeapTupleHeader t_data; /* */
^^^^^^^^^^^^^^^^^^^^^^
On-disk data

} HeapTupleData;

I hope that something could be added here for tuple chunks...
TupleTableSlot.ttc_buffer (and ttc_shouldFree?) is good candidate
to be moved here from TupleTableSlot.

As for smgr part - it's not hard at all.

Vadim

From bouncefilter Thu Oct 21 23:43:41 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA28987
for <pgsql-hackers@postgreSQL.org>;
Thu, 21 Oct 1999 23:43:31 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id XAA19481
for <pgsql-hackers@postgreSQL.org>;
Thu, 21 Oct 1999 23:42:28 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Planning final assault on query length limits
In-reply-to: Your message of Fri, 22 Oct 1999 10:17:21 +0800
<380FC931.EB9DDFA5@krs.ru>
Date: Thu, 21 Oct 1999 23:42:28 -0400
Message-ID: <19478.940563748@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Vadim Mikheev <vadim@krs.ru> writes:

Tom Lane wrote:

I'm hoping that once this is done, someone who knows the guts of the
storage managers better than I will feel motivated to work on letting
stored tuples cross block boundaries. (Paging Vadim...) That seems
to be the last piece of the puzzle.

You know that I'm busy with WAL...

Well, Vadim doesn't want to do it, and I don't want to do it (I've
really got to spend some more time on the planner/optimizer, because
there's too much stuff half-fixed in there).

Any volunteers out there? It'd be a shame to not have this problem
area completely licked for 7.0.

regards, tom lane

From bouncefilter Fri Oct 22 00:14:42 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA36809
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 00:14:13 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id AAA26447;
Fri, 22 Oct 1999 00:12:29 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910220412.AAA26447@candle.pha.pa.us>
Subject: Re: [HACKERS] Planning final assault on query length limits
In-Reply-To: <19478.940563748@sss.pgh.pa.us> from Tom Lane at "Oct 21,
1999 11:42:28 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 22 Oct 1999 00:12:29 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Vadim Mikheev <vadim@krs.ru> writes:

Tom Lane wrote:

I'm hoping that once this is done, someone who knows the guts of the
storage managers better than I will feel motivated to work on letting
stored tuples cross block boundaries. (Paging Vadim...) That seems
to be the last piece of the puzzle.

You know that I'm busy with WAL...

Well, Vadim doesn't want to do it, and I don't want to do it (I've
really got to spend some more time on the planner/optimizer, because
there's too much stuff half-fixed in there).

Any volunteers out there? It'd be a shame to not have this problem
area completely licked for 7.0.

Welcome to the small club, Tom. For the first 2 & 1/2 years, the only
person who could tackle those big jobs was Vadim. Now you are in the
club too.

The problem is that there are no more. I can't imagine anyone is going
to be able to jump out of the woodwork and take on a job like that. We
will just have to do the best job we can, and maybe save something for
7.1.

-- 
  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 Fri Oct 22 00:55:42 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA42650
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 00:54:52 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id MAA07504;
Fri, 22 Oct 1999 12:54:28 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380FEE04.51D6E3AD@krs.ru>
Date: Fri, 22 Oct 1999 12:54:28 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Planning final assault on query length limits
References: <199910220412.AAA26447@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

You know that I'm busy with WAL...

Well, Vadim doesn't want to do it, and I don't want to do it (I've
really got to spend some more time on the planner/optimizer, because
there's too much stuff half-fixed in there).

Any volunteers out there? It'd be a shame to not have this problem
area completely licked for 7.0.

Welcome to the small club, Tom. For the first 2 & 1/2 years, the only
person who could tackle those big jobs was Vadim. Now you are in the
club too.

The problem is that there are no more. I can't imagine anyone is going
to be able to jump out of the woodwork and take on a job like that. We
will just have to do the best job we can, and maybe save something for
7.1.

There is Jan!...
But he's busy too -:)

Let's wait for 7.0 beta - "big tuples" seems as work for 2 weeks...

Vadim

From bouncefilter Fri Oct 22 01:01:43 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA43629
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 01:01:12 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id MAA07609;
Fri, 22 Oct 1999 12:59:54 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380FEF4A.437C1D18@krs.ru>
Date: Fri, 22 Oct 1999 12:59:54 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Lamar Owen <lamar.owen@wgcr.org>
CC: Vince Vielhaber <vev@michvhf.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Peter Mount <petermount@it.maidstone.gov.uk>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
References: <Pine.BSF.4.05.9910201050230.3530-100000@paprika.michvhf.com>
<380DF16C.8993F594@wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lamar Owen wrote:

Vince Vielhaber wrote:

Items in the contrib section aren't required for the use of PostgreSQL,
however PostgreSQL *is* required to use those items. So shouldn't the
items in contrib have to change to a Berkeley style license? :)

I mean it's only fair!

I know of at least two items in contrib that are required to run the
regression tests -- which, arguably, make PostgreSQL require those two
components (autoinc and refint).

Well, I made them... so you know what copyright is... -:)

Vadim

From bouncefilter Fri Oct 22 01:25:43 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA46287
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 01:24:44 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id BAA27041;
Fri, 22 Oct 1999 01:22:22 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910220522.BAA27041@candle.pha.pa.us>
Subject: Re: [HACKERS] Planning final assault on query length limits
In-Reply-To: <380FEE04.51D6E3AD@krs.ru> from Vadim Mikheev at "Oct 22,
1999 12:54:28 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Fri, 22 Oct 1999 01:22:22 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

The problem is that there are no more. I can't imagine anyone is going
to be able to jump out of the woodwork and take on a job like that. We
will just have to do the best job we can, and maybe save something for
7.1.

There is Jan!...
But he's busy too -:)

Let's wait for 7.0 beta - "big tuples" seems as work for 2 weeks...

Oops, forgot about him. Sorry Jan.

-- 
  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 Fri Oct 22 01:53:44 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA49440;
Fri, 22 Oct 1999 01:53:33 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id NAA07911;
Fri, 22 Oct 1999 13:52:41 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <380FFBA8.82447656@krs.ru>
Date: Fri, 22 Oct 1999 13:52:40 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Lincoln Yeoh <lylyeoh@mecomb.com>
CC: pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [GENERAL] Postgres INSERTs much slower than MySQL?
References: <3.0.5.32.19991020122550.008bf780@pop.mecomb.po.my>
<6CF4B3E5928@ahorn.sgh.uunet.de>
<m11c7sz-00080dC@mailbox.reptiles.org>
<111F0F713069@ahorn.sgh.uunet.de>
<3.0.5.32.19991020153812.008c4620@pop.mecomb.po.my>
<3.0.5.32.19991020163318.0087e140@pop.mecomb.po.my>
<3.0.5.32.19991021090815.008cb370@pop.mecomb.po.my>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lincoln Yeoh wrote:

At 04:38 PM 20-10-1999 +0800, Vadim Mikheev wrote:

You hit buffer manager/disk manager problems or eat all disk space.
As for "modifying" - I meant insertion, deletion, update...

There was enough disk space (almost another gig more). So it's probably
some buffer manager problem. Is that the postgres buffer manager or is it a
Linux one?

Are you able to duplicate that problem? All I did was to turn off
autocommit and start inserting.

I created table with text column and inserted 1000000 rows
with '!' x rand(256) without problems on Sun Ultra, 6.5.2
I run postmaster only with -S flag.
And while inserting I run select count(*) from _table_
in another session from time to time - wonder what was
returned all the time before commit? -:))

Well anyway the Postgres inserts aren't so much slower if I only commit
once in a while. Only about 3 times slower for the first 100,000 records.
So the subject line is now inaccurate :). Not bad, I like it.

Hope that it will be much faster when WAL will be implemented...

What's WAL? Is postgres going to be faster than MySQL? That would be pretty

^^^^^^^^^^^^^^^^^^^^^^^
No.

impressive- transactions and all. Woohoo!

WAL is Write Ahead Log, transaction logging.
This will reduce # of fsyncs (among other things) Postgres has
to perform now.
Test above took near 38 min without -F flag and 24 min
with -F (no fsync at all).
With WAL the same test without -F will be near as fast as with
-F now.

But what makes me unhappy right now is that with -F COPY FROM takes
JUST 3 min !!! (And 16 min without -F)
Isn't parsing/planning overhead toooo big ?!

Vadim

From bouncefilter Fri Oct 22 03:01:47 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA62491;
Fri, 22 Oct 1999 03:01:21 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id CAA28175;
Fri, 22 Oct 1999 02:04:10 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910220604.CAA28175@candle.pha.pa.us>
Subject: Re: [GENERAL] Postgres INSERTs much slower than MySQL?
In-Reply-To: <380FFBA8.82447656@krs.ru> from Vadim Mikheev at "Oct 22,
1999 01:52:40 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Fri, 22 Oct 1999 02:04:09 -0400 (EDT)
CC: Lincoln Yeoh <lylyeoh@mecomb.com>, pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

WAL is Write Ahead Log, transaction logging.
This will reduce # of fsyncs (among other things) Postgres has
to perform now.
Test above took near 38 min without -F flag and 24 min
with -F (no fsync at all).
With WAL the same test without -F will be near as fast as with
-F now.

But what makes me unhappy right now is that with -F COPY FROM takes
JUST 3 min !!! (And 16 min without -F)
Isn't parsing/planning overhead toooo big ?!

Yikes. I always thought it would be nice to try and cache query plans
by comparing parse trees, and if they match cached versions, replace any
constants with new ones and use cached query plan. Hard to do right,
though.

-- 
  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 Fri Oct 22 02:06:43 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA51445
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 02:05:55 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id CAA19861;
Fri, 22 Oct 1999 02:04:30 -0400 (EDT)
To: Vadim Mikheev <vadim@krs.ru>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Planning final assault on query length limits
In-reply-to: Your message of Fri, 22 Oct 1999 12:54:28 +0800
<380FEE04.51D6E3AD@krs.ru>
Date: Fri, 22 Oct 1999 02:04:29 -0400
Message-ID: <19859.940572269@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Vadim Mikheev <vadim@krs.ru> writes:

Bruce Momjian wrote:

Any volunteers out there? It'd be a shame to not have this problem
area completely licked for 7.0.

Welcome to the small club, Tom. For the first 2 & 1/2 years, the only
person who could tackle those big jobs was Vadim. Now you are in the
club too.

The problem is that there are no more. I can't imagine anyone is going
to be able to jump out of the woodwork and take on a job like that. We
will just have to do the best job we can, and maybe save something for
7.1.

There is Jan!...
But he's busy too -:)

Let's wait for 7.0 beta - "big tuples" seems as work for 2 weeks...

Thing is, if Vadim could do it in two weeks (sounds about right), then
maybe I could do it in three or four (I'd have to spend time studying
parts of the backend that Vadim already knows, but I don't). It seems
to me that some aspiring hacker who's already a little bit familiar
with backend coding could do it in a month or two, with suitable study,
and would in the process make great strides towards gurudom. This is
a fairly localized task, if I'm not greatly mistaken about it. And
there's plenty of time left before 7.0. So this seems like a perfect
project for someone who wants to learn more about the backend and has
some time to spend doing so.

A year ago I didn't know a darn thing about the backend, so I'm a bit
bemused to find myself being called a member of "the small club".
Programming skills don't come out of nowhere, they come out of study
and practice. (See http://www.tuxedo.org/~esr/faqs/loginataka.html)

In short, I'd like to see the club get bigger...

regards, tom lane

From bouncefilter Fri Oct 22 02:27:43 1999
Received: from outthere.thinx.ch (root@outthere.thinx.ch [194.158.233.34])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA54820
for <pgsql-general@hub.org>; Fri, 22 Oct 1999 02:27:13 -0400 (EDT)
(envelope-from Christian.Rudow@thinx.ch)
Received: from iraeugst.net.thinx.ch (root@[212.74.36.228])
by outthere.thinx.ch (8.9.2/8.9.2) with ESMTP id HAA14837;
Fri, 22 Oct 1999 07:20:04 +0200 (CEST)
Received: from thinx.ch (chris@acer.net.thinx.ch [192.168.0.33])
by iraeugst.net.thinx.ch (8.8.8/8.8.8) with ESMTP id HAA01703;
Fri, 22 Oct 1999 07:20:40 +0200
Sender: chris@iraeugst.net.thinx.ch
Message-ID: <3810034F.8ED0341E@thinx.ch>
Date: Fri, 22 Oct 1999 08:25:19 +0200
From: Christian Rudow <Christian.Rudow@thinx.ch>
Organization: ThinX
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Jimmie Houchin <jhouchin@texoma.net>
CC: PostgreSQL General <pgsql-general@hub.org>
Subject: Re: What's WAL
References: <3.0.5.32.19991020122550.008bf780@pop.mecomb.po.my>
<6CF4B3E5928@ahorn.sgh.uunet.de>
<m11c7sz-00080dC@mailbox.reptiles.org>
<111F0F713069@ahorn.sgh.uunet.de>
<3.0.5.32.19991020153812.008c4620@pop.mecomb.po.my>
<3.0.5.32.19991020163318.0087e140@pop.mecomb.po.my>
<3.0.5.32.19991021090815.008cb370@pop.mecomb.po.my>
<380F78C7.6976A819@texoma.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jimmie Houchin wrote:

What is WAL? Or is it something that is only known by the Illuminati? :)

I understand your fears. I can also not follow all that the
linux cracks around me are talking about.

I also was still using a Windows workstation for quite some
time, when we had already started our almost-linux-only startup
business writing Perl apps for PG.

And I still have a dual boot laptop allowing me to use Win98
and IE5.0 when I cannot get internet banking to work under linux
or I want to watch a DVD movie or do some other multimedia stuff
that I don't understand what it does and only want to enjoy.

I'm not one of the guys who enjoy configuring linux for two
days to get some device working. No it rather scares me.
I enjoy to have working solutions though. (I also never looked
closely at the motors inside of any of the cars I owned).

But what I learned is, that still you have to do some learning.
You do it involuntarily as a Windows user. Linux gives you the
freedom to do it on your free choice - having great support
from a lot of people who really know what they are doing.

So - get down from envying the "Illuminati" - build up a working
linux configuration - step by step - slowly. And ... if you are one of
the less brighter guy's like me - don't ask for too much at one
time.

E.g.
I still don't use an Office Suite under Linux. So I made a (very
basic) installation of Samba and use an old laptop with Win95 and
my Office97 Software on the Linux shares.
No sweat. And no apologies necessary.
There's nothing to be ashamed of to be a Windows user. Being a
Linux user can sometimes make you a little proud, though. That's
a difference.

So lets just think that WAL means : use "Windows And Linux".

Good Luck !
Chris
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Christian Rudow E-Mail: Christian.Rudow@thinx.ch
ThinX networked business services Stahlrain 10, CH-5200 Brugg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From bouncefilter Fri Oct 22 02:56:44 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA58213
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 02:55:57 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id OAA08191;
Fri, 22 Oct 1999 14:45:53 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <3810081E.16702D8D@krs.ru>
Date: Fri, 22 Oct 1999 14:45:50 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Planning final assault on query length limits
References: <19859.940572269@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Let's wait for 7.0 beta - "big tuples" seems as work for 2 weeks...

Thing is, if Vadim could do it in two weeks (sounds about right), then
maybe I could do it in three or four (I'd have to spend time studying
parts of the backend that Vadim already knows, but I don't). It seems
to me that some aspiring hacker who's already a little bit familiar
with backend coding could do it in a month or two, with suitable study,
and would in the process make great strides towards gurudom. This is
a fairly localized task, if I'm not greatly mistaken about it. And

^^^^^^^^^^^^^^
I'm not sure. Seems that we'll have to change heap_getattr:
if a column crosses page boundary then we'll have to re-construct
it in memory and pfree it after using...

there's plenty of time left before 7.0. So this seems like a perfect
project for someone who wants to learn more about the backend and has
some time to spend doing so.

And we always ready to help...

A year ago I didn't know a darn thing about the backend, so I'm a bit
bemused to find myself being called a member of "the small club".
Programming skills don't come out of nowhere, they come out of study
and practice. (See http://www.tuxedo.org/~esr/faqs/loginataka.html)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:)))

Vadim

From bouncefilter Fri Oct 22 03:13:44 1999
Received: from sasami.jurai.net (winter@sasami.jurai.net [63.67.141.99])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA64564
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 03:12:58 -0400 (EDT)
(envelope-from winter@jurai.net)
Received: from localhost (winter@localhost)
by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id DAA22586;
Fri, 22 Oct 1999 03:12:11 -0400 (EDT)
Date: Fri, 22 Oct 1999 03:12:11 -0400 (EDT)
From: "Matthew N. Dodd" <winter@jurai.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Readline use in trouble?
In-Reply-To: <199910191341.JAA23790@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910220311270.480-100000@sasami.jurai.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Oct 1999, Bruce Momjian wrote:

Removal of readline would certainly affect psql users.

The actual file is gs5.94/doc/Make.htm.1

One could always switch to libedit, which is BSD licensed. Its not yet
ported to as many platforms as readline though...

--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever |

From bouncefilter Fri Oct 22 03:48:44 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA69259
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 03:48:23 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <4YCB09NW>; Fri, 22 Oct 1999 09:47:41 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C198@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Planning final assault on query length limits
Date: Fri, 22 Oct 1999 09:43:01 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Well, I'm doing the pg_dump thing at the moment. If nobody has stepped up
to the plate by the time I'm finished, and if nobody objects to my style too
much (Tom, comments from the psql changes?), I'll have a shot. This was the
reason that I started on the query string limit in the first place, anyway.

I'll be slowing right up on my day job at the end of next week, so I should
have a fair amount of time to stick into it for a couple of weeks after
that, which should be enough to get pg_dump finished.

MikeA

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, October 22, 1999 8:04 AM
To: Vadim Mikheev
Cc: Bruce Momjian; pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Planning final assault on query length limits

Vadim Mikheev <vadim@krs.ru> writes:

Bruce Momjian wrote:

Any volunteers out there? It'd be a shame to not have

this problem

area completely licked for 7.0.

Welcome to the small club, Tom. For the first 2 & 1/2

years, the only

person who could tackle those big jobs was Vadim. Now

you are in the

club too.

The problem is that there are no more. I can't imagine

anyone is going

to be able to jump out of the woodwork and take on a job

like that. We

will just have to do the best job we can, and maybe save

something for

7.1.

There is Jan!...
But he's busy too -:)

Let's wait for 7.0 beta - "big tuples" seems as work for 2 weeks...

Thing is, if Vadim could do it in two weeks (sounds about
right), then
maybe I could do it in three or four (I'd have to spend time studying
parts of the backend that Vadim already knows, but I don't).
It seems
to me that some aspiring hacker who's already a little bit familiar
with backend coding could do it in a month or two, with
suitable study,
and would in the process make great strides towards gurudom. This is
a fairly localized task, if I'm not greatly mistaken about it. And
there's plenty of time left before 7.0. So this seems like a perfect
project for someone who wants to learn more about the backend and has
some time to spend doing so.

A year ago I didn't know a darn thing about the backend, so I'm a bit
bemused to find myself being called a member of "the small club".
Programming skills don't come out of nowhere, they come out of study
and practice. (See http://www.tuxedo.org/~esr/faqs/loginataka.html)

In short, I'd like to see the club get bigger...

regards, tom lane

************

From bouncefilter Fri Oct 22 04:15:45 1999
Received: from pdm.pvt.net (qmailr@pdm.pvt.net [194.149.103.204])
by hub.org (8.9.3/8.9.3) with SMTP id EAA72065
for <pgsql-hackers@hub.org>; Fri, 22 Oct 1999 04:15:09 -0400 (EDT)
(envelope-from pdm@pvt.net)
Received: (qmail 12627 invoked by uid 1000); 22 Oct 1999 08:15:07 -0000
Sender: pdm@pdm.pvt.net
Original-Sender: pdm@debian.cz
From: Milan Zamazal <pdm@debian.cz>
To: Christoph Hoegl <darkwing@bsdd.regensburg.com>
Cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] Readline use in trouble?
References: <8171.940526781@bsdd.regensburg.com>
X-Face: #G'i>Q>~:^*=!qpsXTU;
iEZ8xcAz+u~Vq0(<P>a6!3ebS/2|\r{9&asz&Qp]~)uF,N"4,jS
T&F>.|='gO6:N<FD-e0EI5.+#BblSdQ!$7ZC'3m/6m4edq-E&nU+R%<!V&MXqR<W5RIISsd?Q6]Ig]
V4|Y_QsT/c$EX1WqSYQizlNDh,krFL=uX6OQU?N[wW(8'3[cMK$w
Date: 22 Oct 1999 10:15:07 +0200
In-Reply-To: Christoph Hoegl's message of "Thu, 21 Oct 1999 19:26:21 +0200"
Message-ID: <871zann75g.fsf@pdm.pvt.net>
Lines: 12
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"CH" == Christoph Hoegl <darkwing@bsdd.regensburg.com> writes:

CH> 2. GNU readline is a optional (though convenient) part of
CH> postgreSQL (If someone wants to make money with postgreSQL he
CH> simply must not link with readline)

Just for exactness: readline doesn't prevent you to make money with
anything, it only states licensing conditions (these are two quite
different things).

Milan Zamazal

From bouncefilter Fri Oct 22 08:48:47 1999
Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar
[200.10.100.10]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA08819
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 08:47:57 -0400 (EDT)
(envelope-from fpscha@ns1.via-net-works.net.ar)
Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.8.5/8.8.4)
id JAA01480; Fri, 22 Oct 1999 09:38:36 -0300 (GMT)
From: Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar>
Message-Id: <199910221238.JAA01480@ns1.via-net-works.net.ar>
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
In-Reply-To: <17824.940534310@sss.pgh.pa.us> from Tom Lane at "Oct 21,
99 03:31:50 pm"
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Fri, 22 Oct 1999 09:38:35 -0300 (GMT)
Cc: fpscha@via-net-works.net.ar, pgsql-hackers@postgreSQL.org
Reply-To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
X-Mailer: ELM [version 2.4ME+ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

En un mensaje anterior, Tom Lane escribi�:

Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar> writes:

I have 6.5.0 running over Solaris 2.5.1 SPARC. I have a
database with 5 tables, 3 of them < 100 regs. and 2 ("usuarios" and
"passwd") with >10000. When querying for:

SELECT u.nombre_cuenta, per.nombre, pas.clave_cifrada,
pas.clave_plana, u.estado FROM usuarios u, perfiles per, passwd pas
WHERE (u.perfil=per.id_perfil) and (u.id_usr=pas.id_usr) and
(u.activa) \g

postmaster starts eating a lot of CPU and it doesn't finish to
process the query in +20 minutes.

Have you vacuumed the database lately? What does "explain ..." show

I did this today. I also installed Postgres on a FreeBSD machine
(comparable -and low- load averages) and updated the version to 6.5.2.

After vacuum:
On the Sun: 1 minute.
On the FreeBSD: 12 seconds.

Explain shows (on both machines):

operaciones=> explain SELECT u.nombre_cuenta, per.nombre,
pas.clave_cifrada, pas.clave_plana, u.estado FROM usuarios u, perfiles per,
passwd pas WHERE (u.activa) and (u.perfil=per.id_perfil) and
(u.id_usr=pas.id_usr) \g
NOTICE: QUERY PLAN:

Nested Loop (cost=503.74 rows=1 width=74)
-> Nested Loop (cost=500.89 rows=1 width=58)
-> Seq Scan on usuarios u (cost=498.84 rows=1 width=30)
-> Index Scan using passwd_id_usr_key on passwd pas
(cost=2.05 rows=10571 width=28)
-> Seq Scan on perfiles per (cost=2.85 rows=56 width=16)

EXPLAIN

You might be well advised to create indexes on usarios.id_usr and
passwd.id_usr, if you don't have them already. I'd expect this

As usuarios.id_usr and passwd.id_usr are both serial, they have
indexes automatically created (I double checked that). PgAccess shows
that usuarios has no primary key (I don't know why) and that
usuarios_id_usr_key is an unique, no clustered index. Same on passwd.

I'm running postmaster -N 8 -B 16 because whitout these postmaster
wouldn't get all the shared memory it needed and won't start. Do you
think that this may be in some way related?

Thanks for your help!

Fernando P. Schapachnik
Administraci�n de la red
VIA Net Works Argentina SA
Diagonal Roque S�enz Pe�a 971, 4� y 5� piso.
1035 - Capital Federal, Argentina.
(54-11) 4323-3333
http://www.via-net-works.net.ar

From bouncefilter Fri Oct 22 10:50:49 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA25920
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 10:50:01 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA20409;
Fri, 22 Oct 1999 10:48:51 -0400 (EDT)
To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
In-reply-to: Your message of Fri, 22 Oct 1999 09:38:35 -0300 (GMT)
<199910221238.JAA01480@ns1.via-net-works.net.ar>
Date: Fri, 22 Oct 1999 10:48:51 -0400
Message-ID: <20407.940603731@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar> writes:

postmaster starts eating a lot of CPU and it doesn't finish to
process the query in +20 minutes.

Have you vacuumed the database lately? What does "explain ..." show

After vacuum:
On the Sun: 1 minute.
On the FreeBSD: 12 seconds.

That's a little better, anyway ...

Explain shows (on both machines):

Nested Loop (cost=503.74 rows=1 width=74)
-> Nested Loop (cost=500.89 rows=1 width=58)
-> Seq Scan on usuarios u (cost=498.84 rows=1 width=30)
-> Index Scan using passwd_id_usr_key on passwd pas
(cost=2.05 rows=10571 width=28)
-> Seq Scan on perfiles per (cost=2.85 rows=56 width=16)

OK, that still looks a little bogus. It's estimating it will only
find one row in usarios that needs to be joined against the other
two tables. If that were true, then this plan is pretty reasonable,
but I bet it's not true. The only WHERE clause that can be used to
eliminate usarios rows in advance of the join is (u.activa), and I'll
bet you have more than one active user.

Does the plan change if you do VACUUM ANALYZE instead of just a plain
vacuum?

As usuarios.id_usr and passwd.id_usr are both serial, they have
indexes automatically created (I double checked that). PgAccess shows
that usuarios has no primary key (I don't know why) and that
usuarios_id_usr_key is an unique, no clustered index. Same on passwd.

OK, so it *could* make a mergejoin plan without sorting. I think the
problem is the unreasonably low estimate for number of matching usarios
rows; that makes the nested-loop plan look cheap because of its lower
startup overhead. But if there's a lot of usarios rows to process then
it's not so cheap anymore.

As an experiment you could try forbidding nestloop plans (start psql
with environment variable PGOPTIONS="-fn") and see what sort of plan
you get then and how long it really takes in comparison to the nestloop.
This isn't a good long-term solution, because you might get poor plans
for smaller queries, but it would help us see whether and how the
planner is making the wrong choice. (I've been trying to collect
examples of poor planning so that I can improve the planner --- so
I'm quite interested in the details of your situation.)

I'm running postmaster -N 8 -B 16 because whitout these postmaster
wouldn't get all the shared memory it needed and won't start. Do you
think that this may be in some way related?

Well, that's certainly costing you performance; 16 disk pages is not
enough buffer space to avoid thrashing. You need to increase your
kernel's max-shared-memory-block-size (SHMMAX, I think) parameter
so that you can run with a more reasonable -B setting. A lot of
kernels ship with SHMMAX settings that are ridiculously small for
any modern machine.

regards, tom lane

From bouncefilter Fri Oct 22 11:09:50 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA28810;
Fri, 22 Oct 1999 11:09:47 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA20508;
Fri, 22 Oct 1999 11:08:01 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Vadim Mikheev <vadim@krs.ru>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Postgres INSERTs much slower than MySQL?
In-reply-to: Your message of Fri, 22 Oct 1999 02:04:09 -0400 (EDT)
<199910220604.CAA28175@candle.pha.pa.us>
Date: Fri, 22 Oct 1999 11:08:01 -0400
Message-ID: <20506.940604881@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <maillist@candle.pha.pa.us> writes:

But what makes me unhappy right now is that with -F COPY FROM takes
JUST 3 min !!! (And 16 min without -F)
Isn't parsing/planning overhead toooo big ?!

Yikes. I always thought it would be nice to try and cache query plans
by comparing parse trees, and if they match cached versions, replace any
constants with new ones and use cached query plan. Hard to do right,
though.

But INSERT ... VALUES(...) has such a trivial plan that it's hardly
likely to be worth caching. We probably ought to do some profiling to
see where the time is going, and see if we can't speed things up for
this simple case.

In the meantime, the conventional wisdom is still that you should use
COPY, if possible, for bulk data loading. (If you need default values
inserted in some columns then this won't do...)

regards, tom lane

From bouncefilter Fri Oct 22 11:22:50 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA31095
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 11:21:53 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA20556;
Fri, 22 Oct 1999 11:15:41 -0400 (EDT)
To: Vadim Mikheev <vadim@krs.ru>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Planning final assault on query length limits
In-reply-to: Your message of Fri, 22 Oct 1999 14:45:50 +0800
<3810081E.16702D8D@krs.ru>
Date: Fri, 22 Oct 1999 11:15:41 -0400
Message-ID: <20554.940605341@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Vadim Mikheev <vadim@krs.ru> writes:

a fairly localized task, if I'm not greatly mistaken about it. And

^^^^^^^^^^^^^^
I'm not sure. Seems that we'll have to change heap_getattr:
if a column crosses page boundary then we'll have to re-construct
it in memory and pfree it after using...

I was thinking more along the lines of reconstructing the whole tuple
in palloc'd memory and leaving heap_getattr as-is. Otherwise we have
problems with the system relations whose tuples are accessed as C
structs. You'd need to somehow guarantee that those tuples are never
split if you do it as above.

Of course, that just moves the palloc/pfree bookkeeping problem down
a level; it's still going to be tricky to avoid storage leaks.
We might be able to get some win from storing reassembled tuples in
TupleTableSlots, though.

there's plenty of time left before 7.0. So this seems like a perfect
project for someone who wants to learn more about the backend and has
some time to spend doing so.

And we always ready to help...

Right. Questions can be answered.

regards, tom lane

From bouncefilter Fri Oct 22 11:17:50 1999
Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar
[200.10.100.10]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA30174
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 11:16:51 -0400 (EDT)
(envelope-from fpscha@ns1.via-net-works.net.ar)
Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.8.5/8.8.4)
id MAA19232; Fri, 22 Oct 1999 12:16:23 -0300 (GMT)
From: Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar>
Message-Id: <199910221516.MAA19232@ns1.via-net-works.net.ar>
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
In-Reply-To: <20407.940603731@sss.pgh.pa.us> from Tom Lane at "Oct 22,
99 10:48:51 am"
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Fri, 22 Oct 1999 12:16:23 -0300 (GMT)
Cc: fpscha@via-net-works.net.ar, pgsql-hackers@postgreSQL.org
Reply-To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
X-Mailer: ELM [version 2.4ME+ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

En un mensaje anterior, Tom Lane escribi�:

Explain shows (on both machines):

Nested Loop (cost=503.74 rows=1 width=74)
-> Nested Loop (cost=500.89 rows=1 width=58)
-> Seq Scan on usuarios u (cost=498.84 rows=1 width=30)
-> Index Scan using passwd_id_usr_key on passwd pas
(cost=2.05 rows=10571 width=28)
-> Seq Scan on perfiles per (cost=2.85 rows=56 width=16)

OK, that still looks a little bogus. It's estimating it will only
find one row in usarios that needs to be joined against the other
two tables. If that were true, then this plan is pretty reasonable,
but I bet it's not true. The only WHERE clause that can be used to
eliminate usarios rows in advance of the join is (u.activa), and I'll
bet you have more than one active user.

That's right!

Does the plan change if you do VACUUM ANALYZE instead of just a plain
vacuum?

Sorry for not being clear enough, but that was what I did.

As an experiment you could try forbidding nestloop plans (start psql
with environment variable PGOPTIONS="-fn") and see what sort of plan
you get then and how long it really takes in comparison to the nestloop.

I took 30 seconds on the Sun, and explain shows:

NOTICE: QUERY PLAN:

Merge Join (cost=1314.02 rows=1 width=74)
-> Seq Scan (cost=1297.56 rows=1 width=58)
-> Sort (cost=1297.56 rows=1 width=58)
-> Hash Join (cost=1296.56 rows=1 width=58)
-> Seq Scan on passwd pas (cost=447.84
rows=10571 width=28)
-> Hash (cost=498.84 rows=1 width=30)
-> Seq Scan on usuarios u (cost=498.84
rows=1 width=30)
-> Seq Scan (cost=14.58 rows=56 width=16)
-> Sort (cost=14.58 rows=56 width=16)
-> Seq Scan on perfiles per (cost=2.85 rows=56 width=16)

EXPLAIN

I'm running postmaster -N 8 -B 16 because whitout these postmaster
wouldn't get all the shared memory it needed and won't start. Do you
think that this may be in some way related?

Well, that's certainly costing you performance; 16 disk pages is not
enough buffer space to avoid thrashing. You need to increase your
kernel's max-shared-memory-block-size (SHMMAX, I think) parameter
so that you can run with a more reasonable -B setting. A lot of
kernels ship with SHMMAX settings that are ridiculously small for
any modern machine.

Ok, I'll try to increase it.

Regards.

Fernando P. Schapachnik
Administraci�n de la red
VIA Net Works Argentina SA
Diagonal Roque S�enz Pe�a 971, 4� y 5� piso.
1035 - Capital Federal, Argentina.
(54-11) 4323-3333
http://www.via-net-works.net.ar

From bouncefilter Fri Oct 22 11:17:50 1999
Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar
[200.10.100.10]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA30203
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 11:17:14 -0400 (EDT)
(envelope-from fpscha@ns1.via-net-works.net.ar)
Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.8.5/8.8.4)
id MAA20930; Fri, 22 Oct 1999 12:18:31 -0300 (GMT)
From: Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar>
Message-Id: <199910221518.MAA20930@ns1.via-net-works.net.ar>
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
In-Reply-To: <20407.940603731@sss.pgh.pa.us> from Tom Lane at "Oct 22,
99 10:48:51 am"
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Fri, 22 Oct 1999 12:18:30 -0300 (GMT)
Cc: fpscha@via-net-works.net.ar, pgsql-hackers@postgreSQL.org
Reply-To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
X-Mailer: ELM [version 2.4ME+ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

En un mensaje anterior, Tom Lane escribi�:

I'm running postmaster -N 8 -B 16 because whitout these postmaster
wouldn't get all the shared memory it needed and won't start. Do you
think that this may be in some way related?

Well, that's certainly costing you performance; 16 disk pages is not
enough buffer space to avoid thrashing. You need to increase your
kernel's max-shared-memory-block-size (SHMMAX, I think) parameter
so that you can run with a more reasonable -B setting. A lot of
kernels ship with SHMMAX settings that are ridiculously small for
any modern machine.

What value would you advise for shmmax?

Regards.

Fernando P. Schapachnik
Administraci�n de la red
VIA Net Works Argentina SA
Diagonal Roque S�enz Pe�a 971, 4� y 5� piso.
1035 - Capital Federal, Argentina.
(54-11) 4323-3333
http://www.via-net-works.net.ar

From bouncefilter Fri Oct 22 11:33:50 1999
Received: from mail.texoma.net (mail.texoma.net [209.151.96.3])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA35330
for <pgsql-general@hub.org>; Fri, 22 Oct 1999 11:33:12 -0400 (EDT)
(envelope-from jhouchin@texoma.net)
Received: from texoma.net (ppp-151-101-176.texoma.net [209.151.101.176])
by mail.texoma.net (Postfix) with ESMTP
id 778F915ED1C; Fri, 22 Oct 1999 10:33:09 -0500 (CDT)
Message-ID: <3810838B.A19203A7@texoma.net>
Date: Fri, 22 Oct 1999 10:32:27 -0500
From: Jimmie Houchin <jhouchin@texoma.net>
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Rudow <Christian.Rudow@thinx.ch>
Cc: PostgreSQL General <pgsql-general@hub.org>
Subject: Re: [GENERAL] Re: What's WAL
References: <3.0.5.32.19991020122550.008bf780@pop.mecomb.po.my>
<6CF4B3E5928@ahorn.sgh.uunet.de>
<m11c7sz-00080dC@mailbox.reptiles.org>
<111F0F713069@ahorn.sgh.uunet.de>
<3.0.5.32.19991020153812.008c4620@pop.mecomb.po.my>
<3.0.5.32.19991020163318.0087e140@pop.mecomb.po.my>
<3.0.5.32.19991021090815.008cb370@pop.mecomb.po.my>
<380F78C7.6976A819@texoma.net> <3810034F.8ED0341E@thinx.ch>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

Thanks for the reply.

Actually I don't fear Linux, I embrace it. :)
I am quite proficient with Windows but have never considered myself a
Windows user. I don't own a Windows machine and currently have no
intentions of it. I do however use it a work because my boss wanted a
machine which could play DOOM. :(

I own 4 Macs at home, one of which I have LinuxPPC installed. I will be
purchasing an Athlon PC this winter for my own use. I will install RH
6.x on it. I have never really put too much thought on installing Linux
on my PC at work. There are only 2 employees here and one computer. My
boss is not computer proficient. He plays games, primarily solitaire. I
run the computer and the business uses. Whatever I do Linux wise, I
wanted it to be reasonably transparent to his usage, which is minimal.
I'll install Mandrake Linux and put a games folder in the "Start" menu
and put solitaire inside of it. He might not ever even no I'm no longer
in Windows. :)
However, when I'm not in the office and the computer is shutdown I
wanted him to be able to start up the computer and boot straight into
windows. Typing "win" at a prompt might lose him. :)

I don't envy the Illuminati, only their understanding of what WAL is. :)

I really wasn't apologizing for being a Windows user, only for using
Windows. :)
It is a totally involuntary action.

I am ready for the day when there is enough educational and edutainment
software to be available that I can use Linux for my children computers.
We use computer extensively in their education. But for now it'll be the
MacOS. Someday if I get permission from my wife I'll install Linux and
either Sheepshaver or Mac-on-Linux.

Thanks for the opportunity for fun off topic banter. Now back to the
show. I'll keep an eye on the Illuminati and maybe one of them will slip
and reveal the meaning of the Great WAL of PostgreSQL. :)

Later,

Jimmie Houchin

Christian Rudow wrote:

Jimmie Houchin wrote:

What is WAL? Or is it something that is only known by the Illuminati? :)

I understand your fears. I can also not follow all that the
linux cracks around me are talking about.

I also was still using a Windows workstation for quite some
time, when we had already started our almost-linux-only startup
business writing Perl apps for PG.

And I still have a dual boot laptop allowing me to use Win98
and IE5.0 when I cannot get internet banking to work under linux
or I want to watch a DVD movie or do some other multimedia stuff
that I don't understand what it does and only want to enjoy.

I'm not one of the guys who enjoy configuring linux for two
days to get some device working. No it rather scares me.
I enjoy to have working solutions though. (I also never looked
closely at the motors inside of any of the cars I owned).

But what I learned is, that still you have to do some learning.
You do it involuntarily as a Windows user. Linux gives you the
freedom to do it on your free choice - having great support
from a lot of people who really know what they are doing.

So - get down from envying the "Illuminati" - build up a working
linux configuration - step by step - slowly. And ... if you are one of
the less brighter guy's like me - don't ask for too much at one
time.

E.g.
I still don't use an Office Suite under Linux. So I made a (very
basic) installation of Samba and use an old laptop with Win95 and
my Office97 Software on the Linux shares.
No sweat. And no apologies necessary.
There's nothing to be ashamed of to be a Windows user. Being a
Linux user can sometimes make you a little proud, though. That's
a difference.

So lets just think that WAL means : use "Windows And Linux".

Good Luck !
Chris
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Christian Rudow E-Mail: Christian.Rudow@thinx.ch
ThinX networked business services Stahlrain 10, CH-5200 Brugg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

************

From bouncefilter Fri Oct 22 11:35:50 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA35891
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 11:35:05 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA20679;
Fri, 22 Oct 1999 11:33:56 -0400 (EDT)
To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
In-reply-to: Your message of Fri, 22 Oct 1999 12:18:30 -0300 (GMT)
<199910221518.MAA20930@ns1.via-net-works.net.ar>
Date: Fri, 22 Oct 1999 11:33:56 -0400
Message-ID: <20677.940606436@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar> writes:

enough buffer space to avoid thrashing. You need to increase your
kernel's max-shared-memory-block-size (SHMMAX, I think) parameter
so that you can run with a more reasonable -B setting. A lot of
kernels ship with SHMMAX settings that are ridiculously small for
any modern machine.

What value would you advise for shmmax?

Well, with the default number of buffers (64) Postgres requires about
a megabyte (I think a tad over 1Mb, in 6.5.*). Extra buffers are 8K
plus a little overhead apiece. If you are running with more than a
couple of active backends at a time then you probably want to use
more than the default number of buffers. But I have no advice on
how many is appropriate for what size of installation --- can anyone
else help?

regards, tom lane

From bouncefilter Fri Oct 22 11:57:50 1999
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 LAA40032
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 11:57:24 -0400 (EDT) (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 LAA21603
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 11:57:11 -0400 (EDT)
Date: 22 Oct 1999 11:57:11 -0400
Message-ID: <emacs-smtp-11255-14352-35159-445918@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: <20677.940606436@sss.pgh.pa.us>
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
References: <20677.940606436@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_Oct_22_11:57:10_1999-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit

--pgp-sign-Multipart_Fri_Oct_22_11:57:10_1999-1
Content-Type: text/plain; charset=US-ASCII

Then <tgl@sss.pgh.pa.us> spoke up and said:

Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar> writes:

What value would you advise for shmmax?

more than the default number of buffers. But I have no advice on
how many is appropriate for what size of installation --- can anyone
else help?

Unless you are severely resource constrained, think big. Generally
speaking, the kilobytes of memory you'll lose to kernel structures are
irrelevant. Performance is generally not an issue, either.

--
=====================================================================
| 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_Oct_22_11:57:10_1999-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

iQBVAwUBOBCJV4dzVnzma+gdAQHmVgH/aSxqRSvjRZPbV5julV65b/p5rhH3+ABL
bUm8lumbbb1QfT0ROWfa3a1c15hicfjA0Za1ml2A+OcCzufP4oJM3w==
=KZDG
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Fri_Oct_22_11:57:10_1999-1--

From bouncefilter Fri Oct 22 12:03:50 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA40924
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 12:03:01 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA20860;
Fri, 22 Oct 1999 12:01:57 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Current sources fail if two 'serial' columns in one table
Date: Fri, 22 Oct 1999 12:01:57 -0400
Message-ID: <20857.940608117@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

With current sources,

regression=> create table xx (f1 int, f2 serial, f3 serial);
NOTICE: CREATE TABLE will create implicit sequence 'xx_f2_seq' for SERIAL column 'xx.f2'
NOTICE: CREATE TABLE will create implicit sequence 'xx_f3_seq' for SERIAL column 'xx.f3'
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'xx_f2_key' for table 'xx'
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'xx_f3_key' for table 'xx'
CREATE
regression=> insert into xx values(1);
ERROR: Relation 'xx_f2_seq' does not exist
regression=>

6.5.2 fails to do the CREATE TABLE at all. I'm betting this is related
to the multiple-unique-index bug that you thought you had fixed.

regards, tom lane

From bouncefilter Fri Oct 22 12:06:50 1999
Received: from noether.math.ksu.edu (noether.math.ksu.edu [129.130.6.19])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA41571
for <pgsql-general@hub.org>; Fri, 22 Oct 1999 12:05:53 -0400 (EDT)
(envelope-from jamest@math.ksu.edu)
Received: from hobbes.math.ksu.edu (hobbes.math.ksu.edu [129.130.6.20])
by noether.math.ksu.edu (Postfix) with ESMTP
id 4AE381A42C; Fri, 22 Oct 1999 11:05:52 -0500 (CDT)
Date: Fri, 22 Oct 1999 11:05:52 -0500 (CDT)
From: James Thompson <jamest@math.ksu.edu>
To: Jimmie Houchin <jhouchin@texoma.net>
Cc: Christian Rudow <Christian.Rudow@thinx.ch>,
PostgreSQL General <pgsql-general@hub.org>
Subject: Re: [GENERAL] Re: What's WAL
In-Reply-To: <3810838B.A19203A7@texoma.net>
Message-ID: <Pine.LNX.4.10.9910221103410.1757-100000@hobbes.math.ksu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Thanks for the opportunity for fun off topic banter. Now back to the
show. I'll keep an eye on the Illuminati and maybe one of them will slip
and reveal the meaning of the Great WAL of PostgreSQL. :)

I pulled this from dejanews as the postgresql list archieve search is
down. I have no idea who said it......

WAL is Write Ahead Log, transaction logging. This will reduce # of fsyncs
(among other things) Postgres has to perform now.

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561
Kansas State University Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

From bouncefilter Fri Oct 22 12:21:57 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA44800
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 12:21:37 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA20890;
Fri, 22 Oct 1999 12:20:26 -0400 (EDT)
To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
In-reply-to: Your message of Fri, 22 Oct 1999 12:16:23 -0300 (GMT)
<199910221516.MAA19232@ns1.via-net-works.net.ar>
Date: Fri, 22 Oct 1999 12:20:26 -0400
Message-ID: <20888.940609226@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar> writes:

As an experiment you could try forbidding nestloop plans (start psql
with environment variable PGOPTIONS="-fn") and see what sort of plan
you get then and how long it really takes in comparison to the nestloop.

I took 30 seconds on the Sun, and explain shows:

Better, but still not good.

NOTICE: QUERY PLAN:

Merge Join (cost=1314.02 rows=1 width=74)
-> Seq Scan (cost=1297.56 rows=1 width=58)
-> Sort (cost=1297.56 rows=1 width=58)
-> Hash Join (cost=1296.56 rows=1 width=58)
-> Seq Scan on passwd pas (cost=447.84 rows=10571 width=28)
-> Hash (cost=498.84 rows=1 width=30)
-> Seq Scan on usuarios u (cost=498.84 rows=1 width=30)
-> Seq Scan (cost=14.58 rows=56 width=16)
-> Sort (cost=14.58 rows=56 width=16)
-> Seq Scan on perfiles per (cost=2.85 rows=56 width=16)

It's still convinced it's only going to get one row out of usuarios.
Weird. I assume that your 'activa' field is 'bool'? I've been trying
to duplicate this misbehavior here, and as near as I can tell the system
handles selectivity estimates for boolean fields just fine. Whatever
percentage of 't' values was seen by the last VACUUM ANALYZE is exactly
what it uses.

I am using 6.5.2 and current sources, though, and in your original
message you said you were on 6.5.0. If that's right, seems like the
first thing to try is for you to update to 6.5.2, run another VACUUM
ANALYZE, and then see if you still get the same bogus row estimates.

The other odd thing about the above plan is that it's doing an
explicit sort on perfiles. Didn't you say that you had an index on
perfiles.id_perfil? It should be scanning that instead of doing
a sort, I'd think. (However, if there really are only 56 rows in
perfiles, it probably doesn't matter.)

regards, tom lane

From bouncefilter Fri Oct 22 12:27:51 1999
Received: from mail.texoma.net (mail.texoma.net [209.151.96.3])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA46024
for <pgsql-general@hub.org>; Fri, 22 Oct 1999 12:27:09 -0400 (EDT)
(envelope-from jhouchin@texoma.net)
Received: from texoma.net (ppp-151-101-176.texoma.net [209.151.101.176])
by mail.texoma.net (Postfix) with ESMTP
id 37CE315ED48; Fri, 22 Oct 1999 11:27:07 -0500 (CDT)
Message-ID: <38109032.FE135446@texoma.net>
Date: Fri, 22 Oct 1999 11:26:26 -0500
From: Jimmie Houchin <jhouchin@texoma.net>
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: James Thompson <jamest@math.ksu.edu>
Cc: Christian Rudow <Christian.Rudow@thinx.ch>,
PostgreSQL General <pgsql-general@hub.org>
Subject: Re: [GENERAL] Re: What's WAL
References: <Pine.LNX.4.10.9910221103410.1757-100000@hobbes.math.ksu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

Thanks,

Yes, the Illuminati has spoken. :)

The quote is from Vadim in the "Re: [GENERAL] Postgres INSERTs much
slower than MySQL?" thread.
After I sent my message and continued reading the new messages in my
box, I read the post to which you refer.

Now the intrigue is over. I are educated. :)

I was not aware that DejaNews had the postgresql mailing lists. I'll
have to look into this.

Thanks.

Jimmie Houchin

James Thompson wrote:

Thanks for the opportunity for fun off topic banter. Now back to the
show. I'll keep an eye on the Illuminati and maybe one of them will slip
and reveal the meaning of the Great WAL of PostgreSQL. :)

I pulled this from dejanews as the postgresql list archieve search is
down. I have no idea who said it......

WAL is Write Ahead Log, transaction logging. This will reduce # of fsyncs
(among other things) Postgres has to perform now.

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561
Kansas State University Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

From bouncefilter Fri Oct 22 13:16:51 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA55748
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 13:16:48 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id NAA20997;
Fri, 22 Oct 1999 13:15:09 -0400 (EDT)
To: Fernando Schapachnik <fpscha@via-net-works.net.ar>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
In-reply-to: Your message of Fri, 22 Oct 1999 12:20:26 -0400
<20888.940609226@sss.pgh.pa.us>
Date: Fri, 22 Oct 1999 13:15:09 -0400
Message-ID: <20995.940612509@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I wrote:

Weird. I assume that your 'activa' field is 'bool'? I've been trying
to duplicate this misbehavior here, and as near as I can tell the system
handles selectivity estimates for boolean fields just fine. Whatever
percentage of 't' values was seen by the last VACUUM ANALYZE is exactly
what it uses.

On second thought: 6.5.* can get confused if the column contains more
NULLs than anything else. Dunno if you have a lot of nulls in activa,
but if so you might try changing them all to explicit 'f' and then
redoing the VACUUM ANALYZE. Next release will be smarter about keeping
stats in the presence of many nulls.

It'd be useful to double-check my theory that the system is
misestimating the selectivity of the WHERE (u.activa) clause.
You could try this:
SELECT count(*) FROM usarios WHERE activa;
EXPLAIN SELECT count(*) FROM usarios WHERE activa;
and see how far off the row count estimate in the EXPLAIN is
from reality.

regards, tom lane

From bouncefilter Fri Oct 22 13:14:51 1999
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 NAA55246
for <pgsql-hackers@postgresql.org>;
Fri, 22 Oct 1999 13:14:16 -0400 (EDT)
(envelope-from peter@retep.org.uk)
Received: from maidast.demon.co.uk ([158.152.22.37] helo=maidast.retep.org.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11eiGb-000PS2-0K; Fri, 22 Oct 1999 17:14:14 +0000
Received: from localhost (peter@localhost [127.0.0.1])
by maidast.retep.org.uk (8.9.3/8.9.3) with ESMTP id SAA28512;
Fri, 22 Oct 1999 18:15:13 +0100
Date: Fri, 22 Oct 1999 18:15:13 +0100 (GMT)
From: Peter Mount <peter@retep.org.uk>
To: Vince Vielhaber <vev@michvhf.com>
cc: Peter Mount <petermount@it.maidstone.gov.uk>,
"Pgsql-Hackers (E-mail)" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] GPL vs BSD licencing - a new twist
In-Reply-To: <Pine.BSF.4.05.9910211131070.314-100000@paprika.michvhf.com>
Message-ID: <Pine.LNX.4.10.9910221814160.28260-100000@maidast.retep.org.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 21 Oct 1999, Vince Vielhaber wrote:

On Thu, 21 Oct 1999, Peter Mount wrote:

If you use cygwin1.dll in your application then your
application must be made available as open source. The way to avoid
this is to compile your program using the -mno-cygwin option.

Out of curiousity, is cygwin open source?

Earlier today I found out that yes, cygwin is open source. However, they
have some similarities with Aladin where cygwin is used in embeded
applications as well.

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 Fri Oct 22 16:14:53 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id QAA83085
for pgsql-hackers@postgresql.org; Fri, 22 Oct 1999 16:13:57 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
Message-ID: <3810C755.C93C9CE8@cpsgroup.com>
Date: Fri, 22 Oct 1999 15:21:42 -0500
From: Bryan Ingram <bingram@cpsgroup.com>
Reply-To: bingram@cpsgroup.com
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
X-Newsgroups: comp.databases.postgresql.hackers
Subject: postgres inode q's
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: 22 Oct 1999 15:09:27 -0500, 216.207.61.67
Lines: 62
X-Authenticated-User: boneyjames
X-Report: Report abuse to abuse@newsfeeds.com
X-Abuse-Info: Please be sure to forward a copy of ALL headers,
INCLUDING the body
X-Abuse-Info2: ALL Spam complaints are acted upon within 24 hours!
Organization: Newsfeeds.com http://www.newsfeeds.com 60,
000+ UNCENSORED Newsgroups.
To: pgsql-hackers@postgresql.org

I apologize if this is the wrong group for this message, but I'm not
sure where else this would go.

I don't have a specific problem, but I would like to ask some questions
about how postgres works.

But first, some backfground info:
I have two identical servers each running postgres 6.5.1 and each has an
identical database called zipfind. This is a pretty static, mostly read
only database with 700,000 rows. A few days ago I got some updated
information for the database, 1,400,000 rows worth, almost double the
data in ascii format.

So, I got the new rows inserted with a perl script which read the ascii
file line by line and inserted the data. This took quite a while, in
fact, it took more than 24 hours. So, I decided I would update the
second database in a different way.

I realized I could pg_dump the new zipfind database, and read it back in
using psql on the other machine, but I decided to try it a little
differently, just to see what would happen.

What I tried was to move the actual data files in the data/base/zipfind
directory from the newly updated database directly to the machine still
in need of updating. I shutdown postmaster on the machine that I was
moving the files to, replaced all of the files in the zipfind directory
with the files from the machine with all the new rows, reset all the
permissions, and restarted postmaster.

The strange thing is, even though the old files were removed and
replaced with the new files using identical file names, psql seemed to
be reading data from the old database as if it had not been removed.
issuing a "select count(*) from zips;" returned the old row count 666730
instead of the new row count ca 1400000 ... if anything I expected to
get some kind of error ..not the old row count!

I checked the filesizes in the zipfind directory to make sure I hadn't
made a mistake while putting the new data in place. Everything was
correct. I then vacuumed the database and rechecked the file sizes. ..
the "zips" table entry now reported the old file size!

It occurred to me that there may be some system tables which were
causing the erratic behaviour, I searched for something relevant but
found nothing.

The only theory that I could come up with was that postgres latched on
to an inode for the original files ..but how it would keep that inode
info across daemon invocations seems a mystery to me.

Explanations appreciated!

Thanks,
Bryan

-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----

From bouncefilter Fri Oct 22 17:13:54 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id RAA90185
for <pgsql-hackers@postgresql.org>;
Fri, 22 Oct 1999 17:12:57 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgresql.org
id m11elvg-0003kLC; Fri, 22 Oct 99 23:08 MET DST
Message-Id: <m11elvg-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] postgres inode q's
To: bingram@cpsgroup.com
Date: Fri, 22 Oct 1999 23:08:52 +0200 (MET DST)
Cc: pgsql-hackers@postgresql.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <3810C755.C93C9CE8@cpsgroup.com> from "Bryan Ingram" at Oct 22,
99 03:21:42 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bryan Ingram wrote:

I apologize if this is the wrong group for this message, but I'm not
sure where else this would go.

Topshot - absolutely the right group.

I don't have a specific problem, but I would like to ask some questions
about how postgres works.

But first, some backfground info:
I have two identical servers each running postgres 6.5.1 and each has an
identical database called zipfind. This is a pretty static, mostly read
...

It occurred to me that there may be some system tables which were
causing the erratic behaviour, I searched for something relevant but
found nothing.

Warm, warm, hot - missed!

The only theory that I could come up with was that postgres latched on
to an inode for the original files ..but how it would keep that inode
info across daemon invocations seems a mystery to me.

Deep frozen :-)

I assume from this description, that one of the servers is
created more or less by a similar copy operation, but that
time it was the entire ./data directory that got copied, or
maybe the entire installation directory - right? If not, the
two installations must have been treated absolutely identical
until all the data was inserted into the zipfind databases.

Anyway, the system file causing this is pg_log. It's not a
table, it's a bitmap telling which transaction have committed
and which ones not. There are some transaction ID fields in
the header information of each data tuple in PostgreSQL. One
tells in which transaction this tuple appeared, and the other
when it disappeared. But they are ignored if the transaction
in question isn't marked as committed in pg_log. So on a
DELETE operation, the deleted tuples simply get the DELETE's
transaction ID stamped into the ending field, and on an
UPDATE, the same is done and a new tuple with this XID as the
beginning is appended at the end of the table. Can you
imagine now, what a ROLLBACK in PostgreSQL means? Simple -
eh? Just mark the transaction in pg_log as rolled back and
the stamps will get ignored. So the old tuple is still valid
and the new tuple at the end is ignored.

Vacuum now is the utility, that (dramatically simplified)
whipes out all the tuples with a committed XID in the ending
field and truncates the datafile.

Since you didn't copy pg_log (AND DON'T DO SO, IT WOULD
CORRUPT ALL DATABASES IN THE INSTALLATION) from PostgreSQL's
point of view all the UPDATES/INSERTS found in the copied
zipfind database files never committed, so the where ignored.

Either you copy the entire ./data directory, or you do it
with pg_dump. No other chance.

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 Oct 22 18:30:55 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id SAA00275
for pgsql-hackers@postgresql.org; Fri, 22 Oct 1999 18:30:06 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
Message-ID: <3810E74D.343885E4@cpsgroup.com>
Date: Fri, 22 Oct 1999 17:38:05 -0500
From: Bryan Ingram <bingram@cpsgroup.com>
Reply-To: bingram@cpsgroup.com
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
X-Newsgroups: comp.databases.postgresql.hackers
Subject: Re: [HACKERS] postgres inode q's
References: <m11elvg-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: 22 Oct 1999 17:25:51 -0500, 216.207.61.67
Lines: 52
X-Authenticated-User: boneyjames
X-Report: Report abuse to abuse@newsfeeds.com
X-Abuse-Info: Please be sure to forward a copy of ALL headers,
INCLUDING the body
X-Abuse-Info2: ALL Spam complaints are acted upon within 24 hours!
Organization: Newsfeeds.com http://www.newsfeeds.com 60,
000+ UNCENSORED Newsgroups.
To: pgsql-hackers@postgresql.org

Jan,

Thanks for the explanation, that does help to explain, and adds a lot to my
postgres knowledge in general ..

Based on your explanation, I understand how running VACUUM wiped out the new
tuples that did not have a corresponding XID in pg_log.

However, there is one aspect of this I still do not quite grasp ..

What happens if the INSERT/DELETE is done without a transaction
(BEGIN/COMMIT)? Is an XID still generated for that particular tuple, or is the
tuple instantly commited with no XID stamped into the beginning/ending fields?

Also, I don't understand why vacuum didn't wipe out all tuples in the
database, rather than just the new ones. Here's why:

When I updated the "new" database with the new records I used the DELETE then
INSERT trick to avoid having to write logic to first see if there was an
existing record and then to update only the changing fields. Since I actually
deleted, then inserted, I'm guessing that the XID would change so that when I
moved the database over to the other server, ALL of the XIDs would be
different, not just the newly added rows. In which case, I would expect
VACUUM to wipe everything. Instead, it only wiped the new rows, which tells
me that even though I DELETED/INSERTED all existing rows, that somehow the
XID's still sync with the XID's on the other server.

Assuming the XIDs did change, I'd guess that though I had exactly the same
number of rows I started with (666730 instead of +1400000) it is because the
XIDs happened to correspond, but not necessarily with their original
relationships. Which would mean that I still had 666730 rows, but not the
original ones. Probably a smattering of new and old ones.

I'm just theorizing off of the top of my head .. please let me know where I
have gone wrong!

Much Thanks,
Bryan

-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----

From bouncefilter Fri Oct 22 20:13:55 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA11186;
Fri, 22 Oct 1999 20:13:22 -0400 (EDT)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id UAA22720;
Fri, 22 Oct 1999 20:13:13 -0400 (EDT)
Message-ID: <3810FBDA.482F904A@southeast.net>
Date: Fri, 22 Oct 1999 20:05:46 -0400
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-admin@postgresql.org, pgsql-hackers@postgresql.org
Subject: RFC: Industrial-strength logging (long message)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Request For Comments: Towards an industrial-strength
logging facility

1999-10-19, Tim Holloway mtsinc@leading.net

Introduction.

PostgreSQL is a commercial-quality DBMS. However, one item
generally found in commercial DBMS's that
PostgreSQL has so far lacked has been a logging facility.
Yes, it has a debugging facility that can
spit out reams of useful information, but debugging is not
logging - it has different goals and constraints. This,
then, is an attempt to provide that missg item.

What should a log look like?

This depends. I like a console-style listing, as my needs
are simple. Others would prefer that the
log be itself a database. Happily, I think that what I have
developed so far can be used for both.
While it's perilous to attempt to be all things to all
people, my experience in working with the Amiga was that
simplicity doesn't have to mean rigidity or lack of ability.
Preliminary design efforts have resulted in a plan that I
think will satisfy the majority of DBA's. Time will tell.

Design goals

1. Robustness. Adding logging should not cause the system to
become unstable.
2. Performance. Unless you're IBM at least, logging is a
means, not an end. The performance of the system
must not be degraded.
3. Security. Since logging is often part of a security
effort, it's only reasonable that the log itself
be secure. As of this writing, security is that of the
PostgreSQL backend and/or syslog facilities.
4. Routability. Preliminary design permits routing any or
all events to multiple destinations, each of which is
individually controllable as to format. Abuse of this power
may impact 2), above, however.
5. Locale support. Not everyone's preferred language is
English. Because each and every log message is fully
configurable, and because care is given to formatting based
on locale, the DBA can customize logging to the convenience
of his or her own culture. I hope that those who benfit from
this will keep my on the proper path.

Implementation

"Simple things should be simple and complex things should be
possible"

Alan Kay

I've seen far too many systems where simple things were
complex and complex things were simple and other
variantions on that theme. I HOPE that's not what I'm
producing. If I am, PLEASE LET ME KNOW!!!

Although the same mechanism is at work at all times, the
defaults are set to display just enough information to let
you know that more is possible:

Postgres [123] 900 - Logging configuration file
"/usr/local/pgsql/data/postgresql.conf" was not found or
denied access. Using default logging.
Postgres [123] 101 - Server started
Postgres [123] 102 - Server shutdown

These messages are routed to stderr (if available) for the
backend process AND to syslog (if available).
If there are other worthy default channels, I'd like to know
them.

The Next Level

The logging configuration file allows customizing of
logging. At one extreme, it can be used to suppress ALL
logging - even the default items listed above. At the other
- suffice it to say that you can get VERY elaborate.

There are 3 types of information in the logging
configuration file (which may, but likely won't, be part of
pg_hba.conf) Logging info is read at startup. There may
exist signals that cause it to be reread, but not just yet.

They are:

1. General log control. For example, suppression of
high-demand activities BEFORE they get run, formatted and
sent to the log subsystem.

2. Message format. Allows definition/override of message
formats on a class (see below) and individual basis. This is
both how formatting for database load and locale are done.
Multiple message formats are supported!

3. Message routing. Allows definition of the destination(s)
of log messages. Each destination (channel) can select which
messages it will format and report. To avoid potential loss
of critical info, any message not explicitly routed at least
once gets reported on the default channel - stderr/syslog,
unless otherwise configured.

Message classes

Implicit in the desire for logging into a database is the
understanding that some types of messages may have identical
formats but different content. To facilitate this (and to
aid in locale support) each possible message has a unique
identifier, and related messages (those which would route to
the same table) are grouped into classes, identified by
century, as in the http and other familiar protocols.

Classes for PostgreSQL logging are not grouped by severity,
however, but by their affinity for a given
statistical table. Tentatively:

1xz - The PostgreSQL server
2xx - User-related information
3xx - Transaction information
4xx - EXPLAIN results (???)
9xx - General system alerts

Right now, the following are considered likely candidates,
subject to user feedback:

server info
Server name, signal ID
101 - Server started
102 - Server shutdown
103 - Signal xxx received
104 - Server ABEND

user session
userid, port or terminal ID, authentication scheme name
(e.g. md5). session ID
201 - User xxxx connected via port/terminal xxxxxxxx
authenticated by aaaaa
202 - User xxxx disconnected
203 - FORBIDDEN - connection denied for user xxxx via
port/terminal xxxxxxxxxx rejected by aaaaaaa

show commands
Session ID, command text
301 - SELECT text
302 - INSERT text
303 - UPDATE text
304 - DELETE text

show results
session ID, count or OID. primary/first/only table ID
affected
401 - SUCCESS - nnn records retrieved
402 - SUCCESS - record inserted at OID
403 - SUCCESS - nnn records updated
404 - SUCCESS - nnn records deleted
405 - FORBIDDEN - action xxxxxx denied to user xxxx on table
xxxxxxxx

explain
as below:
500 EXPLAIN transaction ID sequence cost rows bytes

miscellaneous
explanatory text
900 - Logging configuration file "ffff" was not found or
denied read access. Using default logging.
901 - Logging configuration file "ffff" could not be
processed - invalid text at line nnn.
902 - User overrides non-existent message ID nnn
903 - Channel requests non-existent message ID nnn
904 - end of section starting on line nnn was not found
905 - start of section ending on line nnn was not found
906 - (message from logging configuration file)

Multiple message format tables may be defined. Each of these
overrides or disables one or more of of the messages listed
above - or its "final" equivalent. Messages which aren't
overridden display in their default (English text) mode.
Because this could be VERY rude to a table loader, each
channel must explicitly request which messages are
acceptable (this also facilitates routing of message
classes). The default channel catches unsolicited messages
as a safeguard. To make it easier, both common message
formats in the message format tables and their
correspoonding solicitations in the channel definitions
allow ranges to be defined. E.g., you can define a logfile
format for messages 301-304 rather than having to replicate
the same format for each.

A brief example --- SUBJECT TO RADICAL CHANGE! ---

; One possible implementation of logging configuration:
; an SQL style - verb attribute(value[s]) might be better?
;
<logging>

<options>
level = warning ; of INFO, NOTICE, DEBUG, WARNING, ERROR, or
FATAL
log directory = /var/log/postgresql
startmessage = " This is a sample log configuration" ;
output via message 906
endmessage = "Have a Nice Day" ; output via message 906
</options>

<format name=info>
101 INFO "%n [%p] fing an"
102 INFO "%n [%p] ist zu Ende"
</format>

<format name=database>
201-203 INFO "%u %p"
301-304 INFO "'%2s'" ; quote with sql escapes
</format>

<channel>
format name : info
output : syslog( localost )
level : INFO
solicit : 101-104, default
</channel>

<channel>
format name : database-user
timestamp: local
file : user.log
solicit : 201-203
</channel>

<channel>
format name : database-session
file : session.log
solicit : 301-304
</channel>

; *** The default message channel ***
<channel>
output : syslog( dba.mousetech.com )
solicit : 1**, 9**, default
</channel>

</logging>

Apology

Although this scheme may appear elaborate, the internal
realization is fairly simple. I have far more concern that
it may overwhelm someone who is new to the entire PostgreSQL
system and is FAR more interested at that time in learning
POSTGRES! The plus side is that it's possible to amass a
library of mix-and-match blocks so that the more sordid
details need not be recreated endlessly by every DBA in the
world.

Credit where it's due

Asture observers may have noticed that the user-definable
message format is a blatant ripoff from Apache. The concept
of logging channels I lifted from bind, the DNS utility.
Some folding, spindling, stapling and/or mutilation may have
occurred in the process.

Feedback Needed

The details are still very much fluid, so your opinion
counts!!!! What's good? What's bad?
What can be improved, and what should be immediately hauled
off to the nearest toxic waste disposal center? Especially
of interest is what the shape of the config file should be.
Is the the pseudo-HTML format shown good? Would an SQL
statement form be preferable? Maybe something like LISP or
C? Or something entirely different? Please tell me! All I
ask is that it be YACC-parseable. Email your thoughts to me
at mtsinc@leading.net, subject: PostgreSQL logging. Results
will be posted to pgsql-admin and pgsql-hackers mailing
lists. Thank You.

Tim Holloway
MTS Associates, Inc.

From bouncefilter Fri Oct 22 20:21:55 1999
Received: from thelab.hub.org (nat198.58.mpoweredpc.net [142.177.198.58])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA12572
for <pgsql-general@hub.org>; Fri, 22 Oct 1999 20:21:02 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA88803;
Fri, 22 Oct 1999 21:20:59 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 22 Oct 1999 21:20:59 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Christian Rudow <Christian.Rudow@thinx.ch>
cc: Jimmie Houchin <jhouchin@texoma.net>,
PostgreSQL General <pgsql-general@hub.org>
Subject: Re: [GENERAL] Re: What's WAL
In-Reply-To: <3810034F.8ED0341E@thinx.ch>
Message-ID: <Pine.BSF.4.10.9910222120080.30583-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 22 Oct 1999, Christian Rudow wrote:

So - get down from envying the "Illuminati" - build up a working
linux configuration - step by step - slowly. And ... if you are one of
the less brighter guy's like me - don't ask for too much at one
time.

Actually, 3 out of 4 Illuminati use *BSD ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Fri Oct 22 20:37:56 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA15387
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 20:37:51 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA03071; Sat, 23 Oct 1999 09:36:17 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, <t-ishii@sra.co.jp>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] mdnblocks is an amazing time sink in huge relations
Date: Sat, 23 Oct 1999 09:40:21 +0900
Message-ID: <001201bf1cef$2fb648a0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <000501bf1a97$b925a860$2801007e@cadzone.tpf.co.jp>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

After a thought,I propose the following solution.

1. mdcreate() couldn't create existent relation files.
If the existent file is of length zero,we would overwrite
the file.(seems the comment in md.c says so but the
code doesn't do so).
If the file is an Index relation file,we would overwrite
the file.

This may allow to CREATE TABLE simultaneously for the
same table name. I would change to check the existence
of the same table name correctly in heap_create_with_ca
talog().

2. mdunlink() couldn't unlink non-existent relation files.
mdunlink() doesn't call elog(ERROR) even if the file
doesn't exist,though I couldn't find where to change
now.

_mdfd_getrelnfd(),mdnblocks() doesn't call elog().
Return code will be checked.

mdopen() doesn't call elog(ERROR) even if the file
doesn't exist and leaves the relation as CLOSED.

Comments ?

Recently I saw 2 postings about this in pgsql MLs.
So I want to change as above.

2. was changed by Tom(mdunlink/mdopen) and
Tatsuo(mdopen) recently.
Any Problems ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Fri Oct 22 20:57:56 1999
Received: from druid.net (root@druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA17630;
Fri, 22 Oct 1999 20:57:13 -0400 (EDT) (envelope-from darcy@druid.net)
Received: from localhost (2686 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m11epUa-0000bFC@druid.net> for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 20:57:08 -0400 (EDT)
(Smail-3.2.0.104 1998-Nov-20 #4 built 1999-Apr-13)
Message-Id: <m11epUa-0000bFC@druid.net>
Subject: Re: [HACKERS] RFC: Industrial-strength logging (long message)
In-Reply-To: <3810FBDA.482F904A@southeast.net> from Tim Holloway at "Oct 22,
1999 08:05:46 pm"
To: mtsinc@southeast.net (Tim Holloway)
Date: Fri, 22 Oct 1999 20:57:07 -0400 (EDT)
From: "D'Arcy" "J.M." Cain <darcy@druid.net>
Cc: pgsql-admin@postgreSQL.org, pgsql-hackers@postgreSQL.org
Reply-To: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL50 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thus spake Tim Holloway

Request For Comments: Towards an industrial-strength
logging facility

<COMMENT>Woo hoo!</COMMENT>

Yes please. As soon as possible. I have been trying to figure out all
sorts of kluges for this. I even considered putting something in PyGreSQL
but this is mush better.

Design goals

1. Robustness. Adding logging should not cause the system to
become unstable.

Absolutely.

2. Performance. Unless you're IBM at least, logging is a
means, not an end. The performance of the system
must not be degraded.

If performance takes a hit, could it be turned on and off with a flag
or by the existence of the config file itself? That way people willing
to pay for the logging can and those that need performance above all
can get it.

Postgres [123] 900 - Logging configuration file
"/usr/local/pgsql/data/postgresql.conf" was not found or
denied access. Using default logging.

Or don't log - see above.

The one thing I would suggest is make sure that logs get date and time stamped.

How about the ability to send the log to a process instead of a file? I
would like to log on a separate machine but there is firewall considerations.

Although this scheme may appear elaborate, the internal
realization is fairly simple. I have far more concern that
it may overwhelm someone who is new to the entire PostgreSQL
system and is FAR more interested at that time in learning

I don't see a problem here. Logging would be an advanced subject. No
one would have to deal with it. I think it is important that it not
log (or log to /dev/null) by default so that new users don't suddenly
find their disk space disappearing. Logging (especially if you log
SELECTs) cand use a lot of space.

Good work. This was definitely needed.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

From bouncefilter Fri Oct 22 21:16:56 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA20416
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 21:16:36 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA26797;
Fri, 22 Oct 1999 21:15:29 -0400 (EDT)
To: bingram@cpsgroup.com
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postgres inode q's
In-reply-to: Your message of Fri, 22 Oct 1999 17:38:05 -0500
<3810E74D.343885E4@cpsgroup.com>
Date: Fri, 22 Oct 1999 21:15:29 -0400
Message-ID: <26794.940641329@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bryan Ingram <bingram@cpsgroup.com> writes:

What happens if the INSERT/DELETE is done without a transaction
(BEGIN/COMMIT)? Is an XID still generated for that particular tuple,
or is the tuple instantly commited with no XID stamped into the
beginning/ending fields?

There is always a transaction. Postgres effectively generates an
implict BEGIN and END around any query that's not inside an explicit
transaction block. This is why failing statements don't cause trouble;
their transactions get aborted.

When I updated the "new" database with the new records I used the DELETE then
INSERT trick to avoid having to write logic to first see if there was an
existing record and then to update only the changing fields. Since I actually
deleted, then inserted, I'm guessing that the XID would change so that when I
moved the database over to the other server, ALL of the XIDs would be
different, not just the newly added rows. In which case, I would expect
VACUUM to wipe everything. Instead, it only wiped the new rows, which tells
me that even though I DELETED/INSERTED all existing rows, that somehow the
XID's still sync with the XID's on the other server.

Yeah, but the old tuples are *still there*. They are marked as having
been deleted by transaction XID so-and-so. When you moved the files,
those transaction numbers are no longer thought to be committed, so
the old tuples come back to life (just as the new tuples are no longer
considered valid, because their inserting transaction is not known to
be committed).

There is a potential hole in this theory, which relates to a point Jan
didn't make in his otherwise excellent discussion. A tuple normally
doesn't stay marked with its creating or deleting XID number for all
that long, because we don't really want to pay the overhead of
consulting pg_log for every single tuple. So, as soon as any backend
checks a tuple and sees that its inserting transaction did commit,
it rewrites the tuple with a new state "INSERT KNOWN COMMITTED" (which
is represented by inserting XID = 0 or some such). After that, no one
has to check pg_log anymore for that tuple; it's good. Similarly, the
deleting XID only stays on the tuple until someone verifies that the
deleting transaction committed; after that the tuple is marked KNOWN
DEAD, and it'll stay dead no matter what's in pg_log. VACUUM is really
only special in that it reclaims space occupied by known-dead tuples;
when it checks/updates the state of a tuple, it's not doing anything
that's not done by a plain SELECT.

So, AFAICT, you could only have seen the problem for tuples that were
not scanned by any SELECT or UPDATE operation subsequent to having been
inserted/deleted and committed. If you did all the deletes/inserts
inside a transaction, committed, and then immediately copied the files,
then for sure you'd have gotten burnt. If you did any sort of SELECT
from the table after committing the changes, I'd have expected the tuple
states to get frozen --- at least for the tuples that SELECT visited,
which might not have been all of them if the SELECT was able to use an
index.

regards, tom lane

From bouncefilter Fri Oct 22 21:25:56 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA21624
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 21:25:30 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id VAA08960;
Fri, 22 Oct 1999 21:24:55 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910230124.VAA08960@candle.pha.pa.us>
Subject: Re: [HACKERS] New psql startup banner
In-Reply-To: <Pine.LNX.4.10.9910220228200.1833-100000@peter-e.yi.org> from
Peter Eisentraut at "Oct 22, 1999 02:36:50 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Fri, 22 Oct 1999 21:24:55 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Oct 20, Bruce Momjian mentioned:

psql now shows new text on startup. The old one just looked bad.
Hope the psql upgrader can merge these changes in. I know we weren't
supposed to touch psql, but I suspect he is not touching the banner.

Hah!

$ ./psql template1
Welcome to psql, the PostgreSQL interactive query shell.
(Please type \copyright to see the distribution terms of PostgreSQL.)
PostgreSQL 6.5.2 on i586-pc-linux-gnu, compiled by egcs

Type \h for help with SQL commands,
\? for help on internal slash commands,
\q to quit,
\g or terminate with semicolon to execute query.
template1=> \copyright
memory clobbered before allocated blockAborted (core dumped)

Oops! :)

Okay, I guess the motivation behind this was the question "Where is that
damn COPYRIGHT file?", or maybe I've just been reading the appendix to the
GPL too often.

Anyway, I guess I'll let the balance of the suggestions apply.

I like your version better. Let's go with that. I will back out my
patch.

-- 
  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 Fri Oct 22 21:41:56 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA23550
for <pgsql-hackers@postgreSQL.org>;
Fri, 22 Oct 1999 21:41:53 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id KAA03079; Sat, 23 Oct 1999 10:41:46 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Vadim Mikheev" <vadim@krs.ru>
Cc: <pgsql-hackers@postgreSQL.org>, "Tom Lane" <tgl@sss.pgh.pa.us>
Subject: RE: [HACKERS] mdnblocks is an amazing time sink in huge relations
Date: Sat, 23 Oct 1999 10:45:49 +0900
Message-ID: <001301bf1cf8$555404e0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <380D6B63.9E7A158@krs.ru>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

But in any case, it seems to me that using shmem for
shared catalog cache is much worther than for
shared cache invalidation...

I don't like current cache invalidation either.
And shared catalog cache would make it easy to rollback
catalog cache(catalog/relation cache is not rollbacked correct-
ly now).

But there are some problems to implement shared catalog
cache.

1. Relation cache invalidation remains
It has almost same mechanism as catalog cache invaldation.
Cache invaldation is still incomprehensible as a whole.

2. Is it clear how consistency is kept between system tuples ?
It's quite unclear for me and there are 4 anxieties at least.

a. Locking for system tuples is short term(this is for DDL
commands inside transactions). This would break 2-phase
lock easily. Is there another principle instead ?

b. SnapshotNow is used to access system tuples in most
cases. SnapshotNow isn't a real snapshot.
i.e SnapshotNow couldn't guarantee read consistency.

c. Row level locking is not implemented for system tuples yet.

d. AccessShare lock are acquired for system tuples in many
places. But does it have any sense ?

3. If neither relpages nor reltuples is held,are there any other
speeding up things ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sat Oct 23 00:47:59 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA78886
for <pgsql-hackers@postgreSQL.org>;
Sat, 23 Oct 1999 00:47:13 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id AAA00741
for <pgsql-hackers@postgreSQL.org>;
Sat, 23 Oct 1999 00:46:42 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Path-length follies
Date: Sat, 23 Oct 1999 00:46:42 -0400
Message-ID: <738.940654002@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Whilst cleaning up query-length dependencies, I noticed that our
handling of maximum file pathname lengths is awfully messy.

Different parts of the system rely on no fewer than four different
symbols that they import from several different system header
files (any one of which might not exist on a particular platform):
MAXPATHLEN, _POSIX_PATH_MAX, MAX_PATH, PATH_MAX
And on top of that, postgres.h defines MAXPGPATH which is used
by yet other places.

On my system, _POSIX_PATH_MAX = 255, PATH_MAX = 1023, MAXPATHLEN = 1024
(a nearby Linux box is almost but not quite the same) whereas MAXPGPATH
is 128. So there is absolutely no consistency to the pathname length
limits being imposed in different parts of Postgres.

AFAIK, most or all flavors of Unix have kernel limits on the maximum
length of a pathname that will be accepted by the kernel's file-access
calls (it's 1024 on my box). So I don't feel any need to remove
hardwired limits on pathname lengths in favor of indefinitely-expansible
buffers. But it does seem that a little more consistency in the
hardwired limits is called for.

From the information I have, it seems that the various allegedly-

standard #defines for max pathname length are not too standard,
and I don't think that Postgres internal buffers ought to constrain
path lengths to much less than the kernel limit (so using the
seemingly "standard" _POSIX_PATH_MAX symbol would be a loser).
So my inclination is to define MAXPGPATH as 1024 in config.h, and
remove all uses of the other four symbols in favor of MAXPGPATH.
That would at least provide a single point of tweaking for anyone
who didn't like the value of 1024.

Does anyone have a better idea? Is it worth trying to extract a
system limit on pathlength during configure, rather than leaving
MAXPGPATH as a manual configuration item --- and if so, exactly how
should configure go about it?

regards, tom lane

From bouncefilter Sat Oct 23 02:34:00 1999
Received: from kiln.isn.net (root@kiln.isn.net [198.167.161.1])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA90901;
Sat, 23 Oct 1999 02:33:04 -0400 (EDT)
(envelope-from ctassell@isn.net)
Received: from niki (julia14.isn.net [198.167.161.182])
by kiln.isn.net (8.9.3/8.9.3) with ESMTP id DAA21088;
Sat, 23 Oct 1999 03:39:29 -0300
Message-Id: <4.2.0.58.19991023032917.00a505c0@mailer.isn.net>
X-Sender: ctassell@mailer.isn.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Sat, 23 Oct 1999 03:29:42 -0300
To: The Hermit Hacker <scrappy@hub.org>
From: Charles Tassell <ctassell@isn.net>
Subject: Re: [GENERAL] Re: What's WAL
Cc: PostgreSQL General <pgsql-general@hub.org>
In-Reply-To: <Pine.BSF.4.10.9910222120080.30583-100000@thelab.hub.org>
References: <3810034F.8ED0341E@thinx.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

That's why you don't hear anything about them anymore, they are stuck in
the past... :)

At 09:20 PM 10/22/99, The Hermit Hacker wrote:

On Fri, 22 Oct 1999, Christian Rudow wrote:

So - get down from envying the "Illuminati" - build up a working
linux configuration - step by step - slowly. And ... if you are one of
the less brighter guy's like me - don't ask for too much at one
time.

Actually, 3 out of 4 Illuminati use *BSD ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary:
scrappy@{freebsd|postgresql}.org

************

From bouncefilter Sat Oct 23 09:45:04 1999
Received: from smtp4.mindspring.com (smtp4.mindspring.com [207.69.200.64])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA45799;
Sat, 23 Oct 1999 09:44:27 -0400 (EDT)
(envelope-from samelash@ix.netcom.com)
Received: from amd (nyc-ny70-09.ix.netcom.com [209.109.226.137])
by smtp4.mindspring.com (8.8.5/8.8.5) with SMTP id JAA23833;
Sat, 23 Oct 1999 09:44:24 -0400 (EDT)
Message-Id: <3.0.3.32.19991023083850.0108ac2c@popd.ix.netcom.com>
X-Sender: samelash@popd.ix.netcom.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sat, 23 Oct 1999 08:38:50 +0000
To: The Hermit Hacker <scrappy@hub.org>,
Christian Rudow <Christian.Rudow@thinx.ch>
From: Samy Elashmawy <samelash@ix.netcom.com>
Subject: Re: [GENERAL] Re: What's WAL
Cc: Jimmie Houchin <jhouchin@texoma.net>,
PostgreSQL General <pgsql-general@hub.org>
In-Reply-To: <Pine.BSF.4.10.9910222120080.30583-100000@thelab.hub.org>
References: <3810034F.8ED0341E@thinx.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Whats BSD ?? Hows itcompare to linux ?

Newbie you know

At 09:20 PM 10/22/1999 -0300, The Hermit Hacker wrote:

On Fri, 22 Oct 1999, Christian Rudow wrote:

So - get down from envying the "Illuminati" - build up a working
linux configuration - step by step - slowly. And ... if you are one of
the less brighter guy's like me - don't ask for too much at one
time.

Actually, 3 out of 4 Illuminati use *BSD ...

Marc G. Fournier ICQ#7615664 IRC Nick:

Scrappy

Systems Administrator @ hub.org
primary: scrappy@hub.org secondary:

scrappy@{freebsd|postgresql}.org

************

From bouncefilter Sat Oct 23 08:45:05 1999
Received: from fep132.fep.ru (mail@[195.230.89.88])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA39316
for <pgsql-hackers@postgresql.org>;
Sat, 23 Oct 1999 08:44:47 -0400 (EDT) (envelope-from phd@phd.russ.ru)
Received: from localhost [127.0.0.1] (phd)
by fep132.fep.ru with esmtp (Exim 2.05 #1 (Debian))
id 11f0XD-0002dO-00; Sat, 23 Oct 1999 16:44:35 +0400
Date: Sat, 23 Oct 1999 12:44:35 +0000 (GMT)
From: Oleg Broytmann <phd@phd.russ.ru>
X-Sender: phd@fep132.fep.ru
Reply-To: phd2@earthling.net
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: GPL vs BSD vs SCSL
Message-ID: <Pine.LNX.4.20.9910231238190.10100-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello!

Eric Raymond responds to Bill Joy... RMS said its words too:
http://www.upsidetoday.com/texis/mvm/richard_brandt?id=380f44bb0

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

From bouncefilter Sat Oct 23 13:27:07 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA70986;
Sat, 23 Oct 1999 13:26:11 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id NAA01736;
Sat, 23 Oct 1999 13:25:05 -0400 (EDT)
To: Tim Holloway <mtsinc@leading.net>
cc: pgsql-admin@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RFC: Industrial-strength logging (long message)
In-reply-to: Your message of Fri, 22 Oct 1999 20:05:46 -0400
<3810FBDA.482F904A@southeast.net>
Date: Sat, 23 Oct 1999 13:25:05 -0400
Message-ID: <1734.940699505@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tim Holloway <mtsinc@southeast.net> writes:

Request For Comments: Towards an industrial-strength
logging facility

Sounds pretty good overall.

This depends. I like a console-style listing, as my needs are
simple. Others would prefer that the log be itself a database.

Note that logging into a table is harder than you might think.
For example: (1) The postmaster cannot touch tables at all, so
no events detected in the postmaster could be logged that way.
(2) No events detected during a transaction that ultimately
aborts will be successfully logged. (3) Logging events such as
"server failure" would be quite risky --- if the server has
suffered internal state corruption then it could manage to
corrupt the log table entirely while it's trying to add its
last-dying-breath report.

Fortunately none of these problems apply to stderr, syslog,
or plain-text-file reporting channels.

There are 3 types of information in the logging
configuration file (which may, but likely won't, be part of
pg_hba.conf)

No, it should definitely not be part of pg_hba.conf, it should
be a separate configuration file. (pg_hba.conf has a syntax too
simple to be easily extensible.)

Another possibility is to keep the config info in a system table, but
that would have a number of drawbacks (the postmaster cannot read
tables, nor can a backend that's just starting up and hasn't finished
initialization). On the whole, a plain text file in the database
directory is probably the best bet.

Logging info is read at startup. There may
exist signals that cause it to be reread, but not just yet.

There MUST exist a way to alter the logging level on-the-fly;
IMHO this is a rock bottom, non negotiable requirement.
A production system can't restart the postmaster just to tweak
the logging level up or down for investigation of a problem.

Whether it's a signal or something else remains to be determined.
We have pretty nearly used up all the available signal numbers :-(.
I suppose that whichever signal is currently used to trigger
rereading of the pg_options configuration file could also trigger
re-reading of the logging config file.

To avoid potential loss
of critical info, any message not explicitly routed at least
once gets reported on the default channel - stderr/syslog,
unless otherwise configured.

Hmm, so I'd have to explicitly discard every message I didn't want to
hear about? I think that "forced display" like this should only happen
for high-severity messages, not for routine junk. There doesn't seem to
be any notion of message importance in your design, but I think there
should be. Most people would probably prefer to filter on an importance
level, only occasionally resorting to calling out specific message types.

Especially of interest is what the shape of the config file should be.
Is the the pseudo-HTML format shown good?

You could do worse than to borrow BIND's syntax for log control.

regards, tom lane

From bouncefilter Sat Oct 23 13:26:07 1999
Received: from postal.dn.net (postal.dn.net [207.226.170.20])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA70947
for <pgsql-hackers@postgreSQL.org>;
Sat, 23 Oct 1999 13:25:42 -0400 (EDT)
(envelope-from frankpit@pop.dn.net)
Received: from pop.dn.net (pm-68.ppp.wdc.dn.net [207.226.188.68])
by postal.dn.net (102199-jg) with ESMTP id NAA17663;
Sat, 23 Oct 1999 13:24:21 -0400 (EDT)
Sender: matuser@postal.dn.net
Message-ID: <3811F51C.B884AC7D@pop.dn.net>
Date: Sat, 23 Oct 1999 17:49:16 +0000
From: Bernard Frankpitt <frankpit@pop.dn.net>
Organization: AIMS
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.32 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: bingram@cpsgroup.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postgres inode q's
References: <26794.940641329@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

................ So, as soon as any backend
checks a tuple and sees that its inserting transaction did commit,
it rewrites the tuple with a new state "INSERT KNOWN COMMITTED" (which
is represented by inserting XID = 0 or some such). .........

The way concurrency is supported in PostgreSQL is really cool, and I
think not widely understood. The tuple uses flags stored in the
t_infomask field of the HeapTupleHeader structure to 'cache' the status
of the creating and deleting transactions for each tuple.

Check out backend/utils/time/tqual.c and include/utils/tqual.h for
the details of the algorithms. (Not recommended if you have been
drinking at all)

Ullman "Principles of Database and Knowledge-Base Systems, Vol 1" Has a
pretty good discussion of time based and lock based schemes for
concurrency control.

Bernie Frankpitt

From bouncefilter Sat Oct 23 14:41:11 1999
Received: from genisys.gtv.ca (h-207-228-97-106.gen.cadvision.com
[207.228.97.106]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA81739;
Sat, 23 Oct 1999 14:40:18 -0400 (EDT) (envelope-from aaron@gtv.ca)
Received: from stilborne (h-207-228-97-110.gen.cadvision.com [207.228.97.110])
by genisys.gtv.ca (8.9.3/8.8.7) with SMTP id MAA13741;
Sat, 23 Oct 1999 12:39:05 -0600
From: "Aaron J. Seigo" <aaron@gtv.ca>
To: Tom Lane <tgl@sss.pgh.pa.us>, Tim Holloway <mtsinc@leading.net>
Subject: Re: [ADMIN] Re: [HACKERS] RFC: Industrial-strength logging (long
message)
Date: Sat, 23 Oct 1999 11:54:40 -0600
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: pgsql-admin@postgreSQL.org, pgsql-hackers@postgreSQL.org
References: <1734.940699505@sss.pgh.pa.us>
In-Reply-To: <1734.940699505@sss.pgh.pa.us>
MIME-Version: 1.0
Message-Id: <9910231236140N.10632@stilborne>
Content-Transfer-Encoding: 8bit

hi...

This depends. I like a console-style listing, as my needs are
simple. Others would prefer that the log be itself a database.

Note that logging into a table is harder than you might think.

unless i misunderstand, the concept is to design the logs such that it is
trivial to convert them into a database, even including tools to do this, not
to actually create a database on the fly.

i'm also supportive of including tools to run standard reports out-of-the-box
on these logs. using pgsql to massage its own logs is pretty sexy, imo =)

No, it should definitely not be part of pg_hba.conf, it should
be a separate configuration file. (pg_hba.conf has a syntax too
simple to be easily extensible.)
initialization). On the whole, a plain text file in the database
directory is probably the best bet.

agreed...

There MUST exist a way to alter the logging level on-the-fly;
IMHO this is a rock bottom, non negotiable requirement.

whilst i don't think this is MUST, it is EXTREMELY desirable and would make the
logging actually useful for large installations =)

Whether it's a signal or something else remains to be determined.
We have pretty nearly used up all the available signal numbers :-(.
I suppose that whichever signal is currently used to trigger
rereading of the pg_options configuration file could also trigger
re-reading of the logging config file.

why not use pg_options for logging cofig?

Hmm, so I'd have to explicitly discard every message I didn't want to
hear about? I think that "forced display" like this should only happen
for high-severity messages, not for routine junk. There doesn't seem to
be any notion of message importance in your design, but I think there
should be. Most people would probably prefer to filter on an importance
level, only occasionally resorting to calling out specific message types.

systems i've dealt with in the past prioritize (as you mentioned) on a numeric
scale to reflect "importance" and the logging level is by default set at a
certain "height"... increasing logging is as easy as changing the threshold..
this has been effective in the past...

the only problem with ONLY relying on thresholds is that its a very coarse
grain method... so when you request a lower level of logging, you often get
inundated with all SORTS of stuff you don't really care/want...

a hybridization between the two approaches might be best.. e.g., each type of
message gets assigned a "criticality", between 1 and 10 perhaps. with 1 being
most critical, and 10 being least.. therefore, the higher you set your logging
level, the more messages you get (logical?)

the default behaviour for each level (1..10) is to let everything though on
that level. but you can apply filters to limit the output...
so you get the ability to define grossly with thresholds (1..10) and finely
(and optionally) with message filters...

You could do worse than to borrow BIND's syntax for log control.

much worse. =)

--
Aaron J. Seigo
Sys Admin

From bouncefilter Sat Oct 23 14:34:08 1999
Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar
[200.10.100.10]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA80596
for <pgsql-hackers@postgreSQL.org>;
Sat, 23 Oct 1999 14:33:06 -0400 (EDT)
(envelope-from fpscha@ns1.via-net-works.net.ar)
Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.8.5/8.8.4)
id PAA12452; Sat, 23 Oct 1999 15:25:26 -0300 (GMT)
From: Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar>
Message-Id: <199910231825.PAA12452@ns1.via-net-works.net.ar>
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
In-Reply-To: <20888.940609226@sss.pgh.pa.us> from Tom Lane at "Oct 22,
99 12:20:26 pm"
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Sat, 23 Oct 1999 15:25:25 -0300 (GMT)
Cc: fpscha@via-net-works.net.ar, pgsql-hackers@postgreSQL.org
Reply-To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
X-Mailer: ELM [version 2.4ME+ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

En un mensaje anterior, Tom Lane escribi�:

It's still convinced it's only going to get one row out of usuarios.
Weird. I assume that your 'activa' field is 'bool'? I've been trying
to duplicate this misbehavior here, and as near as I can tell the system
handles selectivity estimates for boolean fields just fine. Whatever
percentage of 't' values was seen by the last VACUUM ANALYZE is exactly
what it uses.

I am using 6.5.2 and current sources, though, and in your original
message you said you were on 6.5.0. If that's right, seems like the
first thing to try is for you to update to 6.5.2, run another VACUUM
ANALYZE, and then see if you still get the same bogus row estimates.

I was using 6.5.0 on my first post, then I upgraded and all the vacuum
and explain commands where from 6.5.2. Here is my complete database
definition:

CREATE TABLE usuarios
(id_usr serial,
razon_social text NOT NULL,
nombre_cuenta text NOT NULL,
grupo int2 NOT NULL,
perfil int2 NOT NULL,
estado char(1) NOT NULL DEFAULT 'H' CHECK ((estado='H') or (estado='D')),
id_madre int4 NOT NULL,
fecha_creacion datetime DEFAULT CURRENT_DATE,
fecha_baja datetime,
gratuita bool DEFAULT 'f',
activa bool DEFAULT 't',
observaciones text
) \g

CREATE TABLE passwd
(id_usr serial,
clave_plana text NOT NULL,
clave_cifrada text NOT NULL
) \g

CREATE TABLE perfiles
(id_perfil serial,
nombre text NOT NULL,
descripcion text
) \g

CREATE TABLE grupos
(id_grupo serial,
nombre text NOT NULL,
descripcion text
) \g

CREATE TABLE cronometradas
(id_usr serial,
fecha_comienzo_cronometrado datetime DEFAULT CURRENT_DATE,
tipo_cronometrado int2,
max_segs_vida int4,
max_segs_consumo int4
) \g

CREATE TABLE tipos_cronometrado
(id_tipo_cronometrado serial,
nombre text NOT NULL,
descripcion text
) \g

The other odd thing about the above plan is that it's doing an
explicit sort on perfiles. Didn't you say that you had an index on
perfiles.id_perfil? It should be scanning that instead of doing

It should, as it is serial. What does it mean when PgAccess says a table
doesn't has a primary key? Would it impact?

Again, thanks!

Fernando P. Schapachnik
Administraci�n de la red
VIA Net Works Argentina SA
Diagonal Roque S�enz Pe�a 971, 4� y 5� piso.
1035 - Capital Federal, Argentina.
(54-11) 4323-3333
http://www.via-net-works.net.ar

From bouncefilter Sat Oct 23 14:35:08 1999
Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar
[200.10.100.10]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA80695
for <pgsql-hackers@postgreSQL.org>;
Sat, 23 Oct 1999 14:34:18 -0400 (EDT)
(envelope-from fpscha@ns1.via-net-works.net.ar)
Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.8.5/8.8.4)
id PAA13176; Sat, 23 Oct 1999 15:29:01 -0300 (GMT)
From: Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar>
Message-Id: <199910231829.PAA13176@ns1.via-net-works.net.ar>
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
In-Reply-To: <20995.940612509@sss.pgh.pa.us> from Tom Lane at "Oct 22,
99 01:15:09 pm"
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Sat, 23 Oct 1999 15:29:01 -0300 (GMT)
Cc: fpscha@via-net-works.net.ar, pgsql-hackers@postgreSQL.org
Reply-To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
X-Mailer: ELM [version 2.4ME+ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

En un mensaje anterior, Tom Lane escribi�:

I wrote:

Weird. I assume that your 'activa' field is 'bool'? I've been trying
to duplicate this misbehavior here, and as near as I can tell the system
handles selectivity estimates for boolean fields just fine. Whatever
percentage of 't' values was seen by the last VACUUM ANALYZE is exactly
what it uses.

On second thought: 6.5.* can get confused if the column contains more
NULLs than anything else. Dunno if you have a lot of nulls in activa,
but if so you might try changing them all to explicit 'f' and then
redoing the VACUUM ANALYZE. Next release will be smarter about keeping
stats in the presence of many nulls.

It'd be useful to double-check my theory that the system is
misestimating the selectivity of the WHERE (u.activa) clause.
You could try this:
SELECT count(*) FROM usarios WHERE activa;

10571

EXPLAIN SELECT count(*) FROM usarios WHERE activa;
and see how far off the row count estimate in the EXPLAIN is
from reality.

NOTICE: QUERY PLAN:

Aggregate (cost=498.84 rows=1 width=4)
-> Seq Scan on usuarios (cost=498.84 rows=1 width=4)

EXPLAIN

Don't hesitate in asking any other info/test you may consider useful.

Regards!

Fernando P. Schapachnik
Administraci�n de la red
VIA Net Works Argentina SA
Diagonal Roque S�enz Pe�a 971, 4� y 5� piso.
1035 - Capital Federal, Argentina.
(54-11) 4323-3333
http://www.via-net-works.net.ar

From bouncefilter Sat Oct 23 15:27:09 1999
Received: from thelab.hub.org (nat198.58.mpoweredpc.net [142.177.198.58])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA99653;
Sat, 23 Oct 1999 15:26:23 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA97226;
Sat, 23 Oct 1999 16:23:57 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sat, 23 Oct 1999 16:23:57 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: "Aaron J. Seigo" <aaron@gtv.ca>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Tim Holloway <mtsinc@leading.net>,
pgsql-admin@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [ADMIN] Re: [HACKERS] RFC: Industrial-strength logging (long
message)
In-Reply-To: <9910231236140N.10632@stilborne>
Message-ID: <Pine.BSF.4.10.9910231622440.404-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 23 Oct 1999, Aaron J. Seigo wrote:

There MUST exist a way to alter the logging level on-the-fly;
IMHO this is a rock bottom, non negotiable requirement.

whilst i don't think this is MUST, it is EXTREMELY desirable and would make the
logging actually useful for large installations =)

Let's re-iterate Tom here: There MUST exist a way ... someone *MUST* be
able to change their configuration without having to physically stop/start
the server to affect the changes ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Sat Oct 23 15:41:09 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA01748
for <pgsql-hackers@postgreSQL.org>;
Sat, 23 Oct 1999 15:40:21 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id PAA19850;
Sat, 23 Oct 1999 15:38:33 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910231938.PAA19850@candle.pha.pa.us>
Subject: Re: [HACKERS] Path-length follies
In-Reply-To: <738.940654002@sss.pgh.pa.us> from Tom Lane at "Oct 23,
1999 00:46:42 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 23 Oct 1999 15:38:33 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Whilst cleaning up query-length dependencies, I noticed that our
handling of maximum file pathname lengths is awfully messy.

Different parts of the system rely on no fewer than four different
symbols that they import from several different system header
files (any one of which might not exist on a particular platform):
MAXPATHLEN, _POSIX_PATH_MAX, MAX_PATH, PATH_MAX
And on top of that, postgres.h defines MAXPGPATH which is used
by yet other places.

On my system, _POSIX_PATH_MAX = 255, PATH_MAX = 1023, MAXPATHLEN = 1024
(a nearby Linux box is almost but not quite the same) whereas MAXPGPATH
is 128. So there is absolutely no consistency to the pathname length
limits being imposed in different parts of Postgres.

AFAIK, most or all flavors of Unix have kernel limits on the maximum
length of a pathname that will be accepted by the kernel's file-access
calls (it's 1024 on my box). So I don't feel any need to remove
hardwired limits on pathname lengths in favor of indefinitely-expansible
buffers. But it does seem that a little more consistency in the
hardwired limits is called for.

From the information I have, it seems that the various allegedly-

standard #defines for max pathname length are not too standard,
and I don't think that Postgres internal buffers ought to constrain
path lengths to much less than the kernel limit (so using the
seemingly "standard" _POSIX_PATH_MAX symbol would be a loser).
So my inclination is to define MAXPGPATH as 1024 in config.h, and
remove all uses of the other four symbols in favor of MAXPGPATH.
That would at least provide a single point of tweaking for anyone
who didn't like the value of 1024.

Does anyone have a better idea? Is it worth trying to extract a
system limit on pathlength during configure, rather than leaving
MAXPGPATH as a manual configuration item --- and if so, exactly how
should configure go about it?

I don't like the 128 or 256 numbers, but isn't there a predefined place
for this value in standard system headers?

-- 
  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 Sat Oct 23 16:15:09 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA07328
for <pgsql-hackers@postgreSQL.org>;
Sat, 23 Oct 1999 16:14:57 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <4YCB005M>; Sat, 23 Oct 1999 22:14:12 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C1A9@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Peter Eisentraut '" <peter_e@gmx.net>, "'Bruce Momjian '"
<maillist@candle.pha.pa.us>
Cc: "'PostgreSQL-development '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] New psql startup banner
Date: Sat, 23 Oct 1999 22:09:30 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"

Oops! :)

Okay, I guess the motivation behind this was the question "Where is
that damn COPYRIGHT file?", or maybe I've just been reading the
appendix to the GPL too often.

The thing is this: it's not GPL'd ;-)

MikeA

From bouncefilter Sat Oct 23 16:32:09 1999
Received: from tuna.uimage.com (root@tuna.uimage.com [192.88.117.16])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA09537
for <pgsql-hackers@postgresql.org>;
Sat, 23 Oct 1999 16:31:25 -0400 (EDT)
(envelope-from stevek@tuna.uimage.com)
Received: from tuna.uimage.com (stevek@localhost.uimage.com [127.0.0.1])
by tuna.uimage.com (8.9.0/8.9.0) with ESMTP id QAA17104;
Sat, 23 Oct 1999 16:30:51 -0400 (EDT)
Message-Id: <199910232030.QAA17104@tuna.uimage.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: pgsql-hackers@postgresql.org
cc: stevek@uimage.com
Subject: Re: [HACKERS] RFC: Industrial-strength logging
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 23 Oct 1999 16:30:51 -0400
From: Stephen Kogge <stevek@uimage.com>

Is there something syslog does not do? multi level is
built in. Use a cron task to record back to a postgres db if needed/wanted.
syslog.conf lets you decide what to log (to some degree).

Why re-invent things? Most admins sort-of understand syslog.

--
Stephen N. Kogge
stevek@uimage.com
http://www.uimage.com

From bouncefilter Sat Oct 23 18:30:10 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA23506
for <pgsql-hackers@postgreSQL.org>;
Sat, 23 Oct 1999 18:29:17 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA02331;
Sat, 23 Oct 1999 18:28:35 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Path-length follies
In-reply-to: Your message of Sat, 23 Oct 1999 15:38:33 -0400 (EDT)
<199910231938.PAA19850@candle.pha.pa.us>
Date: Sat, 23 Oct 1999 18:28:34 -0400
Message-ID: <2329.940717714@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Does anyone have a better idea? Is it worth trying to extract a
system limit on pathlength during configure, rather than leaving
MAXPGPATH as a manual configuration item --- and if so, exactly how
should configure go about it?

I don't like the 128 or 256 numbers, but isn't there a predefined place
for this value in standard system headers?

There are too many of 'em, actually --- I had never realized this
before, but there are three or four *different* "standard" symbols that
all purport to be max pathlength. On my box they actually have three
different values, which doesn't leave a warm feeling in the stomach.

As I was just commenting off-list, we do not need to enforce the local
kernel's pathlength limit --- it's perfectly capable of doing that for
itself. All we really need to do is make sure we are not a bottleneck
preventing reasonable usage. So, although I was thinking last night
that a configure test might be a good idea, I now believe it's a waste
of cycles. (It could even be counterproductive, if it seized on a
bogusly small value, as _POSIX_PATH_MAX appears to be on both of the
systems I've checked.) Let's just set the value at something generous
like 1K and forget it. But we should use a consistent, tweakable-in-
one-place value, just in case.

regards, tom lane

From bouncefilter Sat Oct 23 19:10:11 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA28150
for <pgsql-hackers@postgreSQL.org>;
Sat, 23 Oct 1999 19:09:13 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id TAA02361;
Sat, 23 Oct 1999 19:07:19 -0400 (EDT)
To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
In-reply-to: Your message of Sat, 23 Oct 1999 15:29:01 -0300 (GMT)
<199910231829.PAA13176@ns1.via-net-works.net.ar>
Date: Sat, 23 Oct 1999 19:07:19 -0400
Message-ID: <2359.940720039@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar> writes:

It'd be useful to double-check my theory that the system is
misestimating the selectivity of the WHERE (u.activa) clause.
You could try this:
SELECT count(*) FROM usarios WHERE activa;

10571

EXPLAIN SELECT count(*) FROM usarios WHERE activa;
and see how far off the row count estimate in the EXPLAIN is
from reality.

NOTICE: QUERY PLAN:

Aggregate (cost=498.84 rows=1 width=4)
-> Seq Scan on usuarios (cost=498.84 rows=1 width=4)

Well, it's sure confused about the selectivity of WHERE activa,
all right.

I tried to duplicate this here, by duplicating the table definition you
sent and filling it with some junk data --- about 1800 rows, 1500 of
which had activa = 't'. I found that after loading the table and
running a plain "vacuum", the system indeed estimated one row out, just
as you show above. But after "vacuum analyze", it estimated 1360 rows
out, which is a lot closer to reality (and would make a big difference
in the plan selected for a join).

Now I know you said you did a "vacuum analyze" on the table, but
I am wondering if maybe you got confused about what you did.
Please try it again just to make sure.

The only other explanation I can think of is that I am not running this
test on a pristine 6.5.2 release, but on a recent CVS update from the
REL6_5 branch. I don't see any indication that anything has been
changed in the selectivity code since 6.5 in that branch, but maybe I
missed something. You might need to update to almost-6.5.3. (I am not
sure if there is a beta-test tarball for 6.5.3 or not; if not, you could
pull the sources from the CVS server, or wait for 6.5.3 which should be
out very soon.)

BTW, current sources (7.0-to-be) get the estimate spot-on after "vacuum
analyze", though without it they are not much better than 6.5. The
current system is estimating 1% of the rows will match, because it's
treating the WHERE condition like "WHERE activa = 't'" and the default
estimate for "=" selectivity is 1% in the absence of VACUUM ANALYZE
statistics. Probably we ought to special-case boolean columns to
default to a 50% estimate if no statistics are available...

regards, tom lane

From bouncefilter Sat Oct 23 19:49:11 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA32451
for <pgsql-hackers@postgreSQL.org>;
Sat, 23 Oct 1999 19:49:10 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm119.noc.fukui.nsk.ne.jp [210.161.188.38])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id IAA03284; Sun, 24 Oct 1999 08:49:06 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: <pgsql-hackers@postgreSQL.org>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, <t-ishii@sra.co.jp>
Subject: System indexes are never unique indexes( was RE: [HACKERS] mdnblocks
is an amazing time sink in huge relations)
Date: Sun, 24 Oct 1999 08:48:38 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFMEIBCAAA.Inoue@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
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)
Importance: Normal
In-Reply-To: <001201bf1cef$2fb648a0$2801007e@cadzone.tpf.co.jp>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

After a thought,I propose the following solution.

1. mdcreate() couldn't create existent relation files.
If the existent file is of length zero,we would overwrite
the file.(seems the comment in md.c says so but the
code doesn't do so).
If the file is an Index relation file,we would overwrite
the file.

This may allow to CREATE TABLE simultaneously for the
same table name. I would change to check the existence

As I was afraid,2 tables of a same name could be made.
After a short investigating,I found that system indexes are
never unique indexes.
Why ?
Without duplicate index check,it's very difficult to prevent
objects from having same name.

Comments ?

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sat Oct 23 19:53:12 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA32997
for <pgsql-hackers@postgreSQL.org>;
Sat, 23 Oct 1999 19:53:02 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id TAA02398
for <pgsql-hackers@postgreSQL.org>;
Sat, 23 Oct 1999 19:52:29 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Function-manager redesign: second draft (long)
Date: Sat, 23 Oct 1999 19:52:29 -0400
Message-ID: <2395.940722749@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

This is a followup to a message I wrote in June about reworking the fmgr
interface. I've had a couple of good ideas (I think ;-)) since then,
but there are some parts of the proposal that still need work before
implementation can begin.

I could particularly use some feedback from Jan and anyone else who's
worked with function-call handlers: does this design eliminate the
kluges that you've had to use in the past? If not, what else is needed?

regards, tom lane

Proposal for function-manager redesign
--------------------------------------

We know that the existing mechanism for calling Postgres functions needs
to be redesigned. It has portability problems because it makes
assumptions about parameter passing that violate ANSI C; it fails to
handle NULL arguments and results cleanly; and "function handlers" that
support a class of functions (such as fmgr_pl) can only be done via a
really ugly, non-reentrant kluge. (Global variable set during every
function call, forsooth.) Here is a proposal for fixing these problems.

In the past, the major objections to redoing the function-manager
interface have been (a) it'll be quite tedious to implement, since every
built-in function and everyplace that calls such functions will need to
be touched; (b) such wide-ranging changes will be difficult to make in
parallel with other development work; (c) it will break existing
user-written loadable modules that define "C language" functions. While
I have no solution to the "tedium" aspect, I believe I see an answer to
the other problems: by use of function handlers, we can support both old
and new interfaces in parallel for both callers and callees, at some
small efficiency cost for the old styles. That way, most of the changes
can be done on an incremental file-by-file basis --- we won't need a
"big bang" where everything changes at once. Support for callees
written in the old style can be left in place indefinitely, to provide
backward compatibility for user-written C functions.

The new function-manager interface
----------------------------------

The core of the new design is revised data structures for representing
the result of a function lookup and for representing the parameters
passed to a specific function invocation. (We want to keep function
lookup separate, since many parts of the system apply the same function
over and over; the lookup overhead should be paid once per query, not
once per tuple.)

When a function is looked up in pg_proc, the result is represented as

typedef struct
{
PGFunction fn_addr; /* pointer to function or handler to be called */
Oid fn_oid; /* OID of function (NOT of handler, if any) */
int fn_nargs; /* 0..MAXFMGRARGS, or -1 if variable arg count */
void *fn_extra; /* extra space for use by handler */
} FunctionLookupInfoData;
typedef FunctionLookupInfoData* FunctionLookupInfo;

For an ordinary built-in function, fn_addr is just the address of the C
routine that implements the function. Otherwise it is the address of a
handler for the class of functions that includes the target function.
The handler can use the function OID and perhaps also the fn_extra slot
to find the specific code to execute. (fn_oid = InvalidOid can be used
to denote a not-yet-initialized FunctionLookupInfoData struct. fn_extra
will always be NULL when a FunctionLookupInfoData is first filled by the
function lookup code, but a function handler could set it to avoid
making repeated lookups of its own when the same FunctionLookupInfoData
is used repeatedly during a query.) fn_nargs is the number of arguments
expected by the function.

FunctionLookupInfo replaces the present FmgrInfo structure (but I'm
giving it a new name so that the old struct definition can continue
to exist during the transition phase).

During a call of a function, the following data structure is created
and passed to the function:

typedef struct
{
FunctionLookupInfo flinfo; /* ptr to lookup info used for this call */
bool isnull; /* input/output flag, see below */
int nargs; /* # arguments actually passed */
Datum arg[MAXFMGRARGS]; /* Arguments passed to function */
bool argnull[MAXFMGRARGS]; /* T if arg[i] is actually NULL */
} FunctionCallInfoData;
typedef FunctionCallInfoData* FunctionCallInfo;

Note that all the arguments passed to a function (as well as its result
value) will now uniformly be of type Datum. As discussed below, callers
and callees should apply the standard Datum-to-and-from-whatever macros
to convert to the actual argument types of a particular function. The
value in arg[i] is unspecified when argnull[i] is true.

It is generally the responsibility of the caller to ensure that the
number of arguments passed matches what the callee is expecting: except
for callees that take a variable number of arguments, the callee will
typically ignore the nargs field and just grab values from arg[].

The meaning of the struct elements should be pretty obvious with the
exception of isnull. isnull must be set by the caller to the logical OR
of the argnull[i] flags --- ie, isnull is true if any argument is NULL.
(Of course, isnull is false if nargs == 0.) On return from the
function, isnull is the null flag for the function result: if it is true
the function's result is NULL, regardless of the actual function return
value. Overlapping the input and output flags in this way provides a
simple, convenient, fast implementation for the most common case of a
"strict" function (whose result is NULL if any input is NULL):

if (finfo->isnull)
return (Datum) 0; /* specific value doesn't matter */

... else do normal calculation ignoring argnull[] ...

Non-strict functions can easily be implemented; they just need to check
the individual argnull[] flags and set the appropriate isnull value
before returning.

FunctionCallInfo replaces FmgrValues plus a bunch of ad-hoc parameter
conventions.

Callees, whether they be individual functions or function handlers,
shall always have this signature:

Datum function (FunctionCallInfo finfo);

which is represented by the typedef

typedef Datum (*PGFunction) (FunctionCallInfo finfo);

The function is responsible for setting finfo->isnull appropriately
as well as returning a result represented as a Datum. Note that since
all callees will now have exactly the same signature, and will be called
through a function pointer declared with exactly that signature, we
should have no portability or optimization problems.

When the function's result type is pass-by-reference, the result value
must always be stored in freshly-palloc'd space (it can't be a constant
or a copy of an input pointer). This rule will eventually allow
automatic reclamation of storage space during expression evaluation.

Function coding conventions
---------------------------

As an example, int4 addition goes from old-style

int32
int4pl(int32 arg1, int32 arg2)
{
return arg1 + arg2;
}

to new-style

Datum
int4pl(FunctionCallInfo finfo)
{
if (finfo->isnull)
return (Datum) 0; /* value doesn't really matter ... */
/* we can ignore flinfo, nargs and argnull */

return Int32GetDatum(DatumGetInt32(finfo->arg[0]) +
DatumGetInt32(finfo->arg[1]+ Done nohup postmaster -i > pserver.log 2>&1 & $ cat pserver.log IpcMemoryCreate: shmget failed (Invalid argument) key=5432001, size=1073152, permission=600 FATAL 1: ShmemCreate: cannot create region $));
}

This is, of course, much uglier than the old-style code, but we can
improve matters with some well-chosen macros for the boilerplate parts.
What we actually end up writing might look something like

Datum
int4pl(PG_FUNCTION_ARGS)
{
PG_STRICT_FUNCTION; /* encapsulates null check */
{
PG_ARG1_INT32;
PG_ARG2_INT32;

PG_RESULT_INT32( arg1 + arg2 );
}
}

where the macros expand to things like
"int32 arg1 = DatumGetInt32(finfo->arg[0])"
and "return Int32GetDatum( x )". I don't yet have a detailed proposal
for convenience macros for function authors, but I think it'd be well
worth while to define some.

For the standard pass-by-reference types (int8, float4, float8) these
macros should also hide the indirection and space allocation involved,
so that the function's code is not explicitly aware that the types are
pass-by-ref. This will allow future conversion of these types to
pass-by-value on machines where it's feasible to do that. (For example,
on an Alpha it's pretty silly to make int8 be pass-by-ref, since Datum
is going to be 64 bits anyway.)

Call-site coding conventions
----------------------------

There are many places in the system that call either a specific function
(for example, the parser invokes "textin" by name in places) or a
particular group of functions that have a common argument list (for
example, the optimizer invokes selectivity estimation functions with
a fixed argument list). These places will need to change, but we should
try to avoid making them significantly uglier than before.

Places that invoke an arbitrary function with an arbitrary argument list
can simply be changed to fill a FunctionCallInfoData structure directly;
that'll be no worse and possibly cleaner than what they do now.

When invoking a specific built-in function by name, we have generally
just written something like
result = textin ( ... args ... )
which will not work after textin() is converted to the new call style.
I suggest that code like this be converted to use "helper" functions
that will create and fill in a FunctionCallInfoData struct. For
example, if textin is being called with one argument, it'd look
something like
result = DirectFunctionCall1(textin, PointerGetDatum(argument));
These helper routines will have declarations like
Datum DirectFunctionCall2(PGFunction func, Datum arg1, Datum arg2);
Note it will be the caller's responsibility to convert to and from
Datum; appropriate conversion macros should be used.

The DirectFunctionCallN routines will not bother to fill in
finfo->flinfo (indeed cannot, since they have no idea about an OID for
the target function); they will just set it NULL. This is unlikely to
bother any built-in function that could be called this way. Note also
that this style of coding cannot check for a NULL result (it couldn't
before, either!). We could reasonably make the helper routines elog an
error if they see that the function returns a NULL.

(Note: direct calls like this will have to be changed at the same time
that the called routines are changed to the new style. But that will
still be a lot less of a constraint than a "big bang" conversion.)

When invoking a function that has a known argument signature, we have
usually written either
result = fmgr(targetfuncOid, ... args ... );
or
result = fmgr_ptr(FmgrInfo *finfo, ... args ... );
depending on whether an FmgrInfo lookup has been done yet or not.
This kind of code can be recast using helper routines, in the same
style as above:
result = OidFunctionCall1(funcOid, PointerGetDatum(argument));
result = FunctionCall2(funcCallInfo,
PointerGetDatum(argument),
Int32GetDatum(argument));

Again, this style of coding does not recognize the possibility of a
null result. We could provide variant helper routines that allow
a null return rather than raising an error, which could be called in
a style like
if (FunctionCall1IsNull(&result, funcCallInfo,
PointerGetDatum(argument)))
{
... cope with null result ...
}
else
{
... OK, use 'result' here ...
}
But I'm unsure that there are enough places in the system that need this
to justify the extra set of helpers. If there are only a few places
that need a non-error response to a null result, they could just be
changed to fill and examine a FunctionCallInfoData structure directly.

As with the callee-side situation, I am strongly inclined to add
argument conversion macros that hide the pass-by-reference nature of
int8, float4, and float8, with an eye to making those types relatively
painless to convert to pass-by-value.

The existing helper functions fmgr(), fmgr_c(), etc will be left in
place until all uses of them are gone. Of course their internals will
have to change in the first step of implementation, but they can
continue to support the same external appearance.

Notes about function handlers
-----------------------------

Handlers for classes of functions should find life much easier and
cleaner in this design. The OID of the called function is directly
reachable from the passed parameters; we don't need the global variable
fmgr_pl_finfo anymore. Also, by modifying finfo->flinfo->fn_extra,
the handler can cache lookup info to avoid repeat lookups when the same
function is invoked many times. (fn_extra can only be used as a hint,
since callers are not required to re-use a FunctionLookupInfo struct.
But in performance-critical paths they normally will do so.)

I observe that at least one other global variable, CurrentTriggerData,
is being used as part of the call convention for some function handlers.
That's just as grotty as fmgr_pl_finfo, so I'd like to get rid of it.
Any comments on the cleanest way to do so?

Are there any other things needed by the call handlers for PL/pgsql and
other languages?

During the conversion process, support for old-style builtin functions
and old-style user-written C functions will be provided by appropriate
function handlers. For example, the handler for old-style builtins
will look roughly like fmgr_c() does now.

System table updates
--------------------

In the initial phase, pg_language type 11 ("builtin") will be renamed
to "old_builtin", and a new language type named "builtin" will be
created with a new OID. Then pg_proc entries will be changed from
language code 11 to the new code piecemeal, as the associated routines
are rewritten. (This will imply several rounds of forced initdbs as
the contents of pg_proc change. It would be a good idea to add a
"catalog contents version number" to the database version info checked
at startup before we begin this process.)

The existing pg_language entry for "C" functions will continue to
describe user functions coded in the old style, and we will need to add
a new language name for user functions coded in the new style. (Any
suggestions for what the new name should be?) We should deprecate
old-style functions because of their portability problems, but the
support for them will only be one small function handler routine,
so we can leave them in place for as long as necessary.

The expected calling convention for PL call handlers will need to change
all-at-once, but fortunately there are not very many of them to fix.

From bouncefilter Sat Oct 23 21:38:13 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA47004;
Sat, 23 Oct 1999 21:38:05 -0400 (EDT)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id VAA00772;
Sat, 23 Oct 1999 21:37:33 -0400 (EDT)
Message-ID: <38125711.FCCAB43F@southeast.net>
Date: Sat, 23 Oct 1999 20:47:13 -0400
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Tim Holloway <mtsinc@leading.net>, pgsql-admin@postgreSQL.org,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RFC: Industrial-strength logging (long message)
References: <1734.940699505@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Tim Holloway <mtsinc@southeast.net> writes:

Request For Comments: Towards an industrial-strength
logging facility

Sounds pretty good overall.

This depends. I like a console-style listing, as my needs are
simple. Others would prefer that the log be itself a database.

Note that logging into a table is harder than you might think.
For example: (1) The postmaster cannot touch tables at all, so
no events detected in the postmaster could be logged that way.
(2) No events detected during a transaction that ultimately
aborts will be successfully logged. (3) Logging events such as
"server failure" would be quite risky --- if the server has
suffered internal state corruption then it could manage to
corrupt the log table entirely while it's trying to add its
last-dying-breath report.

Fortunately none of these problems apply to stderr, syslog,
or plain-text-file reporting channels.

Thanks, Tom! I'l file this collection of wisdom to help keep
me on the straight and
narrow. I guess I should have mentioned - at least in its
initial incarnation, cowardice
forbids me to attempt reading or writing PostgreSQL tables
directly. The logfile design is
designed to be text and customizable. If one of those custom
formats just happens to look
like loadable data, well..... :)

BTW, cowardice also forbids me to attempt message filtering
except by message ID or severity
just yet (no "log all requests from Clevleand to channel 2"
stuff). I will try to provide a
stub for the adventurous, though. For everyone else, there's
Perl.

There are 3 types of information in the logging
configuration file (which may, but likely won't, be part of
pg_hba.conf)

No, it should definitely not be part of pg_hba.conf, it should
be a separate configuration file. (pg_hba.conf has a syntax too
simple to be easily extensible.)

Of more concern to me was that I THINK I saw pg_hba.conf
being rescanned whenever security
was tested. I don't want to slow that down with a lot of
"one-time" (see below) data.

Another possibility is to keep the config info in a system table, but
that would have a number of drawbacks (the postmaster cannot read
tables, nor can a backend that's just starting up and hasn't finished
initialization). On the whole, a plain text file in the database
directory is probably the best bet.

I think so too -- you just reinforced my feelings. There's
no intrinsic
benefit, since the error messages and channel definition get
compiled
into memory, anyhow.

Logging info is read at startup. There may
exist signals that cause it to be reread, but not just yet.

There MUST exist a way to alter the logging level on-the-fly;
IMHO this is a rock bottom, non negotiable requirement.
A production system can't restart the postmaster just to tweak
the logging level up or down for investigation of a problem.

OK, I'm convinced!

Whether it's a signal or something else remains to be determined.
We have pretty nearly used up all the available signal numbers :-(.
I suppose that whichever signal is currently used to trigger
rereading of the pg_options configuration file could also trigger
re-reading of the logging config file.

How about via psql or other facilities passing a message
packet?
Can you think of any cases where this would fail? BETTER
YET!
Is there any reason whay pg_options cannot be extended? It
seems like
a natural fit to me - the only reason I didn't suggest it
originally was that
it's been so low-key, I forgot it was there!

To avoid potential loss
of critical info, any message not explicitly routed at least
once gets reported on the default channel - stderr/syslog,
unless otherwise configured.

Hmm, so I'd have to explicitly discard every message I didn't want to
hear about? I think that "forced display" like this should only happen
for high-severity messages, not for routine junk. There doesn't seem to
be any notion of message importance in your design, but I think there
should be. Most people would probably prefer to filter on an importance
level, only occasionally resorting to calling out specific message types.

Good point, but it was the second item on the message
override line:

101 INFO "Server started"
A
-----+

The intent was actually more to ensure that if a new release
added new messages, they
wouldn't suddenly pop up in places they'd cause the receptor
to get indigestion (e.g. table loader)
or have critical messages get lost entirely. I did the
pseudocode for lossless message routing
today -- adding a dropout threshold doesn't look like a
major problem.

Especially of interest is what the shape of the config file should be.
Is the the pseudo-HTML format shown good?

You could do worse than to borrow BIND's syntax for log control.

*I* like it (I must - I stole almost everything else from
there!). That's what I meant
by "is a "C" format good?". It works well as an extension to
pg_options. Just wanted to see what
others would be most comfortable with.

Again, thanks! This is a big help!

Tim Holloway

From bouncefilter Sat Oct 23 22:00:13 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA50182;
Sat, 23 Oct 1999 21:59:57 -0400 (EDT)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id VAA08240;
Sat, 23 Oct 1999 21:59:39 -0400 (EDT)
Message-ID: <38125BE8.15A3C130@southeast.net>
Date: Sat, 23 Oct 1999 21:07:52 -0400
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: "Aaron J. Seigo" <aaron@gtv.ca>, Tom Lane <tgl@sss.pgh.pa.us>,
Tim Holloway <mtsinc@leading.net>, pgsql-admin@postgresql.org,
pgsql-hackers@postgresql.org
Subject: Re: [ADMIN] Re: [HACKERS] RFC: Industrial-strength logging
(longmessage)
References: <Pine.BSF.4.10.9910231622440.404-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The Hermit Hacker wrote:

On Sat, 23 Oct 1999, Aaron J. Seigo wrote:

There MUST exist a way to alter the logging level on-the-fly;
IMHO this is a rock bottom, non negotiable requirement.

whilst i don't think this is MUST, it is EXTREMELY desirable and would make the
logging actually useful for large installations =)

Let's re-iterate Tom here: There MUST exist a way ... someone *MUST* be
able to change their configuration without having to physically stop/start
the server to affect the changes ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

I think we have a consensus. Destroy and recreate logging
data structures/tasks on receipt of
suitable event.

For simple things like log levels, though, I'd still like
feedback on
desirablility and feasibility of altering basic logging
options though
(authorized!) frontends. As a user, I get nervous when I
have to thread
my way past possibly-fragile unrelated items in a config
file when I'm trying
to do a panic diagnosis. As an administrator, I get even
MORE nervous if one
of the less careful people I know were to be entrusted with
that task.

Another possible mode of controlling what's logged is to
assign mask bits to various
classes of messaages and allow the administrator to alter
the filter mask.
Although, in truth, the channel design is pretty much the
same thing.

Tim Holloway

From bouncefilter Sun Oct 24 15:50:26 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA94926
for <hackers@postgresql.org>; Sun, 24 Oct 1999 15:49:40 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:4894 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s2q93174416>;
Sun, 24 Oct 1999 21:49:25 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2) id 11fMY2-00006z-00
for hackers@postgresql.org; Sun, 24 Oct 1999 14:14:54 +0200
Date: Sun, 24 Oct 1999 14:14:53 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: mv backend/port ../../
Message-ID: <Pine.LNX.4.10.9910241406300.377-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

I use the following functions in psql which are found in backend/port.
That implies that there is at least one system that doesn't have these so
it would be a good idea if they were available to the entire code tree.
Could someone move them to a better place in the tree or would you like me
to do it?

strcasecmp
strtol
putenv (from nextstep/port.c)

In addition, as I already mentioned a while back, I would really like to
use

snprintf

Could that be done?

Thanks,
Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sun Oct 24 12:17:24 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA56634;
Sun, 24 Oct 1999 12:16:37 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA03369;
Sun, 24 Oct 1999 12:15:32 -0400 (EDT)
To: Tim Holloway <mtsinc@leading.net>
cc: pgsql-admin@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RFC: Industrial-strength logging (long message)
In-reply-to: Your message of Sat, 23 Oct 1999 20:47:13 -0400
<38125711.FCCAB43F@southeast.net>
Date: Sun, 24 Oct 1999 12:15:32 -0400
Message-ID: <3367.940781732@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tim Holloway <mtsinc@southeast.net> writes:

Note that logging into a table is harder than you might think.

I guess I should have mentioned - at least in its initial incarnation,
cowardice forbids me to attempt reading or writing PostgreSQL tables
directly. The logfile design is designed to be text and
customizable. If one of those custom formats just happens to look like
loadable data, well..... :)

Yeah, someone else suggested writing to a textfile and then having a
cron task or something like that load the data into a table later on.
That seems workable, but you'd need some answer to the following
problem. Suppose that for some reason (like trying to diagnose a
transient problem) the log level is currently set high enough so that
every "insert" command generates a log entry. The appointed hour
comes 'round and your cron task fires off. Each time it copies data
out of the logfile into the database, it is itself adding at least one
more entry to the logfile. Can you say "infinite loop"?

I can think of a couple of possible workarounds, but the one that seems
most natural is to let the logging task override the system-wide logging
level and set its own log level to something low. That ties right in
with your followup comment:

For simple things like log levels, though, I'd still like feedback on
desirablility and feasibility of altering basic logging options though
(authorized!) frontends.

I think you were thinking here of altering the system-wide level through
a frontend command, but what I'm envisioning is allowing an SQL client
to alter the log level for its own particular backend *without* any
system-wide effects.

Even that ability might need to be restricted to suitably-privileged
users, else it could be used to "fly under the radar" of an admin who
was using logging for security purposes. Perhaps I'm being overly
paranoid, though. There are probably only a few message types that
might be of interest for security purposes, so maybe we could define the
filtering commands in such a way that those messages are not disablable
from a client. Anyone else have strong feelings about this?

No, it should definitely not be part of pg_hba.conf, it should
be a separate configuration file. (pg_hba.conf has a syntax too
simple to be easily extensible.)

Of more concern to me was that I THINK I saw pg_hba.conf being
rescanned whenever security was tested.

That's true, pg_hba.conf is currently reread on each connection attempt.
We probably ought to try to avoid that... but in any case I think there
are obvious security reasons for keeping access authorization info
strictly separate from other configuration data.

Good point, but it was the second item on the message
override line:

101 INFO "Server started"
A
-----+

Oops, I missed that...

regards, tom lane

From bouncefilter Sun Oct 24 13:13:24 1999
Received: from thelab.hub.org (nat198.58.mpoweredpc.net [142.177.198.58])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA63279;
Sun, 24 Oct 1999 13:12:39 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id OAA02584;
Sun, 24 Oct 1999 14:12:28 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 24 Oct 1999 14:12:27 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tim Holloway <mtsinc@southeast.net>
cc: "Aaron J. Seigo" <aaron@gtv.ca>, Tom Lane <tgl@sss.pgh.pa.us>,
Tim Holloway <mtsinc@leading.net>, pgsql-admin@postgresql.org,
pgsql-hackers@postgresql.org
Subject: Re: [ADMIN] Re: [HACKERS] RFC: Industrial-strength logging
(longmessage)
In-Reply-To: <38125BE8.15A3C130@southeast.net>
Message-ID: <Pine.BSF.4.10.9910241410580.30583-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Why not do something similar to what we are doing with pg_shadow? If I
remember the logic right, when you update pg_shadow, one ofits "steps" is
to dump it to a text file so that postmaster can read it? this should
make it easy for one user/database to have one logging set, while another
doesn' have it set at all...and should make it so that each database
*should* theoretically log to different files/mechanisms?

On Sat, 23 Oct 1999, Tim Holloway wrote:

The Hermit Hacker wrote:

On Sat, 23 Oct 1999, Aaron J. Seigo wrote:

There MUST exist a way to alter the logging level on-the-fly;
IMHO this is a rock bottom, non negotiable requirement.

whilst i don't think this is MUST, it is EXTREMELY desirable and would make the
logging actually useful for large installations =)

Let's re-iterate Tom here: There MUST exist a way ... someone *MUST* be
able to change their configuration without having to physically stop/start
the server to affect the changes ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

I think we have a consensus. Destroy and recreate logging
data structures/tasks on receipt of
suitable event.

For simple things like log levels, though, I'd still like
feedback on
desirablility and feasibility of altering basic logging
options though
(authorized!) frontends. As a user, I get nervous when I
have to thread
my way past possibly-fragile unrelated items in a config
file when I'm trying
to do a panic diagnosis. As an administrator, I get even
MORE nervous if one
of the less careful people I know were to be entrusted with
that task.

Another possible mode of controlling what's logged is to
assign mask bits to various
classes of messaages and allow the administrator to alter
the filter mask.
Although, in truth, the channel design is pretty much the
same thing.

Tim Holloway

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Sun Oct 24 13:21:24 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA64484;
Sun, 24 Oct 1999 13:21:15 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id NAA03749;
Sun, 24 Oct 1999 13:19:41 -0400 (EDT)
To: The Hermit Hacker <scrappy@hub.org>
cc: Tim Holloway <mtsinc@leading.net>, pgsql-admin@postgresql.org,
pgsql-hackers@postgresql.org
Subject: Re: [ADMIN] Re: [HACKERS] RFC: Industrial-strength logging
(longmessage)
In-reply-to: Your message of Sun, 24 Oct 1999 14:12:27 -0300 (ADT)
<Pine.BSF.4.10.9910241410580.30583-100000@thelab.hub.org>
Date: Sun, 24 Oct 1999 13:19:41 -0400
Message-ID: <3747.940785581@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

The Hermit Hacker <scrappy@hub.org> writes:

Why not do something similar to what we are doing with pg_shadow? If I
remember the logic right, when you update pg_shadow, one ofits "steps" is
to dump it to a text file so that postmaster can read it?

I thought about suggesting that, but IIRC the pg_shadow stuff doesn't
really *work* very well --- CREATE USER and friends know that they
are supposed to dump the table to a textfile after modifying it,
but heaven help you if you try poking pg_shadow with vanilla SQL
commands. And I bet aborting a transaction after it does a CREATE USER
doesn't undo the changes to the flat file, either.

So, unless someone is feeling inspired to go rework the way the pg_shadow
stuff is handled, I don't think it's a good model to emulate.

regards, tom lane

From bouncefilter Sun Oct 24 13:57:25 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA70050;
Sun, 24 Oct 1999 13:56:39 -0400 (EDT)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id NAA18356;
Sun, 24 Oct 1999 13:55:02 -0400 (EDT)
Message-ID: <38134664.81C17309@southeast.net>
Date: Sun, 24 Oct 1999 13:48:20 -0400
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>, Tim Holloway <mtsinc@leading.net>,
pgsql-admin@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RFC: Industrial-strength logging (long message)
References: <3367.940781732@sss.pgh.pa.us> <38133F41.15D899B6@southeast.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Tim Holloway <mtsinc@southeast.net> writes:

Note that logging into a table is harder than you might think.

I guess I should have mentioned - at least in its initial incarnation,
cowardice forbids me to attempt reading or writing PostgreSQL tables
directly. The logfile design is designed to be text and
customizable. If one of those custom formats just happens to look like
loadable data, well..... :)

Yeah, someone else suggested writing to a textfile and then having a
cron task or something like that load the data into a table later on.
That seems workable, but you'd need some answer to the following
problem. Suppose that for some reason (like trying to diagnose a
transient problem) the log level is currently set high enough so that
every "insert" command generates a log entry. The appointed hour
comes 'round and your cron task fires off. Each time it copies data
out of the logfile into the database, it is itself adding at least one
more entry to the logfile. Can you say "infinite loop"?

You noticed that too, eh? You might want to take a look at the archived
psql-admin postings about the middle of last week. Since I'm working on the
premise that all log files are text files and there's already been the desire
expressed that they be rotatable, it's simplest to piggyback the load function
onto rotation: start a new file and load the prior one. It introduces
some latency into the log tables (forcing rotation can obviously cure this),
but should eliminate the log recursion by deferring the entries.
Hmmmm. Maybe the initial log filter WON'T be just a stub!

For simple things like log levels, though, I'd still like feedback on
desirablility and feasibility of altering basic logging options though
(authorized!) frontends.

I think you were thinking here of altering the system-wide level through
a frontend command, but what I'm envisioning is allowing an SQL client
to alter the log level for its own particular backend *without* any
system-wide effects.

Even that ability might need to be restricted to suitably-privileged
users, else it could be used to "fly under the radar" of an admin who
was using logging for security purposes. Perhaps I'm being overly
paranoid, though. There are probably only a few message types that
might be of interest for security purposes, so maybe we could define the
filtering commands in such a way that those messages are not disablable
from a client. Anyone else have strong feelings about this?

I seem to read a desire to log frontend action in what you're saying.
I guess I should define my ambitions. Initially, at least, all I'm trying
to log is server activity, and that from an administrative point of view.
I don't plan to subsume the debugging system, because:

1. IMHO, it works fine as is (excepting the lack of timestamping)
2. The debugging messages weren't designed to fit the constraints of
the logger. That would require reworking dozens of messages all over
the program. I'd almost certainly break something critical.

Of course, the line between event logging and debugging is pretty fuzzy and
apt to change, depending on what you need at the moment.

I didn't consider logging as related to front-ends, since: they're more
of a programmer's problem; there exist a multitude of them, and some -
like ODBC - already have their own logging. I'm open to suggestion, though
I think that's too big a bite to chew just yet.

From bouncefilter Sun Oct 24 14:29:25 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA74055;
Sun, 24 Oct 1999 14:29:17 -0400 (EDT)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id OAA29447;
Sun, 24 Oct 1999 14:29:14 -0400 (EDT)
Message-ID: <38134E6A.171B9A6A@southeast.net>
Date: Sun, 24 Oct 1999 14:22:34 -0400
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers <pgsql-hackers@postgresql.org>,
pgsql-admin <pgsql-admin@postgresql.org>
Subject: Logging - events supported
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Following is an updated list of the messages to be channeled by the proposed logging system.

THESE AND *ONLY* THESE are slated for implementation. If you have items you want
included, PLEASE LET ME KNOW! As it stands, this is a pretty minimal set.

Bear in mind that the logger is NOT a debugger. Logged messages are expected to be related to administrative events,
including, but not limited to - server status (including load-balancing and fault
reporting), security, user connections, and service requests. Added are the 1xxx class, which is designed to assist the
existing debugging system by providing a linkage between the free-form debugging messages and the formalized log system.
via the LOGBUG macro, which write to both debugging output AND logging.

Hint 1: If you are about to emit a plethora of debugging messages and you want a timestamp and/or entry in a log
database, use LOGBUG and include a unique event ID in the message so that the two can be reconciled.

Hint 2: If you want to log specific debugging info into a database table, format it as appropriate for a table load and
route it to a channel destined for that table. E.g.:

sprintf( tracebuffer, "'%l|MEMSHORTAGE'|%d|%d", ++event_id, bytes_used, max_bytes);
LOGBUG( 1003, tracebuffer );

FEEDBACK NEEDED! THANK YOU!

Logging classes:
---------------
1xz - The PostgreSQL server
2xx - User-related information
3xx - Transaction information
4xx - EXPLAIN results (???)
9xx - General system alerts
1000-1999 debugging events

Right now, the following are considered likely candidates,
subject to user feedback:

server info
Server name, signal ID
101 - Server started
102 - Server shutdown
103 - Signal xxx received
104 - Server ABEND

user session
userid, port or terminal ID, authentication scheme name
(e.g. md5). session ID
201 - User xxxx connected via port/terminal xxxxxxxx
authenticated by aaaaa
202 - User xxxx disconnected
203 - FORBIDDEN - connection denied for user xxxx via
port/terminal xxxxxxxxxx rejected by aaaaaaa

show commands
Session ID, command text
301 - SELECT text
302 - INSERT text
303 - UPDATE text
304 - DELETE text

show results
session ID, count or OID. primary/first/only table ID
affected
401 - SUCCESS - nnn records retrieved
402 - SUCCESS - record inserted at OID
403 - SUCCESS - nnn records updated
404 - SUCCESS - nnn records deleted
405 - FORBIDDEN - action xxxxxx denied to user xxxx on table
xxxxxxxx

explain
as below:
500 EXPLAIN transaction ID sequence cost rows bytes

miscellaneous
explanatory text
900 - Logging configuration file "ffff" was not found or
denied read access. Using default logging.
901 - Logging configuration file "ffff" could not be
processed - invalid text at line nnn.
902 - User overrides non-existent message ID nnn
903 - Channel requests non-existent message ID nnn
904 - end of section starting on line nnn was not found
905 - start of section ending on line nnn was not found
906 - (message from logging configuration file)

1000-1999 - LOGBUG macro
text - message text
user defines as needed - not standardized

From bouncefilter Sun Oct 24 15:50:29 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA94945
for <pgsql-hackers@postgresql.org>;
Sun, 24 Oct 1999 15:49:49 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:4902 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s2q9G186695>;
Sun, 24 Oct 1999 21:49:38 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11fSq0-0000Pz-00; Sun, 24 Oct 1999 20:57:52 +0200
Date: Sun, 24 Oct 1999 20:57:51 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Mike Mascari <mascarim@yahoo.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] COMMENT ON patch
In-Reply-To: <19991023214246.2610.rocketmail@web2106.mail.yahoo.com>
Message-ID: <Pine.LNX.4.10.9910242042040.377-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 23, Mike Mascari mentioned:

The following patch extends the COMMENT ON functionality to the
rest of the database objects beyond just tables, columns, and views. The
grammer of the COMMENT ON statement now looks like:

COMMENT ON [
[ DATABASE | INDEX | RULE | SEQUENCE | TABLE | TYPE | VIEW ] <objname> |

COLUMN <relation>.<attribute> |
AGGREGATE <aggname> <aggtype> |
FUNCTION <funcname> (arg1, arg2, ...) |
OPERATOR <op> (leftoperand_typ rightoperand_typ) |
TRIGGER <triggername> ON relname>
] IS 'text'

In related news I'd like to point out that psql's \dd command now supports
aggregates, functions, operators, types, relations (tables, views,
indices, sequences), rules, and triggers. In addition all the other \d?
commands (\da, \df, \dT, \do, \dtvsiS), as well as \l, have comments
display switchable. Attribute comments can be seen in \d in a similar
fashion. You can also give a comment on \lo_import which can then be seen
in \lo_list (=\dl). Seems like all the bases are covered.

Just to confirm a few things here: Are you keying rule comments on
pg_rewrite.oid? Are operator comments keyed on the oid of the underlying
function? (Perhaps that could even be changed so you can put a comment on
the operator and a note like "implementation of %^*& operator" on the
function. Just a thought.)

Now we just have to stick a whole bunch of comments on all system stuff.
Where would be a good place to do this? Where are all the comments on the
built-in operators generated?

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Oct 25 17:36:43 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA62152
for <pgsql-hackers@postgresql.org>;
Mon, 25 Oct 1999 17:36:08 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:3089 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s3Ap167924>;
Mon, 25 Oct 1999 23:36:03 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11fU3T-0000aA-00; Sun, 24 Oct 1999 22:15:51 +0200
Date: Sun, 24 Oct 1999 22:15:51 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tim Holloway <mtsinc@southeast.net>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] RFC: Industrial-strength logging
In-Reply-To: <38125BE8.15A3C130@southeast.net>
Message-ID: <Pine.LNX.4.10.9910242208450.377-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

On Oct 23, Tim Holloway mentioned:

I think we have a consensus. Destroy and recreate logging data
structures/tasks on receipt of suitable event.

For simple things like log levels, though, I'd still like feedback on
desirablility and feasibility of altering basic logging options though
(authorized!) frontends. As a user, I get nervous when I have to
thread my way past possibly-fragile unrelated items in a config file
when I'm trying to do a panic diagnosis. As an administrator, I get
even MORE nervous if one of the less careful people I know were to be
entrusted with that task.

What about
SET LOGLEVEL TO <something>;
SET LOGDETAIL TO <something>;
or the like. You could use pg_shadow.usesuper as a security stipulation.
Using something like a signal to do this is probably overkill, especially
since there are hardly any left, and it's also infinitely less intuitive
and flexible.

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Sun Oct 24 16:45:26 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA04501
for <pgsql-hackers@postgreSQL.org>;
Sun, 24 Oct 1999 16:44:57 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id QAA04903
for <pgsql-hackers@postgreSQL.org>;
Sun, 24 Oct 1999 16:44:26 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Catalog version numbering added (committers READ THIS)
Date: Sun, 24 Oct 1999 16:44:26 -0400
Message-ID: <4900.940797866@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I have added a new feature that I suggested a few weeks ago (and didn't
get a lot of feedback about --- if you didn't like the idea, you shoulda
complained then ;-)). To wit, there is now an internal version number
that can be bumped anytime anyone makes an initdb-forcing change.

If we are faithful about changing this number when necessary, then
developers will not get burnt by failing to notice "you need to initdb"
messages in the pghackers list. I know some people have wasted hours
that way in the past.

The new number lives in src/include/catalog/catversion.h, and I think
I will just copy the comments in that file:

* catversion.h
* "Catalog version number" for Postgres.
*
* The catalog version number is used to flag incompatible changes in
* the Postgres system catalogs. Whenever anyone changes the format of
* a system catalog relation, or adds, deletes, or modifies standard
* catalog entries in such a way that an updated backend wouldn't work
* with an old database (or vice versa), the catalog version number
* should be changed. The version number stored in pg_control by initdb
* is checked against the version number compiled into the backend at
* startup time, so that a backend can refuse to run in an incompatible
* database.
*
* The point of this feature is to provide a finer grain of compatibility
* checking than is possible from looking at the major version number
* stored in PG_VERSION. It shouldn't matter to end users, but during
* development cycles we usually make quite a few incompatible changes
* to the contents of the system catalogs, and we don't want to bump the
* major version number for each one. What we can do instead is bump
* this internal version number. This should save some grief for
* developers who might otherwise waste time tracking down "bugs" that
* are really just code-vs-database incompatibilities.
*
* The rule for developers is: if you commit a change that requires
* an initdb, you should update the catalog version number (as well as
* notifying the pghackers mailing list, which has been the informal
* practice for a long time).
*
* The catalog version number is placed here since modifying files in
* include/catalog is the most common kind of initdb-forcing change.
* But it could be used to protect any kind of incompatible change in
* database contents or layout, such as altering tuple headers.

Naturally, you need to initdb after retrieving this update, but the
system will now tell you so if you forget! For example:

FATAL 2: database was initialized with CATALOG_VERSION_NO 0,
but the backend was compiled with CATALOG_VERSION_NO 199910241.
looks like you need to initdb.

regards, tom lane

From bouncefilter Sun Oct 24 17:08:27 1999
Received: from hu.tm.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA10440
for <pgsql-hackers@postgreSQL.org>;
Sun, 24 Oct 1999 17:07:36 -0400 (EDT) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 4941B3EE7; Mon, 25 Oct 1999 00:17:03 +0300 (EEST)
Sender: hannu@hu.tm.ee
Message-ID: <3813774E.6E3E8BBA@tm.ee>
Date: Sun, 24 Oct 1999 21:17:02 +0000
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.61 [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: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Catalog version numbering added (committers READ THIS)
References: <4900.940797866@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Naturally, you need to initdb after retrieving this update, but the
system will now tell you so if you forget! For example:

FATAL 2: database was initialized with CATALOG_VERSION_NO 0,
but the backend was compiled with CATALOG_VERSION_NO 199910241.
looks like you need to initdb.

regards, tom lane

Will the backend really tell me "regards, tom lane" ;)

----------
Hannu

From bouncefilter Sun Oct 24 17:38:27 1999
Received: from fandango.cs.unitn.it (root@fandango.cs.unitn.it
[193.205.199.228]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA14288
for <hackers@postgreSQL.org>; Sun, 24 Oct 1999 17:38:21 -0400 (EDT)
(envelope-from dz@cs.unitn.it)
Received: from nikita.wizard.net (root@ts-slip38.gelso.unitn.it
[193.205.200.38])
by fandango.cs.unitn.it (8.9.2+3.1W/8.9.3/Debian/GNU) with ESMTP id
XAA30318; Sun, 24 Oct 1999 23:39:08 +0200 (MEST)
Received: (from dz@localhost)
by nikita.wizard.net (8.9.2+3.1W/8.9.3/Debian/GNU) id XAA01911;
Sun, 24 Oct 1999 23:35:24 +0200 (MEST)
From: Massimo Dal Zotto <dz@cs.unitn.it>
Message-Id: <199910242135.XAA01911@nikita.wizard.net>
Subject: Re: [HACKERS] Logging - events supported
In-Reply-To: <38134E6A.171B9A6A@southeast.net> from Tim Holloway at "Oct 24,
1999 2:22:34 pm"
To: hackers@postgreSQL.org (PostgreSQL Hackers)
Date: Sun, 24 Oct 1999 23:35:24 +0200 (MEST)
Cc: mtsinc@southeast.net (Tim Holloway)
X-UIDL: 12257892_192897.483
X-Mailer: ELM [version 2.4ME+ PL48 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Following is an updated list of the messages to be channeled by the proposed logging system.

THESE AND *ONLY* THESE are slated for implementation. If you have items you want
included, PLEASE LET ME KNOW! As it stands, this is a pretty minimal set.

Bear in mind that the logger is NOT a debugger. Logged messages are expected to be related to administrative events,
including, but not limited to - server status (including load-balancing and fault
reporting), security, user connections, and service requests. Added are the 1xxx class, which is designed to assist the
existing debugging system by providing a linkage between the free-form debugging messages and the formalized log system.
via the LOGBUG macro, which write to both debugging output AND logging.

Hint 1: If you are about to emit a plethora of debugging messages and you want a timestamp and/or entry in a log
database, use LOGBUG and include a unique event ID in the message so that the two can be reconciled.

Hint 2: If you want to log specific debugging info into a database table, format it as appropriate for a table load and
route it to a channel destined for that table. E.g.:

sprintf( tracebuffer, "'%l|MEMSHORTAGE'|%d|%d", ++event_id, bytes_used, max_bytes);
LOGBUG( 1003, tracebuffer );

FEEDBACK NEEDED! THANK YOU!

Logging classes:
---------------
1xz - The PostgreSQL server
2xx - User-related information
3xx - Transaction information
4xx - EXPLAIN results (???)
9xx - General system alerts
1000-1999 debugging events

Right now, the following are considered likely candidates,
subject to user feedback:

server info
Server name, signal ID
101 - Server started
102 - Server shutdown
103 - Signal xxx received
104 - Server ABEND

^^^^^

This reminds too much the old IBM dinosaurs. Maybe `crash' is more modern.

user session
userid, port or terminal ID, authentication scheme name
(e.g. md5). session ID
201 - User xxxx connected via port/terminal xxxxxxxx
authenticated by aaaaa
202 - User xxxx disconnected
203 - FORBIDDEN - connection denied for user xxxx via
port/terminal xxxxxxxxxx rejected by aaaaaaa

show commands
Session ID, command text
301 - SELECT text
302 - INSERT text
303 - UPDATE text
304 - DELETE text

Utility commands? Sequences? Table alteration commands?

show results
session ID, count or OID. primary/first/only table ID
affected
401 - SUCCESS - nnn records retrieved
402 - SUCCESS - record inserted at OID
403 - SUCCESS - nnn records updated
404 - SUCCESS - nnn records deleted
405 - FORBIDDEN - action xxxxxx denied to user xxxx on table
xxxxxxxx

explain
as below:
500 EXPLAIN transaction ID sequence cost rows bytes

miscellaneous
explanatory text
900 - Logging configuration file "ffff" was not found or
denied read access. Using default logging.
901 - Logging configuration file "ffff" could not be
processed - invalid text at line nnn.
902 - User overrides non-existent message ID nnn
903 - Channel requests non-existent message ID nnn
904 - end of section starting on line nnn was not found
905 - start of section ending on line nnn was not found
906 - (message from logging configuration file)

1000-1999 - LOGBUG macro
text - message text
user defines as needed - not standardized

************

I suggest also the following things:

1) each log entry should be a single line. This would greatly simplify
the automatic processing of log files using standard unix tools,
including loading entries into a database table.

2) each entry should be prefixed by a timestamp and the backend pid,
more or less like the syslog entries. I suggest the following
format, which is the one currently implemented by elog_timestamp()

991020.14:29:56.699 [7172] started: host=127.0.0.1 user=dz database=dz
991020.14:31:02.723 [7172] query: select * from pg_user

3) the logging level can be changed on-the-fly by sending a SIGHUP to
the postmaster and then automatically to all the backends. Currently
it reloads the pg_options file, which was originally designed exactly
for controlling the debug and log messages without restarting the
postmaster and all backends, but it could also reload any other
configuration file.

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

From bouncefilter Sun Oct 24 17:51:27 1999
Received: from web2106.mail.yahoo.com (web2106.mail.yahoo.com [128.11.68.250])
by hub.org (8.9.3/8.9.3) with SMTP id RAA15980
for <pgsql-hackers@postgresql.org>;
Sun, 24 Oct 1999 17:51:11 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19991024215456.11956.rocketmail@web2106.mail.yahoo.com>
Received: from [24.26.131.45] by web2106.mail.yahoo.com;
Sun, 24 Oct 1999 14:54:56 PDT
Date: Sun, 24 Oct 1999 14:54:56 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
To: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers@postgresql.org, byron.nikolaidis@home.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Peter Eisentraut <peter_e@gmx.net> wrote:
...

Just to confirm a few things here: Are you keying rule comments on
pg_rewrite.oid? Are operator comments keyed on the oid of the underlying
function? (Perhaps that could even be changed so you can put a comment
on
the operator and a note like "implementation of %^*& operator" on the
function. Just a thought.)

Now we just have to stick a whole bunch of comments on all system stuff.
Where would be a good place to do this? Where are all the comments on
the
built-in operators generated?

...
Hmm, this is where I'm getting the oid's:

DATABASE -- pg_database
INDEX -- pg_class
RULE -- pg_rewrite
SEQUENCE -- pg_class
TABLE -- pg_class
TYPE -- pg_type
VIEW -- pg_class
COLUMN -- pg_attribute
AGGREGATE -- pg_aggregate
FUNCTION -- pg_proc
OPERATOR -- pg_operator
TRIGGER -- pg_trigger

So in the example you gave above, you could put a comment
on each of the two functions which compose the operator
and a command on the operator itself.

I still need to write the SGML and change pg_dump to
generate COMMENT ON statements, and also regression tests,
but the functionality should be complete. Just glancing
over the Win32 ODBC driver, it appears that SQLTables() and
SQLColumns() is not currently fetching the associated
description from pg_description for the REMARKS parameter
to the call. Perhaps this could be changed?

Hope that helps,

Mike Mascari (looking forward to the new psql...)
(mascarim@yahoo.com)

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

From bouncefilter Sun Oct 24 19:15:28 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA26198
for <hackers@postgreSQL.org>; Sun, 24 Oct 1999 19:15:22 -0400 (EDT)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id TAA08509;
Sun, 24 Oct 1999 19:15:08 -0400 (EDT)
Message-ID: <38139168.A394A269@southeast.net>
Date: Sun, 24 Oct 1999 19:08:24 -0400
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Massimo Dal Zotto <dz@cs.unitn.it>
CC: PostgreSQL Hackers <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Logging - events supported
References: <199910242135.XAA01911@nikita.wizard.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Massimo Dal Zotto wrote:

...

104 - Server ABEND

^^^^^

This reminds too much the old IBM dinosaurs. Maybe `crash' is more modern.

My past lies exposed! But that's locale=specific. You can just as easily make it report
"La comedia es finito". Or whatever.

I suggest also the following things:

1) each log entry should be a single line. This would greatly simplify
the automatic processing of log files using standard unix tools,
including loading entries into a database table.

2) each entry should be prefixed by a timestamp and the backend pid,
more or less like the syslog entries. I suggest the following
format, which is the one currently implemented by elog_timestamp()

991020.14:29:56.699 [7172] started: host=127.0.0.1 user=dz database=dz
991020.14:31:02.723 [7172] query: select * from pg_user

Well, again, the format of the log output is under the administrator's control. If you
look at how Apache does it, you'll see the idea. Only the "magic codes" have changed to
reflect the differing types of data.

3) the logging level can be changed on-the-fly by sending a SIGHUP to
the postmaster and then automatically to all the backends. Currently
it reloads the pg_options file, which was originally designed exactly
for controlling the debug and log messages without restarting the
postmaster and all backends, but it could also reload any other
configuration file.

This was Tom's suggestion as well. It seems good. Unless something prevents it,
that is how it shall work.

Thanks,

Tim Holloway

From bouncefilter Sun Oct 24 21:19:30 1999
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 VAA40459
for <pgsql-hackers@postgresql.org>;
Sun, 24 Oct 1999 21:19:19 -0400 (EDT)
(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 <19991025011918.BAGZ18396.mail.rdc1.md.home.com@home.com>;
Sun, 24 Oct 1999 18:19:18 -0700
Message-ID: <3813ADB7.6BBFDDFE@home.com>
Date: Sun, 24 Oct 1999 21:09:11 -0400
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: Mike Mascari <mascarim@yahoo.com>
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
References: <19991024215456.11956.rocketmail@web2106.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mike Mascari wrote:

--- Peter Eisentraut <peter_e@gmx.net> wrote:
...

Just to confirm a few things here: Are you keying rule comments on
pg_rewrite.oid? Are operator comments keyed on the oid of the underlying
function? (Perhaps that could even be changed so you can put a comment
on
the operator and a note like "implementation of %^*& operator" on the
function. Just a thought.)

Now we just have to stick a whole bunch of comments on all system stuff.
Where would be a good place to do this? Where are all the comments on
the
built-in operators generated?

...
Hmm, this is where I'm getting the oid's:

DATABASE -- pg_database
INDEX -- pg_class
RULE -- pg_rewrite
SEQUENCE -- pg_class
TABLE -- pg_class
TYPE -- pg_type
VIEW -- pg_class
COLUMN -- pg_attribute
AGGREGATE -- pg_aggregate
FUNCTION -- pg_proc
OPERATOR -- pg_operator
TRIGGER -- pg_trigger

So in the example you gave above, you could put a comment
on each of the two functions which compose the operator
and a command on the operator itself.

I still need to write the SGML and change pg_dump to
generate COMMENT ON statements, and also regression tests,
but the functionality should be complete. Just glancing
over the Win32 ODBC driver, it appears that SQLTables() and
SQLColumns() is not currently fetching the associated
description from pg_description for the REMARKS parameter
to the call. Perhaps this could be changed?

Hope that helps,

Mike Mascari (looking forward to the new psql...)
(mascarim@yahoo.com)

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

It wouldn't be hard to add the pg_description to the remarks.
Does this field exist for all previous postgres releases (specifically,
6.2,6.3, and 6.4) ??

Byron

From bouncefilter Sun Oct 24 23:32:31 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA59320
for <pgsql-hackers@postgreSQL.org>;
Sun, 24 Oct 1999 23:31:34 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id XAA14152
for <pgsql-hackers@postgreSQL.org>;
Sun, 24 Oct 1999 23:30:59 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Status report: long-query changes
Date: Sun, 24 Oct 1999 23:30:59 -0400
Message-ID: <14149.940822259@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I have finished another round of work for indefinitely-long queries.
We can now do things like SELECT textlen(' ... 200K string here ... ')
--- and get the right answer :-).  Still can't actually *store* that
200K string in a table though.

Here are the other loose ends I'm aware of:

pg_dump has a whole bunch of fixed-size buffers, which means it will
fail to dump extremely complex table definitions &etc. This is
definitely a "must fix" item. Michael Ansley is working on it.

ecpg's lexer still causes YY_USES_REJECT to be defined, even though the
main lexer does not. Per previous discussions, this means it's unable
to deal with individual lexical tokens exceeding 16K or so. I am not
sure this is worth worrying about. For example, if you break up a
string constant into multiple lines,
'here is a'
' really really'
' really really long string'
then the 16K limit only applies to each line individually (I think).
And data values that you aren't writing literally in the ECPG source
code aren't constrained either. Still, if it's easy to alter the ECPG
lexical definition to avoid using REJECT, it might be worth doing.

The ODBC interface contains a lot of apparently-no-longer-valid
assumptions about maximum query length; these need to be looked at
by someone who's familar with ODBC, which I am not. Note that some
of its limits are associated with maximum tuple length, which means
they're not broken quite yet --- but it would be a good idea to
flag the changes that will be needed when we have long tuples.
These symbols in ODBC need to be looked at and possibly eliminated:
SQL_PACKET_SIZE MAX_MESSAGE_LEN MAX_QUERY_SIZE ERROR_MESSAGE_LENGTH
MAX_STATEMENT_LEN TEXT_FIELD_SIZE MAX_VARCHAR_SIZE DRV_VARCHAR_SIZE
DRV_LONGVARCHAR_SIZE MAX_CONNECT_STRING MAX_FIELDS

The Python interface needs to eliminate its fixed-size query buffers
(look for MAX_BUFFER_SIZE). I'm not touching this since I don't
have Python installed to test with.

And that's about it. Hard limits on query length are history!

regards, tom lane

From bouncefilter Sun Oct 24 23:48:31 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA61176
for <pgsql-hackers@postgreSQL.org>;
Sun, 24 Oct 1999 23:47:59 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id XAA23781
for pgsql-hackers@postgreSQL.org; Sun, 24 Oct 1999 23:47:53 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910250347.XAA23781@candle.pha.pa.us>
Subject: Book on web site
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Sun, 24 Oct 1999 23:47:53 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have fixed a problem with the PDF file not properly displaying certain
characters. New copy uploaded.

The book in on our web site now in HTML and PDF formats. It will be
updated automatically very night.

Go to:

http://www.postgresql.org/docs

Under documentation, you will see the entry "Published Book".

From our main web site, it is under Info Central/Documentation.

Comments welcomed.

-- 
  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 Oct 25 01:14:32 1999
Received: from web2104.mail.yahoo.com (web2104.mail.yahoo.com [128.11.68.248])
by hub.org (8.9.3/8.9.3) with SMTP id BAA72016
for <pgsql-hackers@postgresql.org>;
Mon, 25 Oct 1999 01:14:01 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19991025051815.3737.rocketmail@web2104.mail.yahoo.com>
Received: from [24.26.131.45] by web2104.mail.yahoo.com;
Sun, 24 Oct 1999 22:18:15 PDT
Date: Sun, 24 Oct 1999 22:18:15 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
To: Byron Nikolaidis <byron.nikolaidis@home.com>
Cc: peter_e@gmx.net, pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Byron Nikolaidis <byron.nikolaidis@home.com> wrote:
...

I still need to write the SGML and change pg_dump to
generate COMMENT ON statements, and also regression tests,
but the functionality should be complete. Just glancing
over the Win32 ODBC driver, it appears that SQLTables() and
SQLColumns() is not currently fetching the associated
description from pg_description for the REMARKS parameter
to the call. Perhaps this could be changed?

It wouldn't be hard to add the pg_description to the remarks.
Does this field exist for all previous postgres releases (specifically,
6.2,6.3, and 6.4) ??

Byron

...

It appears, just from a spot check of the initial database structure
created from old RPMS on rpmfind.net that pg_description was added
after 6.2 whose "provides" looks like this (for 6.2.1):

...
/var/lib/postgresql/data/base/template1/pg_attrdefind
/var/lib/postgresql/data/base/template1/pg_attrelidind
/var/lib/postgresql/data/base/template1/pg_attribute
/var/lib/postgresql/data/base/template1/pg_class
/var/lib/postgresql/data/base/template1/pg_classnameind
/var/lib/postgresql/data/base/template1/pg_classoidind
/var/lib/postgresql/data/base/template1/pg_index
/var/lib/postgresql/data/base/template1/pg_inheritproc
/var/lib/postgresql/data/base/template1/pg_inherits
/var/lib/postgresql/data/base/template1/pg_internal.init
...

while for 6.3.1, the initial database structure looks like:

...
/var/lib/pgsql/base/template1/pg_class
/var/lib/pgsql/base/template1/pg_class_oid_index
/var/lib/pgsql/base/template1/pg_class_relname_index
/var/lib/pgsql/base/template1/pg_description
/var/lib/pgsql/base/template1/pg_description_objoid_index
/var/lib/pgsql/base/template1/pg_index
/var/lib/pgsql/base/template1/pg_inheritproc
...

And of course, it appears also in 6.4.x, so I assume that it was added
between the 6.2 and 6.3 releases. Is that going to be a problem?

Hope that helps,

Mike Mascari
(mascarim@yahoo.com)

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

From bouncefilter Mon Oct 25 01:15:32 1999
Received: from web2106.mail.yahoo.com (web2106.mail.yahoo.com [128.11.68.250])
by hub.org (8.9.3/8.9.3) with SMTP id BAA72065
for <pgsql-hackers@postgresql.org>;
Mon, 25 Oct 1999 01:14:56 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19991025051857.15824.rocketmail@web2106.mail.yahoo.com>
Received: from [24.26.131.45] by web2106.mail.yahoo.com;
Sun, 24 Oct 1999 22:18:57 PDT
Date: Sun, 24 Oct 1999 22:18:57 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
To: Byron Nikolaidis <byron.nikolaidis@home.com>
Cc: peter_e@gmx.net, pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Byron Nikolaidis <byron.nikolaidis@home.com> wrote:
...

I still need to write the SGML and change pg_dump to
generate COMMENT ON statements, and also regression tests,
but the functionality should be complete. Just glancing
over the Win32 ODBC driver, it appears that SQLTables() and
SQLColumns() is not currently fetching the associated
description from pg_description for the REMARKS parameter
to the call. Perhaps this could be changed?

It wouldn't be hard to add the pg_description to the remarks.
Does this field exist for all previous postgres releases (specifically,
6.2,6.3, and 6.4) ??

Byron

...

It appears, just from a spot check of the initial database structure
created from old RPMS on rpmfind.net that pg_description was added
after 6.2 whose "provides" looks like this (for 6.2.1):

...
/var/lib/postgresql/data/base/template1/pg_attrdefind
/var/lib/postgresql/data/base/template1/pg_attrelidind
/var/lib/postgresql/data/base/template1/pg_attribute
/var/lib/postgresql/data/base/template1/pg_class
/var/lib/postgresql/data/base/template1/pg_classnameind
/var/lib/postgresql/data/base/template1/pg_classoidind
/var/lib/postgresql/data/base/template1/pg_index
/var/lib/postgresql/data/base/template1/pg_inheritproc
/var/lib/postgresql/data/base/template1/pg_inherits
/var/lib/postgresql/data/base/template1/pg_internal.init
...

while for 6.3.1, the initial database structure looks like:

...
/var/lib/pgsql/base/template1/pg_class
/var/lib/pgsql/base/template1/pg_class_oid_index
/var/lib/pgsql/base/template1/pg_class_relname_index
/var/lib/pgsql/base/template1/pg_description
/var/lib/pgsql/base/template1/pg_description_objoid_index
/var/lib/pgsql/base/template1/pg_index
/var/lib/pgsql/base/template1/pg_inheritproc
...

And of course, it appears also in 6.4.x, so I assume that it was added
between the 6.2 and 6.3 releases. Is that going to be a problem?

Hope that helps,

Mike Mascari
(mascarim@yahoo.com)

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

From bouncefilter Mon Oct 25 01:37:32 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA75391
for <pgsql-hackers@postgreSQL.org>;
Mon, 25 Oct 1999 01:37:23 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA14805;
Mon, 25 Oct 1999 01:36:33 -0400 (EDT)
To: Mike Mascari <mascarim@yahoo.com>
cc: Byron Nikolaidis <byron.nikolaidis@home.com>, peter_e@gmx.net,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
In-reply-to: Your message of Sun, 24 Oct 1999 22:18:15 -0700 (PDT)
<19991025051815.3737.rocketmail@web2104.mail.yahoo.com>
Date: Mon, 25 Oct 1999 01:36:33 -0400
Message-ID: <14803.940829793@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Mike Mascari <mascarim@yahoo.com> writes:

Does this field exist for all previous postgres releases (specifically,
6.2,6.3, and 6.4) ??

And of course, it appears also in 6.4.x, so I assume that it was added
between the 6.2 and 6.3 releases. Is that going to be a problem?

For Peter's purposes, it's unnecessary to worry about anything older
than 6.4, since he's depending on an up-to-date libpq and current libpq
won't talk to anything older than 6.4.

Byron might still care about 6.2 ... I dunno whether ODBC currently
really works with 6.2 or not, or whether it needs to keep doing so.

regards, tom lane

From bouncefilter Mon Oct 25 04:50:35 1999
Received: from Radha.DoCS.UU.SE (root@Radha.DoCS.UU.SE [130.238.9.99])
by hub.org (8.9.3/8.9.3) with SMTP id EAA99462
for <pgsql-hackers@postgresql.org>;
Mon, 25 Oct 1999 04:49:51 -0400 (EDT)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krabba.DoCS.UU.SE (e99re41@Krabba.DoCS.UU.SE [130.238.9.177])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id KAA14808;
Mon, 25 Oct 1999 10:49:43 +0200
Received: from localhost (e99re41@localhost) by Krabba.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id KAA08358;
Mon, 25 Oct 1999 10:49:42 +0200
X-Authentication-Warning: Krabba.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 25 Oct 1999 10:49:41 +0200 (MET DST)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Mike Mascari <mascarim@yahoo.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
In-Reply-To: <19991024215456.11956.rocketmail@web2106.mail.yahoo.com>
Message-ID: <Pine.GSO.4.02A.9910251042430.8338-100000@Krabba.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 24 Oct 1999, Mike Mascari wrote:

Hmm, this is where I'm getting the oid's:

DATABASE -- pg_database
INDEX -- pg_class
RULE -- pg_rewrite
SEQUENCE -- pg_class
TABLE -- pg_class
TYPE -- pg_type
VIEW -- pg_class
COLUMN -- pg_attribute
AGGREGATE -- pg_aggregate
FUNCTION -- pg_proc
OPERATOR -- pg_operator
TRIGGER -- pg_trigger

So in the example you gave above, you could put a comment
on each of the two functions which compose the operator
and a command on the operator itself.

Very nice, BUT: In the old psql the assumption was that operator comments
are keyed on the underlying function(s?). Since a lot of operators seem to
have comments on them by default, one would have to change this somehow.
Try \do and see for yourself. The fix should be rather simple but I'm not
sure where those descriptions are generated actually.

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Mon Oct 25 21:22:46 1999
Received: from ayup.limey.net (IDENT:root@w042.z208176085.bos-ma.dsl.cnc.net
[208.176.85.42]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA94182
for <hackers@postgreSQL.org>; Mon, 25 Oct 1999 21:22:07 -0400 (EDT)
(envelope-from fiji@ayup.limey.net)
Received: (from fiji@localhost) by ayup.limey.net (8.9.3/8.9.3) id HAA31680;
Mon, 25 Oct 1999 07:39:02 -0400
Message-ID: <19991025073902.A31645@ayup.limey.net>
Date: Mon, 25 Oct 1999 07:39:02 -0400
From: Ben Bennett <fiji@ayup.limey.net>
To: Tim Holloway <mtsinc@southeast.net>, Massimo Dal Zotto <dz@cs.unitn.it>
Cc: PostgreSQL Hackers <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Logging - events supported
References: <199910242135.XAA01911@nikita.wizard.net>
<38139168.A394A269@southeast.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2
In-Reply-To: <38139168.A394A269@southeast.net>;
from Tim Holloway on Sun, Oct 24, 1999 at 07:08:24PM -0400

Not sure if I missed something, but it would be nice to be able to log
performance information such as "query 'XYZ' performed a table scan on
a 3,000,000 row table", "query 'XYZ' took 3000 seconds to complete",
"query 'XYZ' forced a sort of a 4,000,000 row table", etc. where the
thresholds could be set by the administrator. This would allow you to
periodically audit your server to make sure that there were sufficient
indices and that users/programmers were not writing really bad
queries.

Although I am not sure how difficult adding this to the backend is but
I would love to be able to hook a tool onto the logfile and see what
bad queries were being run while I ran an appliation against the
server. This is especially useful if my application allows dynamic
queries.

-ben

From bouncefilter Mon Oct 25 09:41:38 1999
Received: from netsol-nic-ex01.internic.net (netsol-nic-ex01.internic.net
[198.41.2.250]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA69800
for <pgsql-hackers@postgresql.org>;
Mon, 25 Oct 1999 09:41:06 -0400 (EDT)
(envelope-from thuann@netsol.com)
Received: by netsol-nic-ex01.internic.net with Internet Mail Service
(5.5.2650.10) id <VRKN1VH3>; Mon, 25 Oct 1999 09:38:38 -0400
Message-ID:
<8015EE53A058D311B02B00A0C99AB54704AFAF@netsol-nic-ex01.internic.net>
From: "Nguyen, Thuan X" <thuann@netsol.com>
To: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject:
Date: Mon, 25 Oct 1999 09:38:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
charset="iso-8859-1"

unsubscribe

From bouncefilter Mon Oct 25 11:03:39 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA81834
for <pgsql-hackers@postgreSQL.org>;
Mon, 25 Oct 1999 11:02:54 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA17752;
Mon, 25 Oct 1999 11:02:13 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Mike Mascari <mascarim@yahoo.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
In-reply-to: Your message of Mon, 25 Oct 1999 10:49:41 +0200 (MET DST)
<Pine.GSO.4.02A.9910251042430.8338-100000@Krabba.DoCS.UU.SE>
Date: Mon, 25 Oct 1999 11:02:13 -0400
Message-ID: <17750.940863733@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

On Sun, 24 Oct 1999, Mike Mascari wrote:

So in the example you gave above, you could put a comment
on each of the two functions which compose the operator
and a command on the operator itself.

Two functions? An operator only has one underlying function.
(Aggregates have as many as three though.)

Try \do and see for yourself. The fix should be rather simple but I'm not
sure where those descriptions are generated actually.

The default contents of pg_description come from the DESCR() macros in
include/catalog/*.h. It looks like only pg_proc and pg_type have any
useful info in them in the current state of the source. I'm guessing
that psql's \do actually looks for a description attached to the
underlying function, rather than one attached to the operator.

regards, tom lane

From bouncefilter Mon Oct 25 23:41:48 1999
Received: from mail_dns.lagoon.nc (mail.offratel.nc [209.58.55.28])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA12892
for <pgsql-hackers@postgresql.org>;
Mon, 25 Oct 1999 23:41:44 -0400 (EDT)
(envelope-from fillons@offratel.nc)
Received: from portable (unverified [202.22.159.68]) by mail_dns.lagoon.nc
(Rockliffe SMTPRA 3.4.3) with SMTP id <B0000341328@mail_dns.lagoon.nc>
for <pgsql-hackers@postgresql.org>; Tue, 26 Oct 1999 14:43:28 +1100
Message-ID: <000001bf1f64$6e89d2a0$c40a8280@boh.nc>
Reply-To: =?iso-8859-1?Q?St=E9phane_FILLON?= <fillons@offratel.nc>
From: =?iso-8859-1?Q?St=E9phane_FILLON?= <fillons@offratel.nc>
To: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Subject: RE: mv backend/port ../../
Date: Tue, 26 Oct 1999 04:11:08 +1100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2014.211

Hi Peter,

Could you explain me the use of these 3 functions:

strcasecmp
strtol
putenv (from nextstep/port.c)

Regards,
______________________________
St�phane FILLON
mailto:fillons@offratel.nc

From bouncefilter Mon Oct 25 15:26:42 1999
Received: from web2101.mail.yahoo.com (web2101.mail.yahoo.com [128.11.68.245])
by hub.org (8.9.3/8.9.3) with SMTP id PAA41394
for <pgsql-hackers@postgresql.org>;
Mon, 25 Oct 1999 15:26:11 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19991025193056.3953.rocketmail@web2101.mail.yahoo.com>
Received: from [206.246.185.100] by web2101.mail.yahoo.com;
Mon, 25 Oct 1999 12:30:56 PDT
Date: Mon, 25 Oct 1999 12:30:56 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

On Sun, 24 Oct 1999, Mike Mascari wrote:

So in the example you gave above, you could put a comment
on each of the two functions which compose the operator
and a command on the operator itself.

Two functions? An operator only has one underlying function.
(Aggregates have as many as three though.)

I'm sorry...it was late a night. I meant you could comment on left
and right hand sides of the operator (the types) as well as the function
and also on the operator itself. I also spelled comment as command)...

Try \do and see for yourself. The fix should be rather simple but I'm

not

sure where those descriptions are generated actually.

The default contents of pg_description come from the DESCR() macros in
include/catalog/*.h. It looks like only pg_proc and pg_type have any
useful info in them in the current state of the source. I'm guessing
that psql's \do actually looks for a description attached to the
underlying function, rather than one attached to the operator.

Perhaps this behavior should continue. But I thought it would be
nice to comment on the function of the operator without respect to the
function.

Mike Mascari
(mascarim@yahoo.com)

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

From bouncefilter Mon Oct 25 17:54:43 1999
Received: from genisys.gtv.ca (h-207-228-97-106.gen.cadvision.com
[207.228.97.106]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA64424
for <pgsql-hackers@postgreSQL.org>;
Mon, 25 Oct 1999 17:54:37 -0400 (EDT) (envelope-from aaron@gtv.ca)
Received: from stilborne (h-207-228-97-110.gen.cadvision.com [207.228.97.110])
by genisys.gtv.ca (8.9.3/8.8.7) with SMTP id PAA31669;
Mon, 25 Oct 1999 15:56:25 -0600
From: "Aaron J. Seigo" <aaron@gtv.ca>
To: Peter Eisentraut <peter_e@gmx.net>, Tim Holloway <mtsinc@southeast.net>
Subject: Re: [HACKERS] RFC: Industrial-strength logging
Date: Mon, 25 Oct 1999 15:50:59 -0600
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: pgsql-hackers@postgreSQL.org
References: <Pine.LNX.4.10.9910242208450.377-100000@peter-e.yi.org>
In-Reply-To: <Pine.LNX.4.10.9910242208450.377-100000@peter-e.yi.org>
MIME-Version: 1.0
Message-Id: <99102515535807.00882@stilborne>
Content-Transfer-Encoding: 8bit

hi...

What about
SET LOGLEVEL TO <something>;
SET LOGDETAIL TO <something>;
or the like. You could use pg_shadow.usesuper as a security stipulation.
Using something like a signal to do this is probably overkill, especially
since there are hardly any left, and it's also infinitely less intuitive
and flexible.

this would be done from psql? if so, here's a query i have: are there any plans
to seperate the admin functions out of psql and into another seperate tool?

i have a queasyness with general users having access to a tool that can
do admin takss (even if they supposedly don't have a superuser account).

it also seems much cleaner to have admin in one tool and data interaction in
another.

am i off track here?

--
Aaron J. Seigo
Sys Admin

From bouncefilter Mon Oct 25 19:46:45 1999
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 TAA81280
for <pgsql-hackers@postgreSQL.org>;
Mon, 25 Oct 1999 19:46:15 -0400 (EDT)
(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 <19991025234613.NIJX18396.mail.rdc1.md.home.com@home.com>;
Mon, 25 Oct 1999 16:46:13 -0700
Message-ID: <3814E994.24E8AC14@home.com>
Date: Mon, 25 Oct 1999 19:36:52 -0400
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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Mike Mascari <mascarim@yahoo.com>, peter_e@gmx.net,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
References: <14803.940829793@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Mike Mascari <mascarim@yahoo.com> writes:

Does this field exist for all previous postgres releases (specifically,
6.2,6.3, and 6.4) ??

And of course, it appears also in 6.4.x, so I assume that it was added
between the 6.2 and 6.3 releases. Is that going to be a problem?

For Peter's purposes, it's unnecessary to worry about anything older
than 6.4, since he's depending on an up-to-date libpq and current libpq
won't talk to anything older than 6.4.

Byron might still care about 6.2 ... I dunno whether ODBC currently
really works with 6.2 or not, or whether it needs to keep doing so.

regards, tom lane

It still really works with 6.2! But whether it needs to, is another
question!

I'm not sure if anyone cares if it works with 6.2 (even 6.3 for that
matter) or not.

Byron

From bouncefilter Mon Oct 25 20:08:45 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA84175
for <pgsql-hackers@postgresql.org>;
Mon, 25 Oct 1999 20:08:16 -0400 (EDT)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id UAA18125
for <pgsql-hackers@postgresql.org>;
Mon, 25 Oct 1999 20:08:13 -0400 (EDT)
Message-ID: <3814EF4B.70023082@southeast.net>
Date: Mon, 25 Oct 1999 20:01:15 -0400
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Logging - pg_options format change?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Would it be objectionable if I altered the format of the pg_options file slightly?
I feel the need to handle a somewhat more complex syntax for the logging subsystem.

What I'm proposing is to wrap the existing stuff in a backwards-compatible manner,
but extend it. Like so:

---------------------------------------------------
# postgresql options

debugging {
fooparam+
barswitch
dumplevel = 11
}

logging {
# details to follow
}
---------------------------------------------------

Also, is YACC sufficently thread-safe that if a SIGHUP starts
parsing options it won't collide with another task's in-progress
parsing of, say a SELECT statement?

Thanks,

Tim Holloway

From bouncefilter Mon Oct 25 21:01:51 1999
Received: from ext16.sra.co.jp (IDENT:root@ykh28DS02.kng.mesh.ad.jp
[133.205.214.2]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA90603;
Mon, 25 Oct 1999 21:00:54 -0400 (EDT)
(envelope-from t-ishii@ext04.sra.co.jp)
Received: from ext04.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id JAA07248;
Tue, 26 Oct 1999 09:59:49 +0900
Message-Id: <199910260059.JAA07248@ext16.sra.co.jp>
To: Vadim Mikheev <vadim@krs.ru>
cc: Lincoln Yeoh <lylyeoh@mecomb.com>, pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Postgres INSERTs much slower than MySQL?
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Fri, 22 Oct 1999 13:52:40 +0800.
<380FFBA8.82447656@krs.ru>
Date: Tue, 26 Oct 1999 09:59:49 +0900
Sender: t-ishii@ext04.sra.co.jp

WAL is Write Ahead Log, transaction logging.
This will reduce # of fsyncs (among other things) Postgres has
to perform now.
Test above took near 38 min without -F flag and 24 min
with -F (no fsync at all).
With WAL the same test without -F will be near as fast as with
-F now.

This sounds impressive. So I did some testings with my pgbench to see
how WAL improves the performance without -F using current.

100000 records insertation + vacuum took 1:02 with -F (4:10 without -F)

TPC-B like transactions(mix of insert/update/select) per second:
21 (with -F)
3 (without -F)

I couldn't see any improvement against 6.5.2 so far. Maybe some part
of WAL is not yet committed to current?
---
Tatsuo Ishii

From bouncefilter Mon Oct 25 21:01:45 1999
Received: from thelab.hub.org (nat198.58.mpoweredpc.net [142.177.198.58])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA90658
for <pgsql-hackers@postgreSQL.org>;
Mon, 25 Oct 1999 21:01:37 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA13521;
Mon, 25 Oct 1999 22:01:06 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 25 Oct 1999 22:01:05 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: "Aaron J. Seigo" <aaron@gtv.ca>
cc: Peter Eisentraut <peter_e@gmx.net>, Tim Holloway <mtsinc@southeast.net>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RFC: Industrial-strength logging
In-Reply-To: <99102515535807.00882@stilborne>
Message-ID: <Pine.BSF.4.10.9910252159380.404-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 25 Oct 1999, Aaron J. Seigo wrote:

hi...

What about
SET LOGLEVEL TO <something>;
SET LOGDETAIL TO <something>;
or the like. You could use pg_shadow.usesuper as a security stipulation.
Using something like a signal to do this is probably overkill, especially
since there are hardly any left, and it's also infinitely less intuitive
and flexible.

this would be done from psql? if so, here's a query i have: are there any plans
to seperate the admin functions out of psql and into another seperate tool?

i have a queasyness with general users having access to a tool that can
do admin takss (even if they supposedly don't have a superuser account).

There is no such thing, actually...all "admin commands" are seperate SQL
queries...psql is merely one of many interfaces that allows one to talk to
and send queries to the backend...what the backend then does with the
query is where the security lies...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Oct 25 22:00:47 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA99400;
Mon, 25 Oct 1999 22:00:40 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id KAA28705;
Tue, 26 Oct 1999 10:00:24 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <38150B38.4A3CABF7@krs.ru>
Date: Tue, 26 Oct 1999 10:00:24 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: t-ishii@sra.co.jp
CC: Lincoln Yeoh <lylyeoh@mecomb.com>, pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Postgres INSERTs much slower than MySQL?
References: <199910260059.JAA07248@ext16.sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tatsuo Ishii wrote:

With WAL the same test without -F will be near as fast as with
-F now.

This sounds impressive. So I did some testings with my pgbench to see
how WAL improves the performance without -F using current.

100000 records insertation + vacuum took 1:02 with -F (4:10 without -F)

TPC-B like transactions(mix of insert/update/select) per second:
21 (with -F)
3 (without -F)

I couldn't see any improvement against 6.5.2 so far. Maybe some part
of WAL is not yet committed to current?

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...is not implemented.

Vadim

From bouncefilter Mon Oct 25 23:57:48 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA15028
for <pgsql-hackers@postgreSQL.org>;
Mon, 25 Oct 1999 23:57:24 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id XAA17482;
Mon, 25 Oct 1999 23:55:45 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910260355.XAA17482@candle.pha.pa.us>
Subject: Re: [HACKERS] Path-length follies
In-Reply-To: <2329.940717714@sss.pgh.pa.us> from Tom Lane at "Oct 23,
1999 06:28:34 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 25 Oct 1999 23:55:45 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Does anyone have a better idea? Is it worth trying to extract a
system limit on pathlength during configure, rather than leaving
MAXPGPATH as a manual configuration item --- and if so, exactly how
should configure go about it?

I don't like the 128 or 256 numbers, but isn't there a predefined place
for this value in standard system headers?

There are too many of 'em, actually --- I had never realized this
before, but there are three or four *different* "standard" symbols that
all purport to be max pathlength. On my box they actually have three
different values, which doesn't leave a warm feeling in the stomach.

Couldn't we pick one of the standard ones for use in setting a value for
our own define, or at least test one of the standard ones against ours
to see that it is either equal or greater than the 1024 we chose?

-- 
  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 Oct 25 23:59:48 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA15681
for <pgsql-hackers@postgreSQL.org>;
Mon, 25 Oct 1999 23:59:20 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id XAA17626;
Mon, 25 Oct 1999 23:58:58 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910260358.XAA17626@candle.pha.pa.us>
Subject: Re: System indexes are never unique indexes( was RE: [HACKERS]
mdnblocks is an amazing time sink in huge relations)
In-Reply-To: <NDBBIJLOILGIKBGDINDFMEIBCAAA.Inoue@tpf.co.jp> from Hiroshi Inoue
at "Oct 24, 1999 08:48:38 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 25 Oct 1999 23:58:58 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org, Tom Lane <tgl@sss.pgh.pa.us>,
t-ishii@sra.co.jp
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

As I was afraid,2 tables of a same name could be made.
After a short investigating,I found that system indexes are
never unique indexes.
Why ?
Without duplicate index check,it's very difficult to prevent
objects from having same name.

They certainly should be unique.

-- 
  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 Tue Oct 26 00:16:48 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA20926
for <hackers@postgreSQL.org>; Tue, 26 Oct 1999 00:16:33 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id AAA18352;
Tue, 26 Oct 1999 00:16:19 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910260416.AAA18352@candle.pha.pa.us>
Subject: Re: [HACKERS] mv backend/port ../../
In-Reply-To: <Pine.LNX.4.10.9910241406300.377-100000@peter-e.yi.org> from
Peter
Eisentraut at "Oct 24, 1999 02:14:53 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 26 Oct 1999 00:16:19 -0400 (EDT)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I use the following functions in psql which are found in backend/port.
That implies that there is at least one system that doesn't have these so
it would be a good idea if they were available to the entire code tree.
Could someone move them to a better place in the tree or would you like me
to do it?

strcasecmp
strtol
putenv (from nextstep/port.c)

We have them because only a few platforms don't have them. They are
normally part of the OS library.

It is counter productive to move them out of port. We want to reduce
what is in there, not move it into the main tree.

In addition, as I already mentioned a while back, I would really like to
use

snprintf

I think so, but it only handles strings. You have to interface that to
the pgsql character types.

-- 
  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 Tue Oct 26 00:24:48 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA22526
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 00:23:58 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id NAA04208; Tue, 26 Oct 1999 13:23:15 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: System indexes are never unique indexes( was RE: [HACKERS]
mdnblocksis an amazing time sink in huge relations)
Date: Tue, 26 Oct 1999 13:27:22 +0900
Message-ID: <000901bf1f6a$65e40520$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <199910260358.XAA17626@candle.pha.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

As I was afraid,2 tables of a same name could be made.
After a short investigating,I found that system indexes are
never unique indexes.
Why ?
Without duplicate index check,it's very difficult to prevent
objects from having same name.

They certainly should be unique.

All should be unique ?
I don't know system indexes well.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Oct 26 00:39:48 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA25817
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 00:39:03 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id AAA19091;
Tue, 26 Oct 1999 00:34:45 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910260434.AAA19091@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
In-Reply-To: <Pine.LNX.4.10.9910242042040.377-100000@peter-e.yi.org> from
Peter
Eisentraut at "Oct 24, 1999 08:57:51 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 26 Oct 1999 00:34:45 -0400 (EDT)
CC: Mike Mascari <mascarim@yahoo.com>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In related news I'd like to point out that psql's \dd command now supports
aggregates, functions, operators, types, relations (tables, views,
indices, sequences), rules, and triggers. In addition all the other \d?
commands (\da, \df, \dT, \do, \dtvsiS), as well as \l, have comments
display switchable. Attribute comments can be seen in \d in a similar
fashion. You can also give a comment on \lo_import which can then be seen
in \lo_list (=\dl). Seems like all the bases are covered.

OK, I think we need help on this. I have added documentation in
psqlHelp.c and comment.sgml. You are mentioning some new psql flags
that I don't know we had. Can you send info on that. psql.c and
psql-ref.sgml are two areas that need additions based on what you said.

Now we just have to stick a whole bunch of comments on all system stuff.
Where would be a good place to do this? Where are all the comments on the
built-in operators generated?

OK, right now, comments are in src/include/catalog as DESC entries.
These are pulled out by OID during creation of the *.bki files, and
initdb does a COPY to load the description table.

One limitation now is that we can only comment objects that have a fixed
oid in the system tables because we define the oid at compile time
coming from the system table.

One idea I had in the past was to store the object type and object name
instead in a file during compile, and run some UPDATE during initdb that
looked up the oid of the object type and name, and stuffed that
initdb-supplied oid into the pg_description table. I think that is the
only way you are going to be able to do this properly.

Seems your COMMENT command already has this done. You could just dump a
file containing COMMENT lines as part of *.bki compile process, and have
inintdb run the COMMENT file. That is the best way, I think.

-- 
  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 Tue Oct 26 00:50:48 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA27638
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 00:50:04 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id AAA20043;
Tue, 26 Oct 1999 00:49:48 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910260449.AAA20043@candle.pha.pa.us>
Subject: Re: [HACKERS] Catalog version numbering added (committers READ THIS)
In-Reply-To: <4900.940797866@sss.pgh.pa.us> from Tom Lane at "Oct 24,
1999 04:44:26 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 26 Oct 1999 00:49:48 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Good idea.

I have added a new feature that I suggested a few weeks ago (and didn't
get a lot of feedback about --- if you didn't like the idea, you shoulda
complained then ;-)). To wit, there is now an internal version number
that can be bumped anytime anyone makes an initdb-forcing change.

If we are faithful about changing this number when necessary, then
developers will not get burnt by failing to notice "you need to initdb"
messages in the pghackers list. I know some people have wasted hours
that way in the past.

The new number lives in src/include/catalog/catversion.h, and I think
I will just copy the comments in that file:

* catversion.h
* "Catalog version number" for Postgres.
*
* The catalog version number is used to flag incompatible changes in
* the Postgres system catalogs. Whenever anyone changes the format of
* a system catalog relation, or adds, deletes, or modifies standard
* catalog entries in such a way that an updated backend wouldn't work
* with an old database (or vice versa), the catalog version number
* should be changed. The version number stored in pg_control by initdb
* is checked against the version number compiled into the backend at
* startup time, so that a backend can refuse to run in an incompatible
* database.
*
* The point of this feature is to provide a finer grain of compatibility
* checking than is possible from looking at the major version number
* stored in PG_VERSION. It shouldn't matter to end users, but during
* development cycles we usually make quite a few incompatible changes
* to the contents of the system catalogs, and we don't want to bump the
* major version number for each one. What we can do instead is bump
* this internal version number. This should save some grief for
* developers who might otherwise waste time tracking down "bugs" that
* are really just code-vs-database incompatibilities.
*
* The rule for developers is: if you commit a change that requires
* an initdb, you should update the catalog version number (as well as
* notifying the pghackers mailing list, which has been the informal
* practice for a long time).
*
* The catalog version number is placed here since modifying files in
* include/catalog is the most common kind of initdb-forcing change.
* But it could be used to protect any kind of incompatible change in
* database contents or layout, such as altering tuple headers.

Naturally, you need to initdb after retrieving this update, but the
system will now tell you so if you forget! For example:

FATAL 2: database was initialized with CATALOG_VERSION_NO 0,
but the backend was compiled with CATALOG_VERSION_NO 199910241.
looks like you need to initdb.

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

From bouncefilter Tue Oct 26 01:03:51 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA29471
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 01:03:08 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id AAA20092;
Tue, 26 Oct 1999 00:52:23 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910260452.AAA20092@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
In-Reply-To: <19991024215456.11956.rocketmail@web2106.mail.yahoo.com> from
Mike
Mascari at "Oct 24, 1999 02:54:56 pm"
To: Mike Mascari <mascarim@yahoo.com>
Date: Tue, 26 Oct 1999 00:52:23 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org,
byron.nikolaidis@home.com
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hmm, this is where I'm getting the oid's:

DATABASE -- pg_database
INDEX -- pg_class
RULE -- pg_rewrite
SEQUENCE -- pg_class
TABLE -- pg_class
TYPE -- pg_type
VIEW -- pg_class
COLUMN -- pg_attribute
AGGREGATE -- pg_aggregate
FUNCTION -- pg_proc
OPERATOR -- pg_operator
TRIGGER -- pg_trigger

So in the example you gave above, you could put a comment
on each of the two functions which compose the operator
and a command on the operator itself.

I still need to write the SGML and change pg_dump to

Please update the sgml and psqlHelp.c files I have already modified for
you. I thought you didn't want to do it, so I did it.

generate COMMENT ON statements, and also regression tests,
but the functionality should be complete. Just glancing
over the Win32 ODBC driver, it appears that SQLTables() and
SQLColumns() is not currently fetching the associated
description from pg_description for the REMARKS parameter
to the call. Perhaps this could be changed?

Hmm. Never heard of that.

-- 
  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 Tue Oct 26 01:03:49 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA29458
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 01:03:01 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id BAA20899;
Tue, 26 Oct 1999 01:00:39 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910260500.BAA20899@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
In-Reply-To: <19991025051815.3737.rocketmail@web2104.mail.yahoo.com> from Mike
Mascari at "Oct 24, 1999 10:18:15 pm"
To: Mike Mascari <mascarim@yahoo.com>
Date: Tue, 26 Oct 1999 01:00:39 -0400 (EDT)
CC: Byron Nikolaidis <byron.nikolaidis@home.com>, peter_e@gmx.net,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

--- Byron Nikolaidis <byron.nikolaidis@home.com> wrote:
...

I still need to write the SGML and change pg_dump to
generate COMMENT ON statements, and also regression tests,
but the functionality should be complete. Just glancing
over the Win32 ODBC driver, it appears that SQLTables() and
SQLColumns() is not currently fetching the associated
description from pg_description for the REMARKS parameter
to the call. Perhaps this could be changed?

It wouldn't be hard to add the pg_description to the remarks.
Does this field exist for all previous postgres releases (specifically,
6.2,6.3, and 6.4) ??

HISTORY file says added in release 6.3.

-- 
  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 Tue Oct 26 01:04:55 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA29611
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 01:04:39 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id BAA21027;
Tue, 26 Oct 1999 01:04:20 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910260504.BAA21027@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
In-Reply-To: <17750.940863733@sss.pgh.pa.us> from Tom Lane at "Oct 25,
1999 11:02:13 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 26 Oct 1999 01:04:20 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>, Mike Mascari <mascarim@yahoo.com>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

On Sun, 24 Oct 1999, Mike Mascari wrote:

So in the example you gave above, you could put a comment
on each of the two functions which compose the operator
and a command on the operator itself.

Two functions? An operator only has one underlying function.
(Aggregates have as many as three though.)

Try \do and see for yourself. The fix should be rather simple but I'm not
sure where those descriptions are generated actually.

The default contents of pg_description come from the DESCR() macros in
include/catalog/*.h. It looks like only pg_proc and pg_type have any
useful info in them in the current state of the source. I'm guessing
that psql's \do actually looks for a description attached to the
underlying function, rather than one attached to the operator.

I can only get oids that are fixed in the include files. Not sure if it
looks at the function behind the operator. I just don't remember.

-- 
  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 Tue Oct 26 01:14:49 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA31306
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 01:13:46 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id BAA21390;
Tue, 26 Oct 1999 01:10:09 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910260510.BAA21390@candle.pha.pa.us>
Subject: Re: System indexes are never unique indexes( was RE: [HACKERS]
mdnblocksis an amazing time sink in huge relations)
In-Reply-To: <000901bf1f6a$65e40520$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Oct 26, 1999 01:27:22 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 26 Oct 1999 01:10:09 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

As I was afraid,2 tables of a same name could be made.
After a short investigating,I found that system indexes are
never unique indexes.
Why ?
Without duplicate index check,it's very difficult to prevent
objects from having same name.

They certainly should be unique.

All should be unique ?
I don't know system indexes well.

Not sure. I don't remember which ones. I can take a look when I add
more indexes for 7.0.

-- 
  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 Tue Oct 26 01:31:49 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA34992
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 01:30:54 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id BAA21896;
Tue, 26 Oct 1999 01:25:43 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910260525.BAA21896@candle.pha.pa.us>
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
In-Reply-To: <2395.940722749@sss.pgh.pa.us> from Tom Lane at "Oct 23,
1999 07:52:29 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 26 Oct 1999 01:25:43 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

This is a followup to a message I wrote in June about reworking the fmgr
interface. I've had a couple of good ideas (I think ;-)) since then,
but there are some parts of the proposal that still need work before
implementation can begin.

I could particularly use some feedback from Jan and anyone else who's
worked with function-call handlers: does this design eliminate the
kluges that you've had to use in the past? If not, what else is needed?

Sounds good. My only question is whether people need backward
compatibility, and whether we can remove the compatiblity part of the
interface and small overhead after 7.1 or later?

-- 
  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 Tue Oct 26 01:31:54 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA35016;
Tue, 26 Oct 1999 01:31:07 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id BAA21909;
Tue, 26 Oct 1999 01:27:54 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910260527.BAA21909@candle.pha.pa.us>
Subject: Re: [ADMIN] Re: [HACKERS] RFC: Industrial-strength logging
(longmessage)
In-Reply-To: <38125BE8.15A3C130@southeast.net> from Tim Holloway at "Oct 23,
1999 09:07:52 pm"
To: Tim Holloway <mtsinc@southeast.net>
Date: Tue, 26 Oct 1999 01:27:54 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, "Aaron J. Seigo" <aaron@gtv.ca>,
Tom Lane <tgl@sss.pgh.pa.us>, Tim Holloway <mtsinc@leading.net>,
pgsql-admin@postgreSQL.org, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I think we have a consensus. Destroy and recreate logging
data structures/tasks on receipt of
suitable event.

For simple things like log levels, though, I'd still like
feedback on
desirablility and feasibility of altering basic logging
options though
(authorized!) frontends. As a user, I get nervous when I
have to thread
my way past possibly-fragile unrelated items in a config
file when I'm trying
to do a panic diagnosis. As an administrator, I get even
MORE nervous if one
of the less careful people I know were to be entrusted with
that task.

One more item I have not heard is that you can create virtual table that
look like tables but return data about users, queries on SELECT.

Informix does this. Allows you to get info, without the need for
storage. Not good for every case, but an interesting idea sometimes.

-- 
  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 Tue Oct 26 02:17:50 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA40739
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 02:17:19 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id CAA22094;
Tue, 26 Oct 1999 02:16:12 -0400 (EDT)
To: Tim Holloway <mtsinc@southeast.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Logging - pg_options format change?
In-reply-to: Your message of Mon, 25 Oct 1999 20:01:15 -0400
<3814EF4B.70023082@southeast.net>
Date: Tue, 26 Oct 1999 02:16:12 -0400
Message-ID: <22092.940918572@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tim Holloway <mtsinc@southeast.net> writes:

Would it be objectionable if I altered the format of the pg_options
file slightly? I feel the need to handle a somewhat more complex
syntax for the logging subsystem.

While I'm not particularly wedded to the pg_options format, I wonder
whether it wouldn't be a better idea to create a separate file for
the logging control data. If I'm reading your proposal correctly,
the backend would no longer parse existing pg_options files --- and
that's certain to make dbadmins unhappy, even if the fix is easy.
Upgrades are always stressful enough, even without added complications
like forced changes to config files.

You could probably tweak the syntax so that an existing pg_options
file is still valid, but that might be a bit too klugy. What's
wrong with having two separate files? We can assume that this isn't
a performance-critical path, I think.

Also, is YACC sufficently thread-safe that if a SIGHUP starts
parsing options it won't collide with another task's in-progress
parsing of, say a SELECT statement?

Don't even think of going there. Even if yacc/bison code itself can be
made reentrant (which I doubt; it's full of static variables) you'd also
have to assume that large chunks of libc are reentrant --- malloc() and
stdio in particular --- and I know for a fact that you *cannot* assume
that. There might be some platforms where it will work, but many others
won't.

Basically, the only thing that's really safe for a signal handler to do
is set an int flag to TRUE for a test in the main control paths to
notice at some later (hopefully not too much later) time. The
QueryCancel flag in the existing Postgres code is an example.

For the purposes of logging, I see no reason why it wouldn't be
good enough to reread the config file at the start of the next
query-execution cycle. There's no need to take the risks of doing
anything unportable.

regards, tom lane

From bouncefilter Tue Oct 26 03:18:50 1999
Received: from hu.tm.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA51596
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 03:18:22 -0400 (EDT) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 8DF7E3EFC; Tue, 26 Oct 1999 10:27:55 +0300 (EEST)
Sender: hannu@hu.tm.ee
Message-ID: <381557FB.B44A2B6E@tm.ee>
Date: Tue, 26 Oct 1999 07:27:55 +0000
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
Cc: Tim Holloway <mtsinc@southeast.net>, The Hermit Hacker <scrappy@hub.org>,
"Aaron J. Seigo" <aaron@gtv.ca>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [ADMIN] Re: [HACKERS] RFC: Industrial-strength logging
(longmessage)
References: <199910260527.BAA21909@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

One more item I have not heard is that you can create virtual table that
look like tables but return data about users, queries on SELECT.

Informix does this. Allows you to get info, without the need for
storage. Not good for every case, but an interesting idea sometimes.

This should come naturally after the function interface is updated
to enable it to return cursors.

A very desirable feature, but I'm not sure anyone is actually working on it.

-------------------
Hannu

From bouncefilter Tue Oct 26 04:15:51 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id EAA60048
for <pgsql-hackers@postgresql.org>;
Tue, 26 Oct 1999 04:15:46 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgresql.org
id m11g1hq-0003kLC; Tue, 26 Oct 99 10:11 MET DST
Message-Id: <m11g1hq-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: System indexes are never unique indexes( was RE: [HACKERS]
mdnblocksis
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Tue, 26 Oct 1999 10:11:46 +0200 (MET DST)
Cc: Inoue@tpf.co.jp, pgsql-hackers@postgresql.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199910260510.BAA21390@candle.pha.pa.us> from "Bruce Momjian" at
Oct 26, 99 01:10:09 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

[Charset iso-8859-1 unsupported, filtering to ASCII...]

As I was afraid,2 tables of a same name could be made.
After a short investigating,I found that system indexes are
never unique indexes.
Why ?
Without duplicate index check,it's very difficult to prevent
objects from having same name.

They certainly should be unique.

All should be unique ?
I don't know system indexes well.

Not sure. I don't remember which ones. I can take a look when I add
more indexes for 7.0.

Don't remember if really or what, but wasn't there some
problem with cached system relations, unique indices and
concurrency?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Oct 26 05:11:54 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id FAA68529
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 05:11:37 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11g2Yt-0003kLC; Tue, 26 Oct 99 11:06 MET DST
Message-Id: <m11g2Yt-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Tue, 26 Oct 1999 11:06:35 +0200 (MET DST)
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199910260525.BAA21896@candle.pha.pa.us> from "Bruce Momjian" at
Oct 26, 99 01:25:43 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

This is a followup to a message I wrote in June about reworking the fmgr
interface. I've had a couple of good ideas (I think ;-)) since then,
but there are some parts of the proposal that still need work before
implementation can begin.

I could particularly use some feedback from Jan and anyone else who's
worked with function-call handlers: does this design eliminate the
kluges that you've had to use in the past? If not, what else is needed?

Sounds good. My only question is whether people need backward
compatibility, and whether we can remove the compatiblity part of the
interface and small overhead after 7.1 or later?

Backward compatibility is a common source of problems, and I
don't like it generally. In the case of the fmgr it is quite
a little difficult, and I thought about it too already. I
like the current interface for it's simpleness from the user
function developers point of view. And converting ALL
internal plus most of the contrib directories ones to
something new is really a huge project.

All function calls through the fmgr use the FmgrInfo
structure, but there are alot of calls to internal functions
like textout() etc. too. Changing their interface would IMHO
introduce many problems. And there are only a few internal
functions where a new fmgr interface really is required due
to incomplete NULL handling or the like.

Therefore I would prefer an interface extension, that doesn't
require changes to existing functions. What about adding a
proifversion to pg_proc, telling the fmgr which call
interface the function uses? This is then held in the
FmgrInfo struct too so the fmgr can call a function using the
old and new interface.

First fmgr_info() is extended to put the interface version
into the FmgrInfo too. Then fmgr_faddr() is renamed to
fmgr_faddr_v1() and it has to check that only functions using
the old interface are called through it (there aren't that
many calls to it as you might think). After that you have
all the time in the world to implement another interface and
add a switch into fmgr() and sisters handling the different
versions.

My thoughts for the new interface:

o Each function argument must have it's separate NULL flag.

o The functions result must have another NULL flag too.

o Argument names and default values for omitted ones aren't
IMHO something to go into the interface itself. The
function is allways called with all arguments positional,
the parser must provide this list.

o The new interface must at least be designed for a later
implementation of tuple set returns. I think this must be
implemented as a temp table, collecting all return tuples
since for a procedural language it might be impossible to
implement a real RETURN AND RESUME (like it is already
for PL/Tcl and it would be for PL/Perl). Therefore
another STRUCT kind of relation must be added too,
providing the tupdesc for the returned set. This temp
table, filled by calling the function at the first time a
tuple is needed and then it is simply another RTE.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Oct 26 05:58:52 1999
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net
[194.217.242.38]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA75226
for <hackers@postgresql.org>; Tue, 26 Oct 1999 05:58:09 -0400 (EDT)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
id 11g3Mm-0001bO-0A
for hackers@postgreSQL.org; Tue, 26 Oct 1999 09:58:08 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id KAA18541; Tue, 26 Oct 1999 10:57:55 +0100 (BST)
Message-Id: <199910260957.KAA18541@mtcc.demon.co.uk>
Date: Tue, 26 Oct 1999 10:57:55 +0100 (BST)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Current source from CVS won't compile.
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 2gO0StUVEBqcLaQYyvskRA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

Hi All,

A make on a "cvs update" from this morning fails with the following
error message.

make -C commands all
make[2]: Entering directory `/usr/local/pgsql/src/backend/commands'
make[2]: *** No rule to make target `../parse.h', needed by `comment.o'. Stop.
make[2]: Leaving directory `/usr/local/pgsql/src/backend/commands'
make[1]+ Done nohup postmaster -i > pserver.log 2>&1 & $ cat pserver.log IpcMemoryCreate: shmget failed (Invalid argument) key=5432001, size=1073152, permission=600 FATAL 1: ShmemCreate: cannot create region $: *** [commands.dir] Error 2
make[1]+ Done nohup postmaster -i > pserver.log 2>&1 & $ cat pserver.log IpcMemoryCreate: shmget failed (Invalid argument) key=5432001, size=1073152, permission=600 FATAL 1: ShmemCreate: cannot create region $: Leaving directory `/usr/local/pgsql/src/backend'
make: *** [install] Error 2

This looks to have been broken by the COMMENT patch.

Keith

From bouncefilter Tue Oct 26 06:22:52 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id GAA78555
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 06:22:49 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11g3hE-0003kzC; Tue, 26 Oct 99 12:19 MET DST
Message-Id: <m11g3hE-0003kzC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Tue, 26 Oct 1999 12:19:16 +0200 (MET DST)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <2395.940722749@sss.pgh.pa.us> from "Tom Lane" at Oct 23,
99 07:52:29 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

System table updates
--------------------

In the initial phase, pg_language type 11 ("builtin") will be renamed
to "old_builtin", and a new language type named "builtin" will be
created with a new OID. Then pg_proc entries will be changed from
language code 11 to the new code piecemeal, as the associated routines
are rewritten. (This will imply several rounds of forced initdbs as
the contents of pg_proc change. It would be a good idea to add a
"catalog contents version number" to the database version info checked
at startup before we begin this process.)

The existing pg_language entry for "C" functions will continue to
describe user functions coded in the old style, and we will need to add
a new language name for user functions coded in the new style. (Any
suggestions for what the new name should be?) We should deprecate
old-style functions because of their portability problems, but the
support for them will only be one small function handler routine,
so we can leave them in place for as long as necessary.

The expected calling convention for PL call handlers will need to change
all-at-once, but fortunately there are not very many of them to fix.

This approach nearly matches all my thoughts about the
redesign of the fmgr. In the system table section I miss
named arguments.

I think we need a new system table

pg_proargs (
Oid pargprooid,
int2 pargno,
name pargname,
bool pargdflnull,
text pargdefault
);

plus another flag in pg_proc that tells if this function
prototype information is available.

The parser then has to handle function calls like

... myfunc(userid = 123, username = 'hugo');

and build a complete function argument list that has all the
arguments in the correct order and defaults for omitted
arguments filled in as const nodes. This new prototype
information than must also be used in the PL handlers to
choose the given names for arguments.

In addition, we could add an argument type at this time
(INPUT, OUTPUT and INOUT) but only support INPUT ones for now
from the SQL level. PL functions calling other functions
could eventually use these argument types in the future.

Also I miss the interface for tuple set returns. I know that
this requires much more in other sections than only the fmgr,
but we need to cover it now or we'll not be able to do it
without another change to the fmgr interface at the time we
want to support real stored procedures. As said in another
mail, I think it must be done via some temp table since most
interpreter languages will not be able to do RETURN AND
RESUME in any other way - not even PL/pgSQL will be easy and
would need a total internal redesign of the bytecode
interpreter since it otherwise needs to recover the internal
call stack maybe across recursive calls.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Oct 26 07:13:54 1999
Received: from web2104.mail.yahoo.com (web2104.mail.yahoo.com [128.11.68.248])
by hub.org (8.9.3/8.9.3) with SMTP id HAA84919
for <pgsql-hackers@postgresql.org>;
Tue, 26 Oct 1999 07:13:43 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19991026111856.13977.rocketmail@web2104.mail.yahoo.com>
Received: from [24.26.131.45] by web2104.mail.yahoo.com;
Tue, 26 Oct 1999 04:18:56 PDT
Date: Tue, 26 Oct 1999 04:18:56 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] Current source from CVS won't compile.
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Cc: pgsql-hackers@postgresql.org, pgsql-patches@postgresql.org,
maillist@candle.pha.pa.us
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-1681692777-940936736=:12865"

--0-1681692777-940936736=:12865
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Yes.

This is my fault. Sorry. Attached is a patch which fixes the problem.
I missed adding the rule to make parse.h to the Makefile for
the ../backend/commands. It also allows for comments to be dropped
using IS NULL as well as IS '';

Again, sorry.

Mike Mascari
(mascarim@yahoo.com)

--- Keith Parks <emkxp01@mtcc.demon.co.uk> wrote:

Hi All,

A make on a "cvs update" from this morning fails with the following
error message.

make -C commands all
make[2]: Entering directory `/usr/local/pgsql/src/backend/commands'
make[2]: *** No rule to make target `../parse.h', needed by `comment.o'.
Stop.
make[2]: Leaving directory `/usr/local/pgsql/src/backend/commands'
make[1]: *** [commands.dir] Error 2
make[1]: Leaving directory `/usr/local/pgsql/src/backend'
make: *** [install] Error 2

This looks to have been broken by the COMMENT patch.

Keith

************

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
--0-1681692777-940936736=:12865
Content-Type: application/x-unknown; name=patchfile
Content-Transfer-Encoding: base64
Content-Description: patchfile
Content-Disposition: attachment; filename=patchfile

ZGlmZiAtQyAyIC1QIC0tZXhjbHVkZS1mcm9tPWlnbm9yZSAtciBwZ3NxbC9z
cmMvYmFja2VuZC9jb21tYW5kcy9NYWtlZmlsZSBwZ3NxbC1tb2Qvc3JjL2Jh
Y2tlbmQvY29tbWFuZHMvTWFrZWZpbGUKKioqIHBnc3FsL3NyYy9iYWNrZW5k
L2NvbW1hbmRzL01ha2VmaWxlCVR1ZSBPY3QgMjYgMDM6MDA6MDkgMTk5OQot
LS0gcGdzcWwtbW9kL3NyYy9iYWNrZW5kL2NvbW1hbmRzL01ha2VmaWxlCVR1
ZSBPY3QgMjYgMDU6NTQ6MDMgMTk5OQoqKioqKioqKioqKioqKioKKioqIDM0
LDM3ICoqKioKLS0tIDM0LDQwIC0tLS0KICBjb21tZW50Lm86IC4uL3BhcnNl
LmgKICAKKyAuLi9wYXJzZS5oOgorIAkkKE1BS0UpIC1DIC4uIHBhcnNlLmgK
KyAKICBkZXBlbmQgZGVwOgogIAkkKENDKSAtTU0gJChDRkxBR1MpICouYyA+
ZGVwZW5kCmRpZmYgLUMgMiAtUCAtLWV4Y2x1ZGUtZnJvbT1pZ25vcmUgLXIg
cGdzcWwvc3JjL2JhY2tlbmQvcGFyc2VyL2dyYW0ueSBwZ3NxbC1tb2Qvc3Jj
L2JhY2tlbmQvcGFyc2VyL2dyYW0ueQoqKiogcGdzcWwvc3JjL2JhY2tlbmQv
cGFyc2VyL2dyYW0ueQlUdWUgT2N0IDI2IDAzOjAwOjE2IDE5OTkKLS0tIHBn
c3FsLW1vZC9zcmMvYmFja2VuZC9wYXJzZXIvZ3JhbS55CVR1ZSBPY3QgMjYg
MDU6NTU6MDkgMTk5OQoqKioqKioqKioqKioqKioKKioqIDI0MywyNDcgKioq
KgogIAogICV0eXBlIDxpdmFsPglJY29uc3QKISAldHlwZSA8c3RyPgkJU2Nv
bnN0CiAgJXR5cGUgPHN0cj4JCVVzZXJJZCwgdmFyX3ZhbHVlLCB6b25lX3Zh
bHVlCiAgJXR5cGUgPHN0cj4JCUNvbElkLCBDb2xMYWJlbAotLS0gMjQzLDI0
NyAtLS0tCiAgCiAgJXR5cGUgPGl2YWw+CUljb25zdAohICV0eXBlIDxzdHI+
CQlTY29uc3QsIGNvbW1lbnRfdGV4dAogICV0eXBlIDxzdHI+CQlVc2VySWQs
IHZhcl92YWx1ZSwgem9uZV92YWx1ZQogICV0eXBlIDxzdHI+CQlDb2xJZCwg
Q29sTGFiZWwKKioqKioqKioqKioqKioqCioqKiAxNTU1LDE1NTkgKioqKgog
ICAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KICAgCiEgQ29t
bWVudFN0bXQ6CUNPTU1FTlQgT04gY29tbWVudF90eXBlIG5hbWUgSVMgU2Nv
bnN0CiAgCQkJewogIAkJCQlDb21tZW50U3RtdCAqbiA9IG1ha2VOb2RlKENv
bW1lbnRTdG10KTsKLS0tIDE1NTUsMTU1OSAtLS0tCiAgICoqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqLwogICAKISBDb21tZW50U3RtdDoJQ09N
TUVOVCBPTiBjb21tZW50X3R5cGUgbmFtZSBJUyBjb21tZW50X3RleHQKICAJ
CQl7CiAgCQkJCUNvbW1lbnRTdG10ICpuID0gbWFrZU5vZGUoQ29tbWVudFN0
bXQpOwoqKioqKioqKioqKioqKioKKioqIDE1NjUsMTU2OSAqKioqCiAgCQkJ
CSQkID0gKE5vZGUgKikgbjsKICAJCQl9CiEgCQl8IENPTU1FTlQgT04gY29t
bWVudF9jbCByZWxhdGlvbl9uYW1lICcuJyBhdHRyX25hbWUgSVMgU2NvbnN0
CiAgCQkJewogIAkJCQlDb21tZW50U3RtdCAqbiA9IG1ha2VOb2RlKENvbW1l
bnRTdG10KTsKLS0tIDE1NjUsMTU2OSAtLS0tCiAgCQkJCSQkID0gKE5vZGUg
KikgbjsKICAJCQl9CiEgCQl8IENPTU1FTlQgT04gY29tbWVudF9jbCByZWxh
dGlvbl9uYW1lICcuJyBhdHRyX25hbWUgSVMgY29tbWVudF90ZXh0CiAgCQkJ
ewogIAkJCQlDb21tZW50U3RtdCAqbiA9IG1ha2VOb2RlKENvbW1lbnRTdG10
KTsKKioqKioqKioqKioqKioqCioqKiAxNTc1LDE1NzkgKioqKgogIAkJCQkk
JCA9IChOb2RlICopIG47CiAgCQkJfQohIAkJfCBDT01NRU5UIE9OIGNvbW1l
bnRfYWcgbmFtZSBhZ2dyX2FyZ3R5cGUgSVMgU2NvbnN0CiAgCQkJewogIAkJ
CQlDb21tZW50U3RtdCAqbiA9IG1ha2VOb2RlKENvbW1lbnRTdG10KTsKLS0t
IDE1NzUsMTU3OSAtLS0tCiAgCQkJCSQkID0gKE5vZGUgKikgbjsKICAJCQl9
CiEgCQl8IENPTU1FTlQgT04gY29tbWVudF9hZyBuYW1lIGFnZ3JfYXJndHlw
ZSBJUyBjb21tZW50X3RleHQKICAJCQl7CiAgCQkJCUNvbW1lbnRTdG10ICpu
ID0gbWFrZU5vZGUoQ29tbWVudFN0bXQpOwoqKioqKioqKioqKioqKioKKioq
IDE1ODUsMTU4OSAqKioqCiAgCQkJCSQkID0gKE5vZGUgKikgbjsKICAJCQl9
CiEgCQl8IENPTU1FTlQgT04gY29tbWVudF9mbiBmdW5jX25hbWUgZnVuY19h
cmdzIElTIFNjb25zdAogIAkJCXsKICAJCQkJQ29tbWVudFN0bXQgKm4gPSBt
YWtlTm9kZShDb21tZW50U3RtdCk7Ci0tLSAxNTg1LDE1ODkgLS0tLQogIAkJ
CQkkJCA9IChOb2RlICopIG47CiAgCQkJfQohIAkJfCBDT01NRU5UIE9OIGNv
bW1lbnRfZm4gZnVuY19uYW1lIGZ1bmNfYXJncyBJUyBjb21tZW50X3RleHQK
ICAJCQl7CiAgCQkJCUNvbW1lbnRTdG10ICpuID0gbWFrZU5vZGUoQ29tbWVu
dFN0bXQpOwoqKioqKioqKioqKioqKioKKioqIDE1OTUsMTU5OSAqKioqCiAg
CQkJCSQkID0gKE5vZGUgKikgbjsKICAJCQl9CiEgCQl8IENPTU1FTlQgT04g
Y29tbWVudF9vcCBhbGxfT3AgJygnIG9wZXJfYXJndHlwZXMgJyknIElTIFNj
b25zdAogIAkJCXsKICAJCQkJQ29tbWVudFN0bXQgKm4gPSBtYWtlTm9kZShD
b21tZW50U3RtdCk7Ci0tLSAxNTk1LDE1OTkgLS0tLQogIAkJCQkkJCA9IChO
b2RlICopIG47CiAgCQkJfQohIAkJfCBDT01NRU5UIE9OIGNvbW1lbnRfb3Ag
YWxsX09wICcoJyBvcGVyX2FyZ3R5cGVzICcpJyBJUyBjb21tZW50X3RleHQK
ICAJCQl7CiAgCQkJCUNvbW1lbnRTdG10ICpuID0gbWFrZU5vZGUoQ29tbWVu
dFN0bXQpOwoqKioqKioqKioqKioqKioKKioqIDE2MDUsMTYwOSAqKioqCiAg
CQkJCSQkID0gKE5vZGUgKikgbjsKICAJCQl9CiEgCQl8IENPTU1FTlQgT04g
Y29tbWVudF90ZyBuYW1lIE9OIHJlbGF0aW9uX25hbWUgSVMgU2NvbnN0CiAg
CQkJewogIAkJCQlDb21tZW50U3RtdCAqbiA9IG1ha2VOb2RlKENvbW1lbnRT
dG10KTsKLS0tIDE2MDUsMTYwOSAtLS0tCiAgCQkJCSQkID0gKE5vZGUgKikg
bjsKICAJCQl9CiEgCQl8IENPTU1FTlQgT04gY29tbWVudF90ZyBuYW1lIE9O
IHJlbGF0aW9uX25hbWUgSVMgY29tbWVudF90ZXh0CiAgCQkJewogIAkJCQlD
b21tZW50U3RtdCAqbiA9IG1ha2VOb2RlKENvbW1lbnRTdG10KTsKKioqKioq
KioqKioqKioqCioqKiAxNjM5LDE2NDQgKioqKgogIAogIGNvbW1lbnRfdGc6
CVRSSUdHRVIgeyAkJCA9IFRSSUdHRVI7IH0KISAJCTsKICAKICAvKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioKICAgKgotLS0gMTYzOSwxNjQ4
IC0tLS0KICAKICBjb21tZW50X3RnOglUUklHR0VSIHsgJCQgPSBUUklHR0VS
OyB9CiEgCQk7IAogIAorIGNvbW1lbnRfdGV4dDoJU2NvbnN0IHsgJCQgPSAk
MTsgfQorIAkJfCBOVUxMX1AgeyAkJCA9IDA7IH0KKyAJCTsKKyAJCQogIC8q
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgogICAqCg==

--0-1681692777-940936736=:12865--

From bouncefilter Tue Oct 26 07:33:54 1999
Received: from Radha.DoCS.UU.SE (root@Radha.DoCS.UU.SE [130.238.9.99])
by hub.org (8.9.3/8.9.3) with SMTP id HAA87667
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 07:33:16 -0400 (EDT)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Krabba.DoCS.UU.SE (e99re41@Krabba.DoCS.UU.SE [130.238.9.177])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id NAA23071;
Tue, 26 Oct 1999 13:33:10 +0200
Received: from localhost (e99re41@localhost) by Krabba.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA11203;
Tue, 26 Oct 1999 13:33:09 +0200
X-Authentication-Warning: Krabba.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 26 Oct 1999 13:33:08 +0200 (MET DST)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [PATCHES] COMMENT ON patch
In-Reply-To: <199910260434.AAA19091@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.9910261318130.11161-100000@Krabba.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 26 Oct 1999, Bruce Momjian wrote:

In related news I'd like to point out that psql's \dd command now supports
aggregates, functions, operators, types, relations (tables, views,
indices, sequences), rules, and triggers. In addition all the other \d?
commands (\da, \df, \dT, \do, \dtvsiS), as well as \l, have comments
display switchable. Attribute comments can be seen in \d in a similar
fashion. You can also give a comment on \lo_import which can then be seen
in \lo_list (=\dl). Seems like all the bases are covered.

OK, I think we need help on this. I have added documentation in
psqlHelp.c and comment.sgml. You are mentioning some new psql flags
that I don't know we had. Can you send info on that. psql.c and
psql-ref.sgml are two areas that need additions based on what you said.

I implemented sort of shell variables into psql (I mentioned it in the
changelogs, but those were admittedly quite long), so you can set
variables like:
\set foo 'bar'
\echo $foo
\echo "foo is now ${foo}"
etc.

The initial motivation was that I would run out of mnemonic flags pretty
soon, so most psql state is now in a variable:
\set quiet on (-q switch)
\set echo on (-e switch)
\set echo_secret on (-E switch)
etc.
(In fact you don't have to set them to "on", anything works. To unset them
just write \set varname)
The cmd line switches are unaffected, but this way you can also set them
within psql. There are also a few variables representing new
functionality:
\set description on
will turn on the display of the object descriptions. There are a few
others, too.

That's just what I meant with the above. Of course one fine day very soon
I'll formally document all of this in DocBook. There is _a lot_ of new
stuff, so I might actually end up doing a lot of new documenting. You
might want to save yourself the work right now.

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Oct 26 08:47:54 1999
Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar
[200.10.100.10]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA96217
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 08:47:37 -0400 (EDT)
(envelope-from fpscha@ns1.via-net-works.net.ar)
Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.8.5/8.8.4)
id JAA06204; Tue, 26 Oct 1999 09:47:12 -0300 (GMT)
From: Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar>
Message-Id: <199910261247.JAA06204@ns1.via-net-works.net.ar>
Subject: Re: [HACKERS] Neverending query on 6.5.2 over Solaris 2.5.1
In-Reply-To: <2359.940720039@sss.pgh.pa.us> from Tom Lane at "Oct 23,
99 07:07:19 pm"
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Tue, 26 Oct 1999 09:47:11 -0300 (GMT)
Cc: fpscha@via-net-works.net.ar, pgsql-hackers@postgreSQL.org
Reply-To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
X-Mailer: ELM [version 2.4ME+ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

En un mensaje anterior, Tom Lane escribi�:

Well, it's sure confused about the selectivity of WHERE activa,
all right.

I tried to duplicate this here, by duplicating the table definition you
sent and filling it with some junk data --- about 1800 rows, 1500 of
which had activa = 't'. I found that after loading the table and
running a plain "vacuum", the system indeed estimated one row out, just
as you show above. But after "vacuum analyze", it estimated 1360 rows
out, which is a lot closer to reality (and would make a big difference
in the plan selected for a join).

Now I know you said you did a "vacuum analyze" on the table, but
I am wondering if maybe you got confused about what you did.
Please try it again just to make sure.

I tried again and now it's working better. I think the first problem
was due to low shared memory available and a special factor between my
keyboard and my chair ;-)

Thanks for all you help!

Fernando P. Schapachnik
Administraci�n de la red
VIA Net Works Argentina SA
Diagonal Roque S�enz Pe�a 971, 4� y 5� piso.
1035 - Capital Federal, Argentina.
(54-11) 4323-3333
http://www.via-net-works.net.ar

From bouncefilter Tue Oct 26 10:03:54 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA06447
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 10:03:02 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA22609;
Tue, 26 Oct 1999 10:01:59 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
In-reply-to: Your message of Tue, 26 Oct 1999 01:25:43 -0400 (EDT)
<199910260525.BAA21896@candle.pha.pa.us>
Date: Tue, 26 Oct 1999 10:01:59 -0400
Message-ID: <22606.940946519@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Sounds good. My only question is whether people need backward
compatibility, and whether we can remove the compatiblity part of the
interface and small overhead after 7.1 or later?

I think we could drop it after a decent interval, but I don't see any
reason to be in a hurry. I do think that we'll get complaints if 7.0
doesn't have any backward compatibility for existing user functions.

regards, tom lane

From bouncefilter Tue Oct 26 10:18:55 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id KAA08777
for pgsql-hackers@postgresql.org; Tue, 26 Oct 1999 10:18:13 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: saad <ahmed1@sat.net.pk>
X-Newsgroups: comp.databases.postgresql.hackers
Subject: what the hell telnet is
Date: Tue, 26 Oct 1999 07:17:37 -0700
Organization: Interpacket Group Inc.
Lines: 3
Message-ID: <3815B800.6F8C6600@sat.net.pk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: news.interpacket.net 940947483 78118 202.163.96.132 (26 Oct 1999
14:18:03 GMT)
X-Complaints-To: usenet@news.interpacket.net
X-Mailer: Mozilla 4.08 [en] (Win95; I)
X-Original-NNTP-Posting-Host: 202.163.97.236
To: pgsql-hackers@postgresql.org

will some one tell me how to use telnet and what is it .
the-virus

From bouncefilter Tue Oct 26 10:32:55 1999
Received: from hipernet.com.br (nautilus.hipernet.com.br [200.246.90.107])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA10906
for <pgsql-hackers@postgresql.org>;
Tue, 26 Oct 1999 10:32:00 -0400 (EDT)
(envelope-from roberto@mha.com.br)
Received: from pc35.mha.com.br ([200.230.11.129])
by hipernet.com.br (8.9.3/8.9.3) with SMTP id MAA11742
for <pgsql-hackers@postgresql.org>;
Tue, 26 Oct 1999 12:32:00 -0200 (EDT)
Message-Id: <3.0.5.32.19991026122515.007cf100@pop.hipernet.com.br>
X-Sender: roberto@pop.hipernet.com.br
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Tue, 26 Oct 1999 12:25:15 -0200
To: pgsql-hackers@postgresql.org
From: Roberto Joao Lopes Garcia <roberto@mha.com.br>
Subject: Error: shmget failed
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id KAA10971

Hi

Sorry if it�s the wrong place to post this. Please let me know where is the
correct place.

I'm upgrading from PostgreSQL 6.4 to 6.5.2. I compiled 6.5.2 and installed
it in an machine (that was not running 6.4) for tests but Postmaster want
not run.

Os: Sun sparc solaris 2.5
compiled with GCC 2.8.1, FLEX 2.5.4

Compilation and install runs OK!
Initidb could not tell what username to use (I was su postgres) so I tried
initdb -u postgres and works, see bellow:

$ LD_LIBRARY_PATH=/usr/local/pgsql/lib
$ export LD_LIBRARY_PATH
$
initdb

Can't tell what username to use. You don't have the
USER
environment variable set to your username and didn't specify the

--username option
$ initdb -u postgres

We are initializing the database
system with username postgres (uid=1156).
This user will own all the files
and must also own the server process.

Creating Postgres database system
directory /usr/local/pgsql/data

Creating Postgres database system
directory /usr/local/pgsql/data/base

Creating template database in
/usr/local/pgsql/data/base/template1

Creating global classes in
/usr/local/pgsql/data/base

Adding template1 database to
pg_database...

Vacuuming template1
Creating public pg_user view
Creating
view pg_rules
Creating view pg_views
Creating view pg_tables
Creating view
pg_indexes
Loading pg_description
$

I tried to start postmaster and it report an error, see bellow:

$ nohup postmaster -i > pserver.log 2>&1 &
[1]: + Done nohup postmaster -i > pserver.log 2>&1 & $ cat pserver.log IpcMemoryCreate: shmget failed (Invalid argument) key=5432001, size=1073152, permission=600 FATAL 1: ShmemCreate: cannot create region $
$ ps -ef | grep
post
postgres 6006 529 0 10:22:05 pts/1 0:00 ksh
postgres 17225
6006 1 11:01:41 pts/1 0:00 grep post
[1]: + Done nohup postmaster -i > pserver.log 2>&1 & $ cat pserver.log IpcMemoryCreate: shmget failed (Invalid argument) key=5432001, size=1073152, permission=600 FATAL 1: ShmemCreate: cannot create region $
nohup postmaster -i > pserver.log 2>&1 &
$ cat
pserver.log
IpcMemoryCreate: shmget failed (Invalid argument) key=5432001,
size=1073152, permission=600
FATAL 1: ShmemCreate: cannot create region
$

I have tried 3 times this installation and the result is the same. I
installed 6.5.2 in my house linux machine and work well.

Thank you for your attention

Roberto

From bouncefilter Tue Oct 26 11:15:56 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA17805
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 11:15:16 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA22970;
Tue, 26 Oct 1999 11:14:41 -0400 (EDT)
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
In-reply-to: Your message of Tue, 26 Oct 1999 11:06:35 +0200 (MET DST)
<m11g2Yt-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Tue, 26 Oct 1999 11:14:40 -0400
Message-ID: <22968.940950880@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

[ responding to both of Jan's messages in one ]

wieck@debis.com (Jan Wieck) writes:

I like the current interface for it's simpleness from the user
function developers point of view.

There is that; even with a good set of convenience macros there will be
more to learn about writing user functions. OTOH, the way it is now
is not exactly transparent --- in particular, NULL handling is so easy
to forget about/get wrong. We can make that much easier. We can also
simplify the interface noticeably for standard types like float4/float8.

BTW: I am not in nearly as big a hurry as Bruce is to rip out support
for the current user-function interface. I want to get rid of old-style
builtin functions before 7.0 because of the portability issue (see
below). But if a particular user is using old-style user functions
and isn't having portability problems on his machine, there's no need
to force him to convert, it seems to me.

And converting ALL
internal plus most of the contrib directories ones to
something new is really a huge project.

It is. I was hoping to get some help ;-) ... but I will do it myself
if I have to.

... And there are only a few internal
functions where a new fmgr interface really is required due
to incomplete NULL handling or the like.

If your goal is *only* to deal with the NULL issue, or *only* to get
things working on a specific platform like Alpha, then yes we could
patch in a few dozen places and not undertake a complete changeover.
But I believe that we really need to fix this right, because it will
keep coming back to haunt us until we do. I will not be happy as
long as we have ports that have to compile "-O0" because of fmgr
brain-damage. I fear there are going to be more and more such ports
as people install smarter compilers that assume they are working with
ANSI-compliant source code. We're giving up performance system-wide
because of fmgr.

Therefore I would prefer an interface extension, that doesn't
require changes to existing functions. What about adding a
proifversion to pg_proc, telling the fmgr which call
interface the function uses?

I was going to let the prolang column tell that, by having different
language codes for old vs. new builtin function and old vs. new
dynamic-linked C function. We could add a version column instead,
but that seems like unnecessary complication.

First fmgr_info() is extended to put the interface version
into the FmgrInfo too. Then fmgr_faddr() is renamed to
fmgr_faddr_v1() and it has to check that only functions using
the old interface are called through it (there aren't that
many calls to it as you might think).

I think it should be possible to make fmgr_faddr call both old and
new functions --- I haven't actually written code yet, but I think
I can do it. You're right that that's important in order to spread
out the repair work instead of having a "big bang".

This approach nearly matches all my thoughts about the
redesign of the fmgr. In the system table section I miss
named arguments.

As you said in your earlier message, that is a parser-level feature
that has nothing to do with what happens at the fmgr level. I don't
want to worry about it for this revision.

Also I miss the interface for tuple set returns. I know that
this requires much more in other sections than only the fmgr,
but we need to cover it now or we'll not be able to do it
without another change to the fmgr interface at the time we
want to support real stored procedures.

OK, I'm willing to worry about that. But what, exactly, needs to
be provided in the fmgr interface?

regards, tom lane

From bouncefilter Tue Oct 26 11:39:56 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id LAA21049
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 11:39:31 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11g8dk-0003kLC; Tue, 26 Oct 99 17:36 MET DST
Message-Id: <m11g8dk-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Tue, 26 Oct 1999 17:36:00 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <22968.940950880@sss.pgh.pa.us> from "Tom Lane" at Oct 26,
99 11:14:40 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

[ responding to both of Jan's messages in one ]

wieck@debis.com (Jan Wieck) writes:

I like the current interface for it's simpleness from the user
function developers point of view.

There is that; even with a good set of convenience macros there will be
more to learn about writing user functions. OTOH, the way it is now
is not exactly transparent --- in particular, NULL handling is so easy
to forget about/get wrong. We can make that much easier. We can also
simplify the interface noticeably for standard types like float4/float8.

BTW: I am not in nearly as big a hurry as Bruce is to rip out support
for the current user-function interface. I want to get rid of old-style
builtin functions before 7.0 because of the portability issue (see
below). But if a particular user is using old-style user functions
and isn't having portability problems on his machine, there's no need
to force him to convert, it seems to me.

Personally, I could live with dropping the entire old
interface. That's not the problem. But at least Bruce and his
book need to know the final programming conventions if we
ought to change it at all, so it can be covered in his
manuscript when it is sent down to the paper.

I was going to let the prolang column tell that, by having different
language codes for old vs. new builtin function and old vs. new
dynamic-linked C function. We could add a version column instead,
but that seems like unnecessary complication.

Right - language is all needed to tell.

This approach nearly matches all my thoughts about the
redesign of the fmgr. In the system table section I miss
named arguments.

As you said in your earlier message, that is a parser-level feature
that has nothing to do with what happens at the fmgr level. I don't
want to worry about it for this revision.

Right too. I just hoped to expand the scope of this change so
there would only ONE change to the PL handlers covering both,
new interface with proper NULL handling and enhanced function
prototypes.

Also I miss the interface for tuple set returns. I know that
this requires much more in other sections than only the fmgr,
but we need to cover it now or we'll not be able to do it
without another change to the fmgr interface at the time we
want to support real stored procedures.

OK, I'm willing to worry about that. But what, exactly, needs to
be provided in the fmgr interface?

First we need another relation type in pg_class. It's like a
table or view, but none of the NORMAL SQL statements can be
used with it (e.g. INSERT, SELECT, ...). It just describes a
row structure.

Then, a function returning a SET of any row type (this time,
regular relations or views too) can be used in the rangetable
as

SELECT A.col1, B.col2 FROM mysetfunc() A, anothertab B
WHERE A.col1 = B.col1;

Of course, it requires some new fields in the rangetable
entry. Anyway, at the beginning of execution for such a
query, the executor initializes those RTE's by creating a
temptable with the schema of the specified structure or
relation. Then it calls the user function, passing in some
handle to the temp table and the user function fills in the
tuples. Now the rest of query execution is if it is a regular
table. After execution, the temp table is dropped.

Isn't that all required for true stored procedures?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Tue Oct 26 12:23:56 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA30738
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 12:23:02 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA23211;
Tue, 26 Oct 1999 12:22:05 -0400 (EDT)
To: Roberto Joao Lopes Garcia <roberto@mha.com.br>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Error: shmget failed
In-reply-to: Your message of Tue, 26 Oct 1999 12:25:15 -0200
<3.0.5.32.19991026122515.007cf100@pop.hipernet.com.br>
Date: Tue, 26 Oct 1999 12:22:04 -0400
Message-ID: <23209.940954924@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Roberto Joao Lopes Garcia <roberto@mha.com.br> writes:

I tried to start postmaster and it report an error, see bellow:
IpcMemoryCreate: shmget failed (Invalid argument) key=5432001,
size=1073152, permission=600
FATAL 1: ShmemCreate: cannot create region

As a quick hack you can start the postmaster with smaller-than-
normal -B and -N (say -B 40 -N 20). Long term solution is to
increase your kernel's SHMMAX limit to more than 1 megabyte.

I thought we had adjusted the default -B and -N to stay just
under a meg, which is the default SHMMAX value on many kernels.
But it looks like someone chewed up some more shared memory when
I wasn't looking :-(.

regards, tom lane

From bouncefilter Tue Oct 26 12:36:56 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA32781
for <pgsql-hackers@postgresql.org>;
Tue, 26 Oct 1999 12:34:53 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA23357;
Tue, 26 Oct 1999 12:24:13 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910261624.MAA23357@candle.pha.pa.us>
Subject: Re: [HACKERS] Logging - pg_options format change?
In-Reply-To: <22092.940918572@sss.pgh.pa.us> from Tom Lane at "Oct 26,
1999 02:16:12 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 26 Oct 1999 12:24:13 -0400 (EDT)
CC: Tim Holloway <mtsinc@southeast.net>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tim Holloway <mtsinc@southeast.net> writes:

Would it be objectionable if I altered the format of the pg_options
file slightly? I feel the need to handle a somewhat more complex
syntax for the logging subsystem.

While I'm not particularly wedded to the pg_options format, I wonder
whether it wouldn't be a better idea to create a separate file for
the logging control data. If I'm reading your proposal correctly,
the backend would no longer parse existing pg_options files --- and
that's certain to make dbadmins unhappy, even if the fix is easy.
Upgrades are always stressful enough, even without added complications
like forced changes to config files.

You could probably tweak the syntax so that an existing pg_options
file is still valid, but that might be a bit too klugy. What's
wrong with having two separate files? We can assume that this isn't
a performance-critical path, I think.

With a 7.0 release, I think we can revamp that file without too many
complaints. pg_options file is fairly new, and it is an administrator's
thing, and only has to be done once. Seems like a revamp to make it
clear for all users would help. Having two files would mean explaining
that to people for ever.

-- 
  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 Tue Oct 26 12:30:56 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA32109
for <pgsql-hackers@postgresql.org>;
Tue, 26 Oct 1999 12:30:40 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA23374;
Tue, 26 Oct 1999 12:25:34 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910261625.MAA23374@candle.pha.pa.us>
Subject: Re: System indexes are never unique indexes( was RE: [HACKERS]
mdnblocksis
In-Reply-To: <m11g1hq-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 26, 1999 10:11:46 am"
To: Jan Wieck <wieck@debis.com>
Date: Tue, 26 Oct 1999 12:25:34 -0400 (EDT)
CC: Inoue@tpf.co.jp, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Not sure. I don't remember which ones. I can take a look when I add
more indexes for 7.0.

Don't remember if really or what, but wasn't there some
problem with cached system relations, unique indices and
concurrency?

I don't remember anything about that.

-- 
  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 Tue Oct 26 12:31:57 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA32097;
Tue, 26 Oct 1999 12:30:35 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA24170;
Tue, 26 Oct 1999 12:28:48 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910261628.MAA24170@candle.pha.pa.us>
Subject: Re: [PATCHES] Re: [HACKERS] Current source from CVS won't compile.
In-Reply-To: <19991026111856.13977.rocketmail@web2104.mail.yahoo.com> from
Mike
Mascari at "Oct 26, 1999 04:18:56 am"
To: Mike Mascari <mascarim@yahoo.com>
Date: Tue, 26 Oct 1999 12:28:48 -0400 (EDT)
CC: Keith Parks <emkxp01@mtcc.demon.co.uk>, pgsql-hackers@postgreSQL.org,
pgsql-patches@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied. Thanks.

Yes.

This is my fault. Sorry. Attached is a patch which fixes the problem.
I missed adding the rule to make parse.h to the Makefile for
the ../backend/commands. It also allows for comments to be dropped
using IS NULL as well as IS '';

Again, sorry.

Mike Mascari
(mascarim@yahoo.com)

--- Keith Parks <emkxp01@mtcc.demon.co.uk> wrote:

Hi All,

A make on a "cvs update" from this morning fails with the following
error message.

make -C commands all
make[2]: Entering directory `/usr/local/pgsql/src/backend/commands'
make[2]: *** No rule to make target `../parse.h', needed by `comment.o'.
Stop.
make[2]: Leaving directory `/usr/local/pgsql/src/backend/commands'
make[1]: *** [commands.dir] Error 2
make[1]: Leaving directory `/usr/local/pgsql/src/backend'
make: *** [install] Error 2

This looks to have been broken by the COMMENT patch.

Keith

************

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

Content-Description: patchfile

[Attachment, skipping...]

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Tue Oct 26 12:33:59 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA32516;
Tue, 26 Oct 1999 12:33:02 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA24351;
Tue, 26 Oct 1999 12:31:33 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910261631.MAA24351@candle.pha.pa.us>
Subject: Re: [HACKERS] Current source from CVS won't compile.
In-Reply-To: <19991026111856.13977.rocketmail@web2104.mail.yahoo.com> from
Mike
Mascari at "Oct 26, 1999 04:18:56 am"
To: Mike Mascari <mascarim@yahoo.com>
Date: Tue, 26 Oct 1999 12:31:33 -0400 (EDT)
CC: Keith Parks <emkxp01@mtcc.demon.co.uk>, pgsql-hackers@postgresql.org,
pgsql-patches@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Yes.

This is my fault. Sorry. Attached is a patch which fixes the problem.
I missed adding the rule to make parse.h to the Makefile for
the ../backend/commands. It also allows for comments to be dropped
using IS NULL as well as IS '';

Can we use only NULL, and not '' please? Seems clearer. I don't like
us of '' for any special handling. Thanks.

-- 
  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 Tue Oct 26 12:40:58 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA33762
for <hackers@postgresql.org>; Tue, 26 Oct 1999 12:39:55 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:4530 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s3RZ8227654>;
Tue, 26 Oct 1999 18:39:38 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2) id 11g9gp-0000fw-00
for hackers@postgresql.org; Tue, 26 Oct 1999 18:43:15 +0200
Date: Tue, 26 Oct 1999 18:43:15 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: psql Week 4
Message-ID: <Pine.LNX.4.10.9910252254530.369-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

Alrighty, this is it. I submit this to your scrutiny in the hope that it
will prove useful and reliable.

The source is at <http://www.pathwaynet.com/~peter/psql-final.tar.gz&gt;
(49k). In a perfect world you could just drop the directory into your
source tree and configure and compile again. Whether or not it is a
perfect world we will find out soon enough, I suppose.

Three patches are included in the tarball. One is a minor libpq fix which
I submitted the other day already and which is mandatory. (I now see it is
in the current tree already). Two more are to put a test of getopt_long
in the autoconf business. Other than that the changes are restricted to
the psql directory.

I'm going to do some more work on it but those should be localized
changes. Here are a few unresolved issues:

* It is now consistently possible to put several slash commands on a line,
even mixed with SQL, such as:
=> select * from \t \o file.out \x \\ my_table \g
This might cause a problem in Windows, if you need to write, for example,
\o \temp\dir. The fix would be to write \o '\temp\dir' (as opposed to \o
"\temp\dir", because that would be subject to substitutions like \t =>
tab). As this might be cumbersome I give the option to the Windows
community: disable things like the above command line completely or quote
your stuff. It's a tradeoff.
(On the other hand, I was at some point under the impression that
in C on Windows you could actually use forward slashes in your file names
which would be converted by some magic layer, thus making this a
non-issue.(?))

* Slash commands can only have up to 16 options. This is purely my own
laziness. Of course, no single slash command actually uses more than three
options, but it sure is unsatisfying.

* The \d* command silently disappeared. It's previous semantics where
"show everything" but I'm not quite sure what that should be short of
rewriting pg_dump.

* Heaven help you if you want to compile this under Windows. I don't have
Windows, so some porter will have to take care of that.

I am writing DocBook documentation right now and an updated version should
be available within 48 hours. For a starter here is a session that
attempts to illustrate a couple of the quoting and substitution features:

play=> \set foo 'bar'
play=> \echo $foo
bar
play=> \echo bla$foo
bla$foo
play=> \echo "bla${foo}bla"
blabarbla
play=> \echo 'bla${foo}bla'
bla${foo}bla
play=> \echo "a\nb"
a
b
play=> \echo 'a\nb'
a\nb
play=> \echo `uname -rms`
Linux 2.2.12 i586
play=> \set sql_interpol '#'
play=> \set singlestep on
play=> \set blah `/usr/games/fortune`
play=> insert into foo values (0, '#blah#');
***(Single step mode: Verify query)*********************************************
QUERY: insert into foo values (0, 'Everything you read in newspapers is
absolutely true, except for that
rare story of which you happen to have first-hand knowledge.
-- Erwin Knoll')
***(press return to proceed or enter x and return to cancel)********************
x

If you use the large object operations, your previous transaction will be
rolled back. To change this do \set lo_transaction 'commit' or \set
lo_transaction 'nothing' (in which case you must provide your own
BEGIN/END block).

Most other stuff can be determined from \? or -?, respectively, and also
from the changelogs I posted in the past.

Enjoy!

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Tue Oct 26 13:32:57 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA50093
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 13:32:37 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA26631;
Tue, 26 Oct 1999 12:46:54 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910261646.MAA26631@candle.pha.pa.us>
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
In-Reply-To: <22606.940946519@sss.pgh.pa.us> from Tom Lane at "Oct 26,
1999 10:01:59 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 26 Oct 1999 12:46:54 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian <maillist@candle.pha.pa.us> writes:

Sounds good. My only question is whether people need backward
compatibility, and whether we can remove the compatiblity part of the
interface and small overhead after 7.1 or later?

I think we could drop it after a decent interval, but I don't see any
reason to be in a hurry. I do think that we'll get complaints if 7.0
doesn't have any backward compatibility for existing user functions.

True.

-- 
  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 Tue Oct 26 13:33:58 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA50219
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 13:33:46 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA26707;
Tue, 26 Oct 1999 12:49:57 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910261649.MAA26707@candle.pha.pa.us>
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
In-Reply-To: <m11g8dk-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 26, 1999 05:36:00 pm"
To: Jan Wieck <wieck@debis.com>
Date: Tue, 26 Oct 1999 12:49:57 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[ responding to both of Jan's messages in one ]

wieck@debis.com (Jan Wieck) writes:

I like the current interface for it's simpleness from the user
function developers point of view.

There is that; even with a good set of convenience macros there will be
more to learn about writing user functions. OTOH, the way it is now
is not exactly transparent --- in particular, NULL handling is so easy
to forget about/get wrong. We can make that much easier. We can also
simplify the interface noticeably for standard types like float4/float8.

BTW: I am not in nearly as big a hurry as Bruce is to rip out support
for the current user-function interface. I want to get rid of old-style
builtin functions before 7.0 because of the portability issue (see
below). But if a particular user is using old-style user functions
and isn't having portability problems on his machine, there's no need
to force him to convert, it seems to me.

Personally, I could live with dropping the entire old
interface. That's not the problem. But at least Bruce and his
book need to know the final programming conventions if we
ought to change it at all, so it can be covered in his
manuscript when it is sent down to the paper.

No. My coverage of that is going to be more conceptual than actual
programming. Do whatever you think is best.

-- 
  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 Tue Oct 26 13:31:57 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA49941
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 13:31:11 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA26723;
Tue, 26 Oct 1999 12:51:11 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910261651.MAA26723@candle.pha.pa.us>
Subject: Re: [HACKERS] Error: shmget failed
In-Reply-To: <23209.940954924@sss.pgh.pa.us> from Tom Lane at "Oct 26,
1999 12:22:04 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 26 Oct 1999 12:51:11 -0400 (EDT)
CC: Roberto Joao Lopes Garcia <roberto@mha.com.br>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Roberto Joao Lopes Garcia <roberto@mha.com.br> writes:

I tried to start postmaster and it report an error, see bellow:
IpcMemoryCreate: shmget failed (Invalid argument) key=5432001,
size=1073152, permission=600
FATAL 1: ShmemCreate: cannot create region

As a quick hack you can start the postmaster with smaller-than-
normal -B and -N (say -B 40 -N 20). Long term solution is to
increase your kernel's SHMMAX limit to more than 1 megabyte.

I thought we had adjusted the default -B and -N to stay just
under a meg, which is the default SHMMAX value on many kernels.
But it looks like someone chewed up some more shared memory when
I wasn't looking :-(.

7.0 backend will point them to FAQ on such errors.

-- 
  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 Tue Oct 26 13:16:57 1999
Received: from web2101.mail.yahoo.com (web2101.mail.yahoo.com [128.11.68.245])
by hub.org (8.9.3/8.9.3) with SMTP id NAA47500
for <pgsql-hackers@postgresql.org>;
Tue, 26 Oct 1999 13:16:00 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19991026171619.22199.rocketmail@web2101.mail.yahoo.com>
Received: from [24.26.131.45] by web2101.mail.yahoo.com;
Tue, 26 Oct 1999 10:16:19 PDT
Date: Tue, 26 Oct 1999 10:16:19 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] Current source from CVS won't compile.
To: Bruce Momjian <maillist@candle.pha.pa.us>
Cc: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Bruce Momjian <maillist@candle.pha.pa.us> wrote:

Yes.

This is my fault. Sorry. Attached is a patch which fixes the problem.
I missed adding the rule to make parse.h to the Makefile for
the ../backend/commands. It also allows for comments to be dropped
using IS NULL as well as IS '';

Can we use only NULL, and not '' please? Seems clearer. I don't like
us of '' for any special handling. Thanks.

-- 
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

I agree with you, an empty string is a goofy way to drop a comment.
The only reason I did it that way was because that's how Oracle does
it (heck, why not create comment on, drop comment on). The question is,
what should the behavior be when a user supplies an empty string?

COMMENT ON TABLE employees IS '';

Should the above add an empty comment to pg_description?

Its up to you... :-)

Mike Mascari
(mascarim@yahoo.com)

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

From bouncefilter Tue Oct 26 13:56:57 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA54271
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 13:55:56 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id NAA28034;
Tue, 26 Oct 1999 13:38:12 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910261738.NAA28034@candle.pha.pa.us>
Subject: Re: [HACKERS] Current source from CVS won't compile.
In-Reply-To: <19991026171619.22199.rocketmail@web2101.mail.yahoo.com> from
Mike
Mascari at "Oct 26, 1999 10:16:19 am"
To: Mike Mascari <mascarim@yahoo.com>
Date: Tue, 26 Oct 1999 13:38:12 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Can we use only NULL, and not '' please? Seems clearer. I don't like
us of '' for any special handling. Thanks.

-- 
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

I agree with you, an empty string is a goofy way to drop a comment.
The only reason I did it that way was because that's how Oracle does
it (heck, why not create comment on, drop comment on). The question is,
what should the behavior be when a user supplies an empty string?

COMMENT ON TABLE employees IS '';

Should the above add an empty comment to pg_description?

OK, I like the compatability issue. Let's leave both as dropping
comments, but only document the NULL case. SGML already 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 19026

From bouncefilter Tue Oct 26 19:24:00 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA56146
for <pgsql-hackers@postgresql.org>;
Tue, 26 Oct 1999 19:23:58 -0400 (EDT)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id TAA07548;
Tue, 26 Oct 1999 19:21:44 -0400 (EDT)
Message-ID: <381635B9.6DEFE78A@southeast.net>
Date: Tue, 26 Oct 1999 19:14:01 -0400
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Logging - pg_options format change?
References: <199910261624.MAA23357@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Tim Holloway <mtsinc@southeast.net> writes:

Would it be objectionable if I altered the format of the pg_options
file slightly? I feel the need to handle a somewhat more complex
syntax for the logging subsystem.

While I'm not particularly wedded to the pg_options format, I wonder
whether it wouldn't be a better idea to create a separate file for
the logging control data. If I'm reading your proposal correctly,
the backend would no longer parse existing pg_options files --- and
that's certain to make dbadmins unhappy, even if the fix is easy.
Upgrades are always stressful enough, even without added complications
like forced changes to config files.

You could probably tweak the syntax so that an existing pg_options
file is still valid, but that might be a bit too klugy. What's
wrong with having two separate files? We can assume that this isn't
a performance-critical path, I think.

With a 7.0 release, I think we can revamp that file without too many
complaints. pg_options file is fairly new, and it is an administrator's
thing, and only has to be done once. Seems like a revamp to make it
clear for all users would help. Having two files would mean explaining
that to people for ever.

--
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

Not to worry - the operative word was "wrap". In fact, I planned to leave the existing
debug parser intact and just jump into it if the proper trigger for extended syntax isn't
seen (also as a subprocessor if it IS seen). I've been on the receiving end of trauma
too many times myself.

I had considered making a "postgresql.conf" file with an option for debugging statements,
but the net effect would just be the same anyway. Besides, Apache went the multi-config
file route and regretted it. I'd rather not repeat history if a little advance planning
can avoid it.

There's another consideration. If a SIGHUP rescanned the ENTIRE configuration and there were
two config files, BOTH of them would end up being processed anyway.

Tim Holloway

From bouncefilter Tue Oct 26 19:45:00 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA11628
for <pgsql-hackers@postgreSQL.org>;
Tue, 26 Oct 1999 19:44:22 -0400 (EDT)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id TAA15938;
Tue, 26 Oct 1999 19:41:29 -0400 (EDT)
Message-ID: <38163A58.2F9AFCA7@southeast.net>
Date: Tue, 26 Oct 1999 19:33:44 -0400
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; 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] Logging - pg_options format change?
References: <22092.940918572@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Also, is YACC sufficently thread-safe that if a SIGHUP starts
parsing options it won't collide with another task's in-progress
parsing of, say a SELECT statement?

Don't even think of going there. Even if yacc/bison code itself can be
made reentrant (which I doubt; it's full of static variables) you'd also
have to assume that large chunks of libc are reentrant --- malloc() and
stdio in particular --- and I know for a fact that you *cannot* assume
that. There might be some platforms where it will work, but many others
won't.

Basically, the only thing that's really safe for a signal handler to do
is set an int flag to TRUE for a test in the main control paths to
notice at some later (hopefully not too much later) time. The
QueryCancel flag in the existing Postgres code is an example.

For the purposes of logging, I see no reason why it wouldn't be
good enough to reread the config file at the start of the next
query-execution cycle. There's no need to take the risks of doing
anything unportable.

regards, tom lane

Darn. I thought newer YACC programs had gotten rid of that kind of mess. But then
I thought the same of the C libs, too. Oh well.

I trust that it IS safe to use do the config reread using YACC if I do it as a
"query-execution" task?

Thanks!
Tim Holloway

From bouncefilter Tue Oct 26 20:50:01 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA61358
for <pgsql-hackers@postgresql.org>;
Tue, 26 Oct 1999 20:49:59 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA04575; Wed, 27 Oct 1999 09:48:48 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>, "Jan Wieck" <wieck@debis.com>
Cc: <pgsql-hackers@postgresql.org>
Subject: RE: System indexes are never unique indexes( was RE: [HACKERS]
mdnblocksis
Date: Wed, 27 Oct 1999 09:52:55 +0900
Message-ID: <000201bf2015$9ae0f7a0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <199910261625.MAA23374@candle.pha.pa.us>
Importance: Normal

Not sure. I don't remember which ones. I can take a look when I add
more indexes for 7.0.

Don't remember if really or what, but wasn't there some
problem with cached system relations, unique indices and
concurrency?

I don't remember anything about that.

I don't know old PostgreSQL at all.
Only one thing I could suppose is the following.

Before MVCC it was unnecessary to read dirty(uncommited) tuples
to check uniqueness because a table level exclusive lock was acquired
automatically. As for user tuples,the consistency was perserved because
the lock was held until transaction end. As for system tuples,the
consistency
could be broken if the lock was a short term lock.

After MVCC,dirty(uncommitted) tuples are taken into account to check
uniqueness and any lock is no longer needed.

AFAIK,there are no other means to check(lock ?) (logically) non-existent
rows now(Referencial Integrity would provide the second one).
So probably PostgreSQL couldn't guarantee the uniquness of system
tuples in many cases.

Anyway,I want to change the implementation of mdcreate() to reuse
existent files but the uniqueness of table name is preserved by the
current implementation narrowly.

First of all,I would change pg_type,pg_class.
It's OK ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Oct 26 21:26:01 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA68104
for <pgsql-hackers@postgresql.org>;
Tue, 26 Oct 1999 21:25:39 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id VAA06770;
Tue, 26 Oct 1999 21:24:57 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910270124.VAA06770@candle.pha.pa.us>
Subject: Re: System indexes are never unique indexes( was RE: [HACKERS]
mdnblocksis
In-Reply-To: <000201bf2015$9ae0f7a0$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Oct 27, 1999 09:52:55 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 26 Oct 1999 21:24:57 -0400 (EDT)
CC: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I don't know old PostgreSQL at all.
Only one thing I could suppose is the following.

Before MVCC it was unnecessary to read dirty(uncommited) tuples
to check uniqueness because a table level exclusive lock was acquired
automatically. As for user tuples,the consistency was perserved because
the lock was held until transaction end. As for system tuples,the
consistency
could be broken if the lock was a short term lock.

After MVCC,dirty(uncommitted) tuples are taken into account to check
uniqueness and any lock is no longer needed.

AFAIK,there are no other means to check(lock ?) (logically) non-existent
rows now(Referencial Integrity would provide the second one).
So probably PostgreSQL couldn't guarantee the uniquness of system
tuples in many cases.

Anyway,I want to change the implementation of mdcreate() to reuse
existent files but the uniqueness of table name is preserved by the
current implementation narrowly.

First of all,I would change pg_type,pg_class.
It's OK ?

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 19026

From bouncefilter Wed Oct 27 05:43:07 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA34535
for <pgsql-hackers@postgresql.org>;
Wed, 27 Oct 1999 05:42:51 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id SAA04863; Wed, 27 Oct 1999 18:41:44 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>
Cc: <pgsql-hackers@postgresql.org>
Subject: RE: System indexes are never unique indexes( was RE: [HACKERS]
mdnblocksis
Date: Wed, 27 Oct 1999 18:45:49 +0900
Message-ID: <000401bf2060$0d08e820$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <199910270124.VAA06770@candle.pha.pa.us>
Importance: Normal

Anyway,I want to change the implementation of mdcreate() to reuse
existent files but the uniqueness of table name is preserved by the
current implementation narrowly.

First of all,I would change pg_type,pg_class.
It's OK ?

Sure.

I made a patch.
But I'm not sure my solution is right.
Is there a better way ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

*** ../../head/pgcurrent/backend/bootstrap/bootscanner.l	Tue Sep 14
12:17:34 1999
--- backend/bootstrap/bootscanner.l	Tue Oct 26 23:36:08 1999
***************
*** 90,95 ****
--- 90,96 ----
  "declare"		{ return(XDECLARE); }
  "build"			{ return(XBUILD); }
  "indices"		{ return(INDICES); }
+ "unique"		{ return(UNIQUE); }
  "index"			{ return(INDEX); }
  "on"			{ return(ON); }
  "using"			{ return(USING); }
*** ../../head/pgcurrent/backend/bootstrap/bootparse.y	Mon Jul 26 12:44:44
1999
--- backend/bootstrap/bootparse.y	Tue Oct 26 23:47:20 1999
***************
*** 80,86 ****
  %token <ival> CONST ID
  %token OPEN XCLOSE XCREATE INSERT_TUPLE
  %token STRING XDEFINE
! %token XDECLARE INDEX ON USING XBUILD INDICES
  %token COMMA EQUALS LPAREN RPAREN
  %token OBJ_ID XBOOTSTRAP NULLVAL
  %start TopLevel
--- 80,86 ----
  %token <ival> CONST ID
  %token OPEN XCLOSE XCREATE INSERT_TUPLE
  %token STRING XDEFINE
! %token XDECLARE INDEX ON USING XBUILD INDICES UNIQUE
  %token COMMA EQUALS LPAREN RPAREN
  %token OBJ_ID XBOOTSTRAP NULLVAL
  %start TopLevel
***************
*** 106,111 ****
--- 106,112 ----
  		| Boot_CreateStmt
  		| Boot_InsertStmt
  		| Boot_DeclareIndexStmt
+ 		| Boot_DeclareUniqueIndexStmt
  		| Boot_BuildIndsStmt
  		;

***************
*** 226,231 ****
--- 227,245 ----
  								LexIDStr($3),
  								LexIDStr($7),
  								$9, NIL, 0, 0, 0, NIL);
+ 					DO_END;
+ 				}
+ 		;
+
+ Boot_DeclareUniqueIndexStmt:
+ 		  XDECLARE UNIQUE INDEX boot_ident ON boot_ident USING boot_ident
LPAREN boot_index_params RPAREN
+ 				{
+ 					DO_START;
+
+ 					DefineIndex(LexIDStr($6),
+ 								LexIDStr($4),
+ 								LexIDStr($8),
+ 								$10, NIL, 1, 0, 0, NIL);
  					DO_END;
  				}
  		;
*** ../../head/pgcurrent/backend/catalog/genbki.sh.in	Mon Jul 26 12:44:44
1999
--- backend/catalog/genbki.sh.in	Tue Oct 26 22:03:43 1999
***************
*** 164,169 ****
--- 164,183 ----
  	print "declare index " data
  }

+ /^DECLARE_UNIQUE_INDEX\(/ {
+ # ----
+ #  end any prior catalog data insertions before starting a define unique
index
+ # ----
+ 	if (reln_open == 1) {
+ #		print "show";
+ 		print "close " catalog;
+ 		reln_open = 0;
+ 	}
+
+ 	data = substr($0, 22, length($0) - 22);
+ 	print "declare unique index " data
+ }
+
  /^BUILD_INDICES/	{ print "build indices"; }

  # ----------------
*** ../../head/pgcurrent/include/postgres.h	Mon Oct 25 22:13:13 1999
--- include/postgres.h	Tue Oct 26 21:45:27 1999
***************
*** 138,143 ****
--- 138,144 ----
  #define DATA(x) extern int errno
  #define DESCR(x) extern int errno
  #define DECLARE_INDEX(x) extern int errno
+ #define DECLARE_UNIQUE_INDEX(x) extern int errno

  #define BUILD_INDICES
  #define BOOTSTRAP
*** ../../head/pgcurrent/include/catalog/indexing.h	Mon Oct  4 14:25:34
1999
--- include/catalog/indexing.h	Tue Oct 26 21:47:24 1999
***************
*** 102,112 ****
  DECLARE_INDEX(pg_proc_oid_index on pg_proc using btree(oid oid_ops));
  DECLARE_INDEX(pg_proc_proname_narg_type_index on pg_proc using
btree(proname name_ops, pronargs int2_ops, proargtypes oid8_ops));

! DECLARE_INDEX(pg_type_oid_index on pg_type using btree(oid oid_ops));
! DECLARE_INDEX(pg_type_typname_index on pg_type using btree(typname
name_ops));

! DECLARE_INDEX(pg_class_oid_index on pg_class using btree(oid oid_ops));
! DECLARE_INDEX(pg_class_relname_index on pg_class using btree(relname
name_ops));

DECLARE_INDEX(pg_attrdef_adrelid_index on pg_attrdef using btree(adrelid
oid_ops));

--- 102,112 ----
  DECLARE_INDEX(pg_proc_oid_index on pg_proc using btree(oid oid_ops));
  DECLARE_INDEX(pg_proc_proname_narg_type_index on pg_proc using
btree(proname name_ops, pronargs int2_ops, proargtypes oid8_ops));

! DECLARE_UNIQUE_INDEX(pg_type_oid_index on pg_type using btree(oid
oid_ops));
! DECLARE_UNIQUE_INDEX(pg_type_typname_index on pg_type using btree(typname
name_ops));

! DECLARE_UNIQUE_INDEX(pg_class_oid_index on pg_class using btree(oid
oid_ops));
! DECLARE_UNIQUE_INDEX(pg_class_relname_index on pg_class using
btree(relname name_ops));

DECLARE_INDEX(pg_attrdef_adrelid_index on pg_attrdef using btree(adrelid
oid_ops));

From bouncefilter Wed Oct 27 06:51:07 1999
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 GAA43432
for <pgsql-hackers@postgreSQL.org>;
Wed, 27 Oct 1999 06:50:35 -0400 (EDT) (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 MAA06962
for <pgsql-hackers@postgreSQL.org>; Wed, 27 Oct 1999 12:37:44 +0200
Date: Wed, 27 Oct 1999 12:37:44 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Bug(?) in pg_get_ruledef()
Message-ID: <Pine.LNX.3.96.991027123327.6743A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

I try dump (via pg_dump) my database, but if I write dumped data back to DB,
views (as select on ingerit table) not work.

The bug is in routine pg_get_ruledef(pg_rewrite.rulename), which _not_
discern between select on standard table and select on inderit table.
Select on inherit table is "SELECT * FROM table*", but pg_get_ruledef()
return this view definition without asterisk: "SELECT * FROM table".

See example:
-----------
abil=> create table mother_tab (aaa int);
CREATE

abil=> create table son () inherits(mother_tab);
CREATE

abil=> create view v_mother as select * from mother_tab*;
CREATE

abil=> insert into son values (111);
INSERT 4946878 1

abil=> select * from v_mother;
aaa
---
111
(1 row)

abil=> SELECT pg_get_ruledef(pg_rewrite.rulename) FROM pg_rewrite WHERE
rulename ='_RETv_mother';
CREATE RULE "_RETv_mother" AS ON SELECT TO "v_mother" DO INSTEAD SELECT
"mother_tab"."aaa" FROM "mother_tab";
(1 row)
^^^^^^^^^^^^
right is "mother_tab*"

-----

Is it but?

(It is probably fatal bug if somebody backup batabase via pg_dump and views
from dump is unavailable.)

Karel Z.

------------------------------------------------------------------------------
<zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/

Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
------------------------------------------------------------------------------
...and cathedral dilapidate

From bouncefilter Wed Oct 27 07:04:10 1999
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 HAA45003
for <hackers@postgresql.org>; Wed, 27 Oct 1999 07:03:17 -0400 (EDT)
(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 11gQrG-0000of-0B
for hackers@postgreSQL.org; Wed, 27 Oct 1999 11:03:10 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id MAA24318; Wed, 27 Oct 1999 12:02:21 +0100 (BST)
Message-Id: <199910271102.MAA24318@mtcc.demon.co.uk>
Date: Wed, 27 Oct 1999 12:02:21 +0100 (BST)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Syntax error in psqlHelp.h
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: mXIStqdlDeyMt+3tgSJzeA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

There's a missing quote in psqlHelp.h in the latest CVS.

Here's a patch:-

*** src/bin/psql/psqlHelp.h.orig  Tue Oct 26 09:34:18 1999
--- src/bin/psql/psqlHelp.h    Wed Oct 27 11:54:25 1999
***************
*** 60,66 ****
    FUNCTION <func_name> (arg1, arg2, ...)|\n\
    OPERATOR <op> (leftoperand_type rightoperand_type) |\n\
    TRIGGER <trigger_name> ON <table_name>\n\
! ] IS 'text'},
        {"commit work",
                "commit a transaction",
        "\
--- 60,66 ----
    FUNCTION <func_name> (arg1, arg2, ...)|\n\
    OPERATOR <op> (leftoperand_type rightoperand_type) |\n\
    TRIGGER <trigger_name> ON <table_name>\n\
! ] IS 'text'"},
        {"commit work",
                "commit a transaction",
        "\

From bouncefilter Wed Oct 27 08:26:09 1999
Received: from hipernet.com.br (nautilus.hipernet.com.br [200.246.90.107])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA61266
for <pgsql-hackers@postgreSQL.org>;
Wed, 27 Oct 1999 08:25:54 -0400 (EDT)
(envelope-from roberto@mha.com.br)
Received: from pc35.mha.com.br ([200.245.167.61])
by hipernet.com.br (8.9.3/8.9.3) with SMTP id KAA17518
for <pgsql-hackers@postgreSQL.org>;
Wed, 27 Oct 1999 10:27:11 -0200 (EDT)
Message-Id: <3.0.5.32.19991027102057.008298f0@pop.hipernet.com.br>
X-Sender: roberto@pop.hipernet.com.br
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 27 Oct 1999 10:20:57 -0200
To: pgsql-hackers@postgreSQL.org
From: Roberto Joao Lopes Garcia <roberto@mha.com.br>
Subject: Re: [HACKERS] Error: shmget failed - SOLVED!
In-Reply-To: <199910261651.MAA26723@candle.pha.pa.us>
References: <23209.940954924@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hi

To change maximun Shared Memory segment size in my Sparc Solaris 2.5, I
have to add the following line into /etc/system file and then reboot the
system

set shmsys:shminfo_shmmax=268435456

It solved the problem.

Also, Solaris ANSWER BOOK recomends to change the follow. Please note that
I do not test the lines bellow in my system, only the above change in
/etc/system solved the problem.

set semsys:seminfo_semmap=250
set semsys:seminfo_semmni=500
set
semsys:seminfo_semmns=500
set semsys:seminfo_semmsl=500
set
semsys:seminfo_semmnu=500
set semsys:seminfo_semume=100
set
semsys:seminfo_shmmin=200
set semsys:seminfo_shmmni=200
set
semsys:seminfo_shmseg=200

To see the actual system sets one can use the command sysdef that, in my
system produce the follow:

#sysdef
.
.
. ...
*
* IPC Semaphores
*
10 entries in semaphore map (SEMMAP)
10
semaphore identifiers (SEMMNI)
60 semaphores in system (SEMMNS)
30
undo structures in system (SEMMNU)
25 max semaphores per id (SEMMSL)

10 max operations per semop call (SEMOPM)
10 max undo entries per
process (SEMUME)
32767 semaphore maximum value (SEMVMX)
16384 adjust on
exit max value (SEMAEM)
*
* IPC Shared Memory
*
268435456 max shared memory
segment size (SHMMAX)
1 min shared memory segment size (SHMMIN)
100
shared memory identifiers (SHMMNI)
6 max attached shm segments per
process (SHMSEG)
*
* Time Sharing Scheduler Tunables
*
60 maximum time
sharing user priority (TSMAXUPRI)
SYS system class name (SYS_NAME)
#

Please read the man pages before execute this command or the changes showed
above.

Thank you for you help

Roberto

At 12:51 26/10/99 -0400, you wrote:

Roberto Joao Lopes Garcia <roberto@mha.com.br> writes:

I tried to start postmaster and it report an error, see bellow:
IpcMemoryCreate: shmget failed (Invalid argument) key=5432001,
size=1073152, permission=600
FATAL 1: ShmemCreate: cannot create region

As a quick hack you can start the postmaster with smaller-than-
normal -B and -N (say -B 40 -N 20). Long term solution is to
increase your kernel's SHMMAX limit to more than 1 megabyte.

I thought we had adjusted the default -B and -N to stay just
under a meg, which is the default SHMMAX value on many kernels.
But it looks like someone chewed up some more shared memory when
I wasn't looking :-(.

7.0 backend will point them to FAQ on such errors.

-- 
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 Wed Oct 27 10:57:10 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA96205
for <pgsql-hackers@postgreSQL.org>;
Wed, 27 Oct 1999 10:56:49 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA25178;
Wed, 27 Oct 1999 10:55:49 -0400 (EDT)
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
In-reply-to: Your message of Tue, 26 Oct 1999 17:36:00 +0200 (MET DST)
<m11g8dk-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Wed, 27 Oct 1999 10:55:48 -0400
Message-ID: <25176.941036148@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

Also I miss the interface for tuple set returns. I know that
this requires much more in other sections than only the fmgr,
but we need to cover it now or we'll not be able to do it
without another change to the fmgr interface at the time we
want to support real stored procedures.

OK, I'm willing to worry about that. But what, exactly, needs to
be provided in the fmgr interface?

First we need another relation type in pg_class. It's like a
table or view, but none of the NORMAL SQL statements can be
used with it (e.g. INSERT, SELECT, ...). It just describes a
row structure.

Why bother? Just create a table --- if you don't want to put any
rows in it, you don't have to.

Of course, it requires some new fields in the rangetable
entry. Anyway, at the beginning of execution for such a
query, the executor initializes those RTE's by creating a
temptable with the schema of the specified structure or
relation. Then it calls the user function, passing in some
handle to the temp table and the user function fills in the
tuples. Now the rest of query execution is if it is a regular
table. After execution, the temp table is dropped.

OK, but this doesn't answer the immediate problem of what needs to
appear in the fmgr interface.

I have been thinking about this some, and I think maybe our best bet is
not to commit to *exactly* what needs to pass through fmgr, but rather
to put in a couple of generic hooks. I can see two hooks that are
needed: one is for passing "context" information, such as information
about the current trigger event when a function is called from the
trigger manager. (This'd replace the present CurrentTriggerData global,
which I hope you'll agree shouldn't be a global...) The other is for
passing and/or returning information about the function result --- maybe
returning a tuple descriptor, maybe passing in the name of a temp table
to put a result set in, maybe other stuff. So, I am thinking that we
should add two fields like this to the FunctionCallInfo struct:

Node *resultinfo; /* pass or return extra info about result */
Node *context; /* pass info about context of call */

We would restrict the usage of these fields only to the extent of saying
that they must point to some kind of Node --- that lets callers and
callees check the node tag to make sure that they understand what they
are looking at. Different node types can be used to handle different
situations. For an "ordinary" function call expecting a scalar return
value, both fields will be set to NULL. Other conventions for their use
will be developed as time goes on.

Does this look good to you, or am I off the track entirely?

regards, tom lane

From bouncefilter Wed Oct 27 11:31:12 1999
Received: from shaked.cc.openu.ac.il (shaked.cc.openu.ac.il [147.233.145.65])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA01994;
Wed, 27 Oct 1999 11:30:46 -0400 (EDT)
(envelope-from herouth@oumail.openu.ac.il)
Received: from [147.233.159.109] (herouth@mac-herouth.pc.openu.ac.il
[147.233.159.109])
by shaked.cc.openu.ac.il (8.8.8/8.8.8) with ESMTP id RAA25536;
Wed, 27 Oct 1999 17:30:19 +0200 (IST)
X-Sender: herouth@shaked.cc.openu.ac.il
Message-Id: <l03130300b43cca53b4fa@[147.233.159.109]>
In-Reply-To: <38134E6A.171B9A6A@southeast.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 27 Oct 1999 17:30:16 +0200
To: Tim Holloway <mtsinc@southeast.net>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>,
pgsql-admin <pgsql-admin@postgreSQL.org>
From: Herouth Maoz <herouth@oumail.openu.ac.il>
Subject: Re: [ADMIN] Logging - events supported

At 20:22 +0200 on 24/10/1999, Tim Holloway wrote:

show commands
Session ID, command text
301 - SELECT text
302 - INSERT text
303 - UPDATE text
304 - DELETE text

FWIW, don't forget CREATE, ALTER, DROP - DDL items in general. Nor COPY in
and out, perhaps SET.

Herouth

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma

From bouncefilter Wed Oct 27 12:10:11 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA07864
for <hackers@postgresql.org>; Wed, 27 Oct 1999 12:09:49 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:1950 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s3mCx133448>;
Wed, 27 Oct 1999 18:09:33 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2) id 11gVhA-0000h5-00
for hackers@postgresql.org; Wed, 27 Oct 1999 18:13:04 +0200
Date: Wed, 27 Oct 1999 18:13:04 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: psql Week 4.142857
Message-ID: <Pine.LNX.4.10.9910271759001.2314-100000@peter-e.yi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Peter Eisentraut <peter@peter-e.yi.org>

Oops, the stuff I posted yesterday contained a few pretty funky bugs. I
have put up a new tarball.

Also, I have written updated DocBook documentation. It's not a great work
of literature yet but it's for those that want to get started. I will
update it several times during the next few days.

Again, those URLs are:
http://www.pathwaynet.com/~peter/psql-final.tar.gz (49k)
http://www.pathwaynet.com/~peter/psql-ref.sgml.gz (16k)

And for those who don't want to rebuild the whole documentation:
http://www.pathwaynet.com/~peter/psql-ref.html

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

From bouncefilter Wed Oct 27 12:31:13 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA11387
for <pgsql-hackers@postgreSQL.org>;
Wed, 27 Oct 1999 12:31:03 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA06828;
Wed, 27 Oct 1999 12:28:39 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910271628.MAA06828@candle.pha.pa.us>
Subject: Re: System indexes are never unique indexes( was RE: [HACKERS]
mdnblocksis
In-Reply-To: <000401bf2060$0d08e820$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Oct 27, 1999 06:45:49 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Wed, 27 Oct 1999 12:28:39 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Anyway,I want to change the implementation of mdcreate() to reuse
existent files but the uniqueness of table name is preserved by the
current implementation narrowly.

First of all,I would change pg_type,pg_class.
It's OK ?

Sure.

I made a patch.
But I'm not sure my solution is right.
Is there a better way ?

Looks perfect to me.

-- 
  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 Wed Oct 27 12:31:21 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA11378
for <hackers@postgreSQL.org>; Wed, 27 Oct 1999 12:30:58 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA07040;
Wed, 27 Oct 1999 12:30:07 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910271630.MAA07040@candle.pha.pa.us>
Subject: Re: [HACKERS] Syntax error in psqlHelp.h
In-Reply-To: <199910271102.MAA24318@mtcc.demon.co.uk> from Keith Parks at "Oct
27, 1999 12:02:21 pm"
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Date: Wed, 27 Oct 1999 12:30:07 -0400 (EDT)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied. Thanks. That was my bug.

There's a missing quote in psqlHelp.h in the latest CVS.

Here's a patch:-

*** src/bin/psql/psqlHelp.h.orig  Tue Oct 26 09:34:18 1999
--- src/bin/psql/psqlHelp.h    Wed Oct 27 11:54:25 1999
***************
*** 60,66 ****
FUNCTION <func_name> (arg1, arg2, ...)|\n\
OPERATOR <op> (leftoperand_type rightoperand_type) |\n\
TRIGGER <trigger_name> ON <table_name>\n\
! ] IS 'text'},
{"commit work",
"commit a transaction",
"\
--- 60,66 ----
FUNCTION <func_name> (arg1, arg2, ...)|\n\
OPERATOR <op> (leftoperand_type rightoperand_type) |\n\
TRIGGER <trigger_name> ON <table_name>\n\
! ] IS 'text'"},
{"commit work",
"commit a transaction",
"\

************

-- 
  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 Wed Oct 27 13:21:12 1999
Received: from shaked.cc.openu.ac.il (shaked.cc.openu.ac.il [147.233.145.65])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA18519
for <pgsql-general@postgreSQL.org>;
Wed, 27 Oct 1999 13:21:10 -0400 (EDT)
(envelope-from herouth@oumail.openu.ac.il)
Received: from [147.233.159.109] (herouth@mac-herouth.pc.openu.ac.il
[147.233.159.109])
by shaked.cc.openu.ac.il (8.8.8/8.8.8) with ESMTP id TAA27960
for <pgsql-general@postgreSQL.org>;
Wed, 27 Oct 1999 19:21:07 +0200 (IST)
X-Sender: herouth@shaked.cc.openu.ac.il
Message-Id: <l03130302b43ce49ae1ea@[147.233.159.109]>
In-Reply-To: <20506.940604881@sss.pgh.pa.us>
References: Your message of Fri, 22 Oct 1999 02:04:09 -0400 (EDT)
<199910220604.CAA28175@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 27 Oct 1999 19:21:03 +0200
To: pgsql-general@postgreSQL.org
From: Herouth Maoz <herouth@oumail.openu.ac.il>
Subject: Re: [HACKERS] Re: [GENERAL] Postgres INSERTs much slower than MySQL?

At 17:08 +0200 on 22/10/1999, Tom Lane wrote:

In the meantime, the conventional wisdom is still that you should use
COPY, if possible, for bulk data loading. (If you need default values
inserted in some columns then this won't do...)

Yes it would - in two steps. COPY to a temp table that only has the
non-default columns. Then INSERT ... SELECT ... from that temp table to
your "real" table.

Herouth

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma

From bouncefilter Wed Oct 27 13:57:12 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id NAA28768
for <pgsql-hackers@postgreSQL.org>;
Wed, 27 Oct 1999 13:56:15 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11gXFb-0003kLC; Wed, 27 Oct 99 19:52 MET DST
Message-Id: <m11gXFb-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Wed, 27 Oct 1999 19:52:43 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <25176.941036148@sss.pgh.pa.us> from "Tom Lane" at Oct 27,
99 10:55:48 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Node *resultinfo; /* pass or return extra info about result */
Node *context; /* pass info about context of call */

Does this look good to you, or am I off the track entirely?

regards, tom lane

Looks perfect. I appreciate to get rid of globals whenever
possible.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

From bouncefilter Wed Oct 27 14:26:17 1999
Received: from loopy.berkhirt.com (loopy.berkhirt.com [209.220.85.54])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA33096
for <pgsql-hackers@postgresql.org>;
Wed, 27 Oct 1999 14:25:48 -0400 (EDT)
(envelope-from bhirt@loopy.berkhirt.com)
Received: (from bhirt@localhost)
by loopy.berkhirt.com (8.9.3/8.8.7) id OAA13904;
Wed, 27 Oct 1999 14:25:18 -0400
Date: Wed, 27 Oct 1999 14:25:18 -0400
From: Brian Hirt <bhirt@mobygames.com>
To: pgsql-hackers@postgreSQL.org
Cc: bhirt@loopy.berkhirt.com
Subject: text datatype and tuple size limits.
Message-ID: <19991027142518.A13571@loopy.berkhirt.com>
Reply-To: bhirt@mobygames.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
X-PC-Gaming: http://www.mobygames.com/

Hello,

I'm running into what appears to be some hard coded limits of postgres.
I've got a table with with a text column that I need to insert large
amounts of text into. I quickly found these two things out:

First, the MAX_QUERY_SIZE which is BLCKSZ*2 (or 16384 bytes), prevents
me from from running the query since my query is much larger than 16384 i
bytes. After discovering this, I decided to create a test query just
smaller than 16384 to see what would happen.

The second query returns "Tuple is too big: size 12508". I didn't bother
to look into this one because I'd probably spend a lot of time looking,
instead I am bringing the issue here.

I haven't done any development work on postgres and don't want
to get involved in doing so before discussing it here and making sure that
my efforts won't be in vain. Without looking at the code, I expect this
problem is not *simple* to fix. I'm operating on the assumption that
tuple sizes cannot be changed very easily. Even if they could, a bigger
problem is probably the MAX_QUERY_SIZE. Simply increasing the MAX_QUERY_SIZE
will only address a short term problem, and there is a practicle limit
to the size it can be increased. Idealy, some sort of dynamic query buffer
would be better but that likely challanges the way the communication
between the client and server works.

So, has anyone looked into this limitation? Is it something that the
development team wants to be addressed? If this is a know problem, is
there some sort of agreement on how it should be solved? If so, is
someone working on it? If not, possible I could help.

Over the last 9 months, I've been using postgres more and more. It's gotten
to the point where our project is becoming quite dependent on it. I am
quite happy with the software and want to stick with it. I've run into
several minor things this year that I have been able to avoid, but this
one may be a show stopper. Rather than ditch this fine software, I'd
rather help out if the help is wanted and I am capible of giving it the
time required.

More details on the problem I am having:
Redhat 6.0 / x86
Postgres 6.5.1
Inserts tried with psql and libpg via Perl DBD/DBI

-Brian

From bouncefilter Wed Oct 27 16:44:14 1999
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net
[194.217.242.38]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA69315
for <hackers@postgresql.org>; Wed, 27 Oct 1999 16:43:46 -0400 (EDT)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
id 11gZv2-000HyI-0A; Wed, 27 Oct 1999 20:43:40 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id VAA04646; Wed, 27 Oct 1999 21:43:34 +0100 (BST)
Message-Id: <199910272043.VAA04646@mtcc.demon.co.uk>
Date: Wed, 27 Oct 1999 21:43:34 +0100 (BST)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] Syntax error in psqlHelp.h
To: emkxp01@mtcc.demon.co.uk, maillist@candle.pha.pa.us
Cc: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 4xNEQxLJllW79j5Qir40UQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

It was a good one, the compiler threw out an error for
a line about 100 lines further down the file that made
no sense whatsoever to me!!

Bruce Momjian <maillist@candle.pha.pa.us>

Applied. Thanks. That was my bug.

There's a missing quote in psqlHelp.h in the latest CVS.

Here's a patch:-

*** src/bin/psql/psqlHelp.h.orig  Tue Oct 26 09:34:18 1999
--- src/bin/psql/psqlHelp.h    Wed Oct 27 11:54:25 1999
***************
*** 60,66 ****
FUNCTION <func_name> (arg1, arg2, ...)|\n\
OPERATOR <op> (leftoperand_type rightoperand_type) |\n\
TRIGGER <trigger_name> ON <table_name>\n\
! ] IS 'text'},
{"commit work",
"commit a transaction",
"\
--- 60,66 ----
FUNCTION <func_name> (arg1, arg2, ...)|\n\
OPERATOR <op> (leftoperand_type rightoperand_type) |\n\
TRIGGER <trigger_name> ON <table_name>\n\
! ] IS 'text'"},
{"commit work",
"commit a transaction",
"\

************

-- 
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 Wed Oct 27 17:04:14 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA89263
for <hackers@postgreSQL.org>; Wed, 27 Oct 1999 17:03:46 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA18298;
Wed, 27 Oct 1999 17:03:18 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910272103.RAA18298@candle.pha.pa.us>
Subject: Re: [HACKERS] Syntax error in psqlHelp.h
In-Reply-To: <199910272043.VAA04646@mtcc.demon.co.uk> from Keith Parks at "Oct
27, 1999 09:43:34 pm"
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Date: Wed, 27 Oct 1999 17:03:17 -0400 (EDT)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

It was a good one, the compiler threw out an error for
a line about 100 lines further down the file that made
no sense whatsoever to me!!

I should always recompile before cvs commit, but I am often too busy.

-- 
  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 Wed Oct 27 17:04:15 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA89277
for <hackers@postgreSQL.org>; Wed, 27 Oct 1999 17:04:04 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA18346;
Wed, 27 Oct 1999 17:03:37 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910272103.RAA18346@candle.pha.pa.us>
Subject: Re: [HACKERS] psql Week 4.142857
In-Reply-To: <Pine.LNX.4.10.9910271759001.2314-100000@peter-e.yi.org> from
Peter Eisentraut at "Oct 27, 1999 06:13:04 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Wed, 27 Oct 1999 17:03:37 -0400 (EDT)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Let me know when you want these applied to the main tree.

Oops, the stuff I posted yesterday contained a few pretty funky bugs. I
have put up a new tarball.

Also, I have written updated DocBook documentation. It's not a great work
of literature yet but it's for those that want to get started. I will
update it several times during the next few days.

Again, those URLs are:
http://www.pathwaynet.com/~peter/psql-final.tar.gz (49k)
http://www.pathwaynet.com/~peter/psql-ref.sgml.gz (16k)

And for those who don't want to rebuild the whole documentation:
http://www.pathwaynet.com/~peter/psql-ref.html

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

************

-- 
  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 Wed Oct 27 18:02:15 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA96294;
Wed, 27 Oct 1999 18:01:32 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA20320;
Wed, 27 Oct 1999 17:39:30 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910272139.RAA20320@candle.pha.pa.us>
Subject: 6.5.3
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Wed, 27 Oct 1999 17:39:30 -0400 (EDT)
CC: "Marc G. Fournier" <scrappy@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

When are we packaging 6.5.3 with the pgaccess addition?

-- 
  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 Wed Oct 27 19:12:15 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA05386
for <pgsql-hackers@postgresql.org>;
Wed, 27 Oct 1999 19:12:11 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id IAA05055; Thu, 28 Oct 1999 08:11:18 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <maillist@candle.pha.pa.us>
Cc: <pgsql-hackers@postgresql.org>
Subject: RE: System indexes are never unique indexes( was RE: [HACKERS]
mdnblocksis
Date: Thu, 28 Oct 1999 08:15:25 +0900
Message-ID: <000101bf20d1$26bdf460$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <199910271628.MAA06828@candle.pha.pa.us>
Importance: Normal

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Anyway,I want to change the implementation of mdcreate() to reuse
existent files but the uniqueness of table name is preserved by the
current implementation narrowly.

First of all,I would change pg_type,pg_class.
It's OK ?

Sure.

I made a patch.
But I'm not sure my solution is right.
Is there a better way ?

Looks perfect to me.

Thanks.
I would commit it with some other changes.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Oct 27 20:31:17 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA20096
for <pgsql-hackers@postgresql.org>;
Wed, 27 Oct 1999 20:31:00 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id UAA27882;
Wed, 27 Oct 1999 20:06:03 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910280006.UAA27882@candle.pha.pa.us>
Subject: Re: System indexes are never unique indexes( was RE: [HACKERS]
mdnblocksis
In-Reply-To: <000101bf20d1$26bdf460$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Oct 28, 1999 08:15:25 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Wed, 27 Oct 1999 20:06:03 -0400 (EDT)
CC: pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Looks perfect to me.

Thanks.
I would commit it with some other changes.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

I want to add some system indexes to cache lookups are faster, but am
having problems with the bootup code. Let me know if you are interested
in looking at 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 19026

From bouncefilter Wed Oct 27 21:07:17 1999
Received: from ext04.sra.co.jp (IDENT:root@ykh28DS46.kng.mesh.ad.jp
[133.205.214.46]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA24152
for <pgsql-hackers@postgreSQL.org>;
Wed, 27 Oct 1999 21:07:01 -0400 (EDT)
(envelope-from t-ishii@ext04.sra.co.jp)
Received: from ext04.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext04.sra.co.jp (8.8.8/8.8.8) with ESMTP id KAA01776
for <pgsql-hackers@postgreSQL.org>; Thu, 28 Oct 1999 10:06:53 +0900
Message-Id: <199910280106.KAA01776@ext04.sra.co.jp>
From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: pgsql-hackers@postgreSQL.org
Subject: PostgreSQL book translation
Date: Thu, 28 Oct 1999 10:06:53 +0900
Sender: t-ishii@ext04.sra.co.jp

Bruce,

We (PostgreSQL users in Japan) have formed a non-profit,
non-commercial PostgreSQL user's group, called JPUG (Japan PostgreSQL
User's Group) this July. We have over 240 members now. You can visit
our web page at http://www.jp.postgresql.org/ (all contents are
written in Japanese).

What we are thinking about is translating your PostgreSQL book into
Japanese. We want not only the result be published from an appropriate
publisher, but also the whole contents could be viewed by anyone on the
Internet as well. I'm not sure this would conflict with the contract
you have made with your publisher though.

How do you think?
---
Tatsuo Ishii

From bouncefilter Wed Oct 27 21:08:17 1999
Received: from ext04.sra.co.jp (IDENT:root@ykh28DS46.kng.mesh.ad.jp
[133.205.214.46]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA24226
for <hackers@postgreSQL.org>; Wed, 27 Oct 1999 21:07:42 -0400 (EDT)
(envelope-from t-ishii@ext04.sra.co.jp)
Received: from ext04.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext04.sra.co.jp (8.8.8/8.8.8) with ESMTP id KAA01785;
Thu, 28 Oct 1999 10:07:16 +0900
Message-Id: <199910280107.KAA01785@ext04.sra.co.jp>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, hackers@postgreSQL.org
Subject: Re: [HACKERS] psql Week 4.142857
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Wed, 27 Oct 1999 17:03:37 -0400.
<199910272103.RAA18346@candle.pha.pa.us>
Date: Thu, 28 Oct 1999 10:07:16 +0900
Sender: t-ishii@ext04.sra.co.jp

Let me know when you want these applied to the main tree.

Does his work replace psql? Or will it be placed under contrib/?
I just want to know how 7.0 would be look like.
---
Tatsuo Ishii

From bouncefilter Wed Oct 27 21:46:17 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA28946
for <pgsql-hackers@postgreSQL.org>;
Wed, 27 Oct 1999 21:45:40 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id VAA29841;
Wed, 27 Oct 1999 21:38:11 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910280138.VAA29841@candle.pha.pa.us>
Subject: Re: [HACKERS] PostgreSQL book translation
In-Reply-To: <199910280106.KAA01776@ext04.sra.co.jp> from Tatsuo Ishii at "Oct
28, 1999 10:06:53 am"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Wed, 27 Oct 1999 21:38:11 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org, paul.becker@awl.com
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce,

We (PostgreSQL users in Japan) have formed a non-profit,
non-commercial PostgreSQL user's group, called JPUG (Japan PostgreSQL
User's Group) this July. We have over 240 members now. You can visit
our web page at http://www.jp.postgresql.org/ (all contents are
written in Japanese).

Sure. Addison, Wesley has the foreign publishing rights. I am CC'ing
my publisher contact on this. You can reach him directly. This
publisher has extensive experience with foreign publishing.

What we are thinking about is translating your PostgreSQL book into
Japanese. We want not only the result be published from an appropriate
publisher, but also the whole contents could be viewed by anyone on the
Internet as well. I'm not sure this would conflict with the contract
you have made with your publisher though.

As you know, the book is on the Internet now, and will remain there
after I complete 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 19026

From bouncefilter Wed Oct 27 21:46:17 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA28939
for <hackers@postgreSQL.org>; Wed, 27 Oct 1999 21:45:33 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id VAA29846;
Wed, 27 Oct 1999 21:38:42 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910280138.VAA29846@candle.pha.pa.us>
Subject: Re: [HACKERS] psql Week 4.142857
In-Reply-To: <199910280107.KAA01785@ext04.sra.co.jp> from Tatsuo Ishii at "Oct
28, 1999 10:07:16 am"
To: t-ishii@sra.co.jp
Date: Wed, 27 Oct 1999 21:38:42 -0400 (EDT)
CC: Peter Eisentraut <peter_e@gmx.net>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Let me know when you want these applied to the main tree.

Does his work replace psql? Or will it be placed under contrib/?
I just want to know how 7.0 would be look like.

This is going into the main tree. psql will still be there, but will be
improved.

-- 
  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 Thu Oct 28 01:44:22 1999
Received: from mail.evergreen.com (mail.evergreen.com [168.158.8.171])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA59192
for <pgsql-hackers@postgresql.org>;
Thu, 28 Oct 1999 01:43:46 -0400 (EDT)
(envelope-from troy@evergreen.com)
Received: from tatooine.evergreen.com (tatooine.evergreen.com [168.158.7.72])
by mail.evergreen.com (8.9.3/8.9.3) with ESMTP id WAA16156
for <pgsql-hackers@postgresql.org>; Wed, 27 Oct 1999 22:43:38 -0700
Received: from evergreen.com (localhost [127.0.0.1])
by tatooine.evergreen.com (8.8.8+Sun/8.8.8) with ESMTP id WAA02470
for <pgsql-hackers@postgresql.org>;
Wed, 27 Oct 1999 22:33:59 -0700 (MST)
Sender: troy@tatooine.evergreen.com
Message-ID: <3817E047.B3745FA2@evergreen.com>
Date: Wed, 27 Oct 1999 22:33:59 -0700
From: Troy Griffitts <troy@evergreen.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: BLOB fields / JDBC
Content-Type: multipart/mixed; boundary="------------FF09C90F2B3A73CE14E21649"

This is a multi-part message in MIME format.
--------------FF09C90F2B3A73CE14E21649
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Is anyone working on support for BLOB fields and corresponding JDBC:
PreparedStatement.setBinaryStream

I would be willing to contribute in this area.

-Troy A. Griffitts
--------------FF09C90F2B3A73CE14E21649
Content-Type: text/x-vcard; charset=us-ascii;
name="troy.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Troy Griffitts
Content-Disposition: attachment;
filename="troy.vcf"

begin:vcard
n:Griffitts;Troy A.
tel;cell:(602) 628-7771
tel;fax:(480) 926-8939
tel;work:(480) 926-4500 Ext. 212
x-mozilla-html:FALSE
url:http://www.ecential.com
org:Evergreen Internet, Inc.;Java Development Team
adr:;;3260 North Colorado St.;Chandler;AZ;85225;US
version:2.1
email;internet:troy@evergreen.com
title:Sr. Software Architech / Engineer
x-mozilla-cpt:;0
fn:Troy A. Griffitts
end:vcard

--------------FF09C90F2B3A73CE14E21649--

From bouncefilter Thu Oct 28 03:44:21 1999
Received: from mail.evergreen.com (mail.evergreen.com [168.158.8.171])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA78408
for <pgsql-hackers@postgresql.org>;
Thu, 28 Oct 1999 03:44:20 -0400 (EDT)
(envelope-from troy@evergreen.com)
Received: from tatooine.evergreen.com (tatooine.evergreen.com [168.158.7.72])
by mail.evergreen.com (8.9.3/8.9.3) with ESMTP id AAA17335
for <pgsql-hackers@postgresql.org>; Thu, 28 Oct 1999 00:44:12 -0700
Received: from evergreen.com (localhost [127.0.0.1])
by tatooine.evergreen.com (8.8.8+Sun/8.8.8) with ESMTP id AAA02490
for <pgsql-hackers@postgresql.org>;
Thu, 28 Oct 1999 00:34:32 -0700 (MST)
Sender: troy@tatooine.evergreen.com
Message-ID: <3817FC88.EEDFAB1D@evergreen.com>
Date: Thu, 28 Oct 1999 00:34:32 -0700
From: Troy Griffitts <troy@evergreen.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: BLOB fields / JDBC
Content-Type: multipart/mixed; boundary="------------AF6D7A25E128274CCCB3A33B"

This is a multi-part message in MIME format.
--------------AF6D7A25E128274CCCB3A33B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Is anyone working on support for BLOB fields and corresponding JDBC:
PreparedStatement.setBinaryStream

I would be willing to contribute in this area.

-Troy A. Griffitts
--------------AF6D7A25E128274CCCB3A33B
Content-Type: text/x-vcard; charset=us-ascii;
name="troy.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Troy Griffitts
Content-Disposition: attachment;
filename="troy.vcf"

begin:vcard
n:Griffitts;Troy A.
tel;cell:(602) 628-7771
tel;fax:(480) 926-8939
tel;work:(480) 926-4500 Ext. 212
x-mozilla-html:FALSE
url:http://www.ecential.com
org:Evergreen Internet, Inc.;Java Development Team
adr:;;3260 North Colorado St.;Chandler;AZ;85225;US
version:2.1
email;internet:troy@evergreen.com
title:Sr. Software Architech / Engineer
x-mozilla-cpt:;0
fn:Troy A. Griffitts
end:vcard

--------------AF6D7A25E128274CCCB3A33B--

From bouncefilter Thu Oct 28 03:52:21 1999
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 DAA79749
for <pgsql-hackers@postgresql.org>;
Thu, 28 Oct 1999 03:51:43 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11gkLW-000CZL-0K; Thu, 28 Oct 1999 07:51:42 +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 KAA23847;
Thu, 28 Oct 1999 10:03:06 +0100
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <T6GA5NL3>; Thu, 28 Oct 1999 08:49:24 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E791@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Troy Griffitts'" <troy@evergreen.com>, pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] BLOB fields / JDBC
Date: Thu, 28 Oct 1999 08:49:14 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

Yes. I'm aiming to get BLOB & Array support completed for the next
release (7.0?).

Currently using standard JDBC, setBytes() and getBytes() handle BLOBS.
Obviously theres the LargeObject and LargeObjectManager classes as well.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Troy Griffitts [mailto:troy@evergreen.com]
Sent: 28 October 1999 08:35
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] BLOB fields / JDBC

Is anyone working on support for BLOB fields and corresponding JDBC:
PreparedStatement.setBinaryStream

I would be willing to contribute in this area.

-Troy A. Griffitts