Re: Linux/Postgres 6.5 problems using jdbc w/jdk1.2

I am having the same problem. I tried the new URL. The problem still
continues. Is there a chance I still need to do a make to create the
posgresql.jar file. I have installed the postgresql rpm's for
posdtgres6.5/. Any Ideas on how to do the make in postgresql 6.5

Ednut

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!

I am having the same problem. I tried the new URL. The problem still
continues. Is there a chance I still need to do a make to create the
posgresql.jar file. I have installed the postgresql rpm's for
posdtgres6.5/. Any Ideas on how to do the make in postgresql 6.5

Ednut
In article <37CE76CC.C341A8EE@netscape.net>, Christian Denning
<ChristianDenning@netscape.net> wrote:

This is a multi-part message in MIME format.
--------------E9628914BE19B20C6DA63E7C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Your database url is wrong. A postgres database needs the
following URL:
jdbc:postgresql://theComputerName/thePostgresDatabaseName
if you omit something, you get your NullPointerException
Christian
EA wrote:

Here are the errors I get while running the example classes

provided by

Postgres:

1. Without Debug
<---------------------------------------------------
PostgreSQL basic test v6.3 rev 1

Connecting to Database URL = jdbc:postgresql:db1
Exception caught.
Something unusual has occured to cause the driver to fail.

Please report

this exception: {1}
Something unusual has occured to cause the driver to fail.

Please report

this exception: {1}
at postgresql.Driver.connect(Compiled Code)
at java.sql.DriverManager.getConnection(Compiled Code)
at java.sql.DriverManager.getConnection(Compiled Code)
at example.basic.<init>(Compiled Code)
at example.basic.main(Compiled Code)
<-----------------------------------------------------
2. With Debug
<---------------------------------------------------
PostgreSQL basic test v6.3 rev 1

DriverManager.initialize: jdbc.drivers = null
JDBC DriverManager initialized
registerDriver:
driver[className=postgresql.Driver,postgresql.Driver@a574f633]
Connecting to Database URL = jdbc:postgresql:web
DriverManager.getConnection("jdbc:postgresql:db1")
trying

driver[className=postgresql.Driver,postgresql.Driver@a574f633]

-- listing properties --
password=start123
user=db1
PGDBNAME=db1
Protocol=postgresql
Using postgresql.jdbc2.Connection
Exception caught.
java.lang.NullPointerException
java.lang.NullPointerException
at java.io.Writer.write(Compiled Code)
at java.io.PrintStream.write(Compiled Code)
at java.io.PrintStream.print(Compiled Code)
at java.io.PrintStream.println(Compiled Code)
at java.lang.Throwable.printStackTrace(Compiled Code)
at java.sql.SQLException.<init>(Compiled Code)
at postgresql.util.PSQLException.<init>(Compiled Code)
at postgresql.Driver.connect(Compiled Code)
at java.sql.DriverManager.getConnection(Compiled Code)
at java.sql.DriverManager.getConnection(Compiled Code)
at example.basic.<init>(Compiled Code)
at example.basic.main(Compiled Code)

<-----------------------------------------------------

Anyone recognize these errors.

--------------E9628914BE19B20C6DA63E7C
Content-Type: text/x-vcard; charset=us-ascii;
name="ChristianDenning.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Christian Denning
Content-Disposition: attachment;
filename="ChristianDenning.vcf"
begin:vcard
n:Denning;Christian
tel;cell:+44-7970-008855
tel;fax:+44-1225-484944
tel;home:+44-1453-836652
tel;work:+44-1225-484449
x-mozilla-html:FALSE
url:http://iecl.iuscomp.org/cd
org:e-net Software
version:2.1
email;internet:ChristianDenning@netscape.net
title:Software Development Manager
adr;quoted-printable:;;Shear's
Cottage=0D=0AWatledge;Nailsworth;Gloucestershire;GL6 0AR;United
Kingdom
x-mozilla-cpt:;-26992
fn:Christian Denning
end:vcard
--------------E9628914BE19B20C6DA63E7C--

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!

From bouncefilter Thu Oct 28 06:18:23 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 GAA00267
for <pgsql-hackers@postgreSQL.org>;
Thu, 28 Oct 1999 06:17:28 -0400 (EDT)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Puma.DoCS.UU.SE (e99re41@Puma.DoCS.UU.SE [130.238.9.112]) by
Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id MAA12910;
Thu, 28 Oct 1999 12:17:03 +0200
Received: from localhost (e99re41@localhost) by Puma.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA00594;
Thu, 28 Oct 1999 12:17:02 +0200
X-Authentication-Warning: Puma.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 28 Oct 1999 12:17:01 +0200 (MET DST)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Brian Hirt <bhirt@mobygames.com>
cc: pgsql-hackers@postgreSQL.org, bhirt@loopy.berkhirt.com
Subject: Re: [HACKERS] text datatype and tuple size limits.
In-Reply-To: <19991027142518.A13571@loopy.berkhirt.com>
Message-ID: <Pine.GSO.4.02A.9910281214130.567-100000@Puma.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

As far as I could follow it, the query size limit is all but gone, and it
will be for sure in 7.0. Regarding the tuple size limit, we are still
looking for volunteers to tackle that. You should find relevant messages
on this list a few days back.

-Peter

On Wed, 27 Oct 1999, Brian Hirt wrote:

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.

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

From bouncefilter Thu Oct 28 08:59:25 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 IAA20754
for <hackers@postgreSQL.org>; Thu, 28 Oct 1999 08:58:23 -0400 (EDT)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Pingvin.DoCS.UU.SE (e99re41@Pingvin.DoCS.UU.SE [130.238.9.118])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id OAA22833;
Thu, 28 Oct 1999 14:58:18 +0200
Received: from localhost (e99re41@localhost) by Pingvin.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id OAA27656;
Thu, 28 Oct 1999 14:58:15 +0200
X-Authentication-Warning: Pingvin.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 28 Oct 1999 14:58:14 +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: hackers@postgreSQL.org
Subject: Re: [HACKERS] psql Week 4.142857
In-Reply-To: <199910272103.RAA18346@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.9910281451010.25778-100000@Pingvin.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 27 Oct 1999, Bruce Momjian wrote:

Let me know when you want these applied to the main tree.

(At the risk of turning this into a C mailing list . . .)

As soon as I have this problem fixed:

gcc -o psql -L../../interfaces/libpq command.o common.o help.o input.o
stringutils.o mainloop.o copy.o startup.o prompt.o variables.o large_obj.o
print.o describe.o -lpq -L/usr/sup/gnu/lib -lgen -lcrypt -lnsl -lsocket
-ldl -lm -lreadline -ltermcap -lcurses
ld: fatal: symbol `xmalloc' is multiply defined:
(file common.o and file /usr/sup/gnu/lib/libreadline.a(xmalloc.o));
ld: fatal: File processing errors. No output written to psql
make: *** [psql] Error 1

This happens on a (particular) Solaris box but not on a (particular) Linux
box. Beats the heck out of me. ;(

Sorry for OT.

-Peter

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

From bouncefilter Thu Oct 28 11:01:26 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA39143
for <hackers@postgreSQL.org>; Thu, 28 Oct 1999 11:01:17 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by trends.net (8.8.8/8.8.8) with ESMTP id LAA01842
for <hackers@postgreSQL.org>; Thu, 28 Oct 1999 11:01:15 -0400 (EDT)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id KAA17756;
Thu, 28 Oct 1999 10:57:06 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910281457.KAA17756@candle.pha.pa.us>
Subject: Re: [HACKERS] psql Week 4.142857
In-Reply-To: <Pine.GSO.4.02A.9910281451010.25778-100000@Pingvin.DoCS.UU.SE>
from Peter Eisentraut at "Oct 28, 1999 02:58:14 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 28 Oct 1999 10:57:06 -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

On Wed, 27 Oct 1999, Bruce Momjian wrote:

Let me know when you want these applied to the main tree.

(At the risk of turning this into a C mailing list . . .)

As soon as I have this problem fixed:

gcc -o psql -L../../interfaces/libpq command.o common.o help.o input.o
stringutils.o mainloop.o copy.o startup.o prompt.o variables.o large_obj.o
print.o describe.o -lpq -L/usr/sup/gnu/lib -lgen -lcrypt -lnsl -lsocket
-ldl -lm -lreadline -ltermcap -lcurses
ld: fatal: symbol `xmalloc' is multiply defined:
(file common.o and file /usr/sup/gnu/lib/libreadline.a(xmalloc.o));
ld: fatal: File processing errors. No output written to psql
make: *** [psql] Error 1

This happens on a (particular) Solaris box but not on a (particular) Linux
box. Beats the heck out of me. ;(

I can't find xmalloc in the source, and can't figure out how it could be
_defined_ in common.o. Strange.

-- 
  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 12:44: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 MAA70832
for <hackers@postgresql.org>; Thu, 28 Oct 1999 12:43:37 -0400 (EDT)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:2930 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s45oY123229>;
Thu, 28 Oct 1999 18:43:16 +0200
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11gshD-0004fs-00; Thu, 28 Oct 1999 18:46:39 +0200
Date: Thu, 28 Oct 1999 18:46:39 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] psql Week 4.142857
In-Reply-To: <199910281457.KAA17756@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.9910281841220.17464-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 28, Bruce Momjian mentioned:

gcc -o psql -L../../interfaces/libpq command.o common.o help.o input.o
stringutils.o mainloop.o copy.o startup.o prompt.o variables.o large_obj.o
print.o describe.o -lpq -L/usr/sup/gnu/lib -lgen -lcrypt -lnsl -lsocket
-ldl -lm -lreadline -ltermcap -lcurses
ld: fatal: symbol `xmalloc' is multiply defined:
(file common.o and file /usr/sup/gnu/lib/libreadline.a(xmalloc.o));
ld: fatal: File processing errors. No output written to psql
make: *** [psql] Error 1

This happens on a (particular) Solaris box but not on a (particular) Linux
box. Beats the heck out of me. ;(

I can't find xmalloc in the source, and can't figure out how it could be
_defined_ in common.o. Strange.

Oh, I defined it in that file, it's used in psql. Unfortunately, it seems
to be used internally in readline as well. In now figured out that this
causes problems only with static linking, but not dynamic. I'm no expert
on linking, does anyone have an idea or do I have to make up a different
name?

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

From bouncefilter Thu Oct 28 15:54:30 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 PAA26286
for <pgsql-hackers@postgresql.org>;
Thu, 28 Oct 1999 15:53:46 -0400 (EDT) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max03-047.enterprise.net
[194.72.196.47])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id UAA25121;
Thu, 28 Oct 1999 20:53:39 +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 UAA31930;
Thu, 28 Oct 1999 20:53:31 +0100
Message-Id: <199910281953.UAA31930@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: pgsql-hackers@postgresql.org
cc: Brian Ristuccia <brianr@osiris.978.org>, 48582@bugs.debian.org
Subject: Bug#48582: psql spends hours computing results it already knows (fwd)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 28 Oct 1999 20:53:31 +0100
From: "Oliver Elphick" <olly@lfix.co.uk>

This is a Debian bug report, which needs upstream attention.

------- Forwarded Message

Date: Thu, 28 Oct 1999 13:45:18 -0400
From: Brian Ristuccia <brianr@osiris.978.org>
To: submit@bugs.debian.org
Subject: Bug#48582: psql spends hours computing results it already knows

Package: postgresql
Version: 6.5.2-3

massive_db=> explain select count(*) from huge_table;
NOTICE: QUERY PLAN:

Aggregate (cost=511.46 rows=9923 width=12)
-> Seq Scan on huge_table (cost=511.46 rows=9923 width=12)

EXPLAIN

If huge_table really is huge -- like 9,000,000 rows instead of 9923, after
postgresql already knows the number of rows (that's how it determines the
cost), it proceeds to do a very long and CPU/IO intensive seq scan to
determine the count().

- --
Brian Ristuccia
brianr@osiris.978.org
bristucc@nortelnetworks.com
bristucc@cs.uml.edu

------- End of Forwarded Message

--
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
========================================
"Cast thy burden upon the LORD, and he shall sustain
thee; he shall never allow the righteous to fall."
Psalms 55:22

From bouncefilter Thu Oct 28 16:33:30 1999
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA31171
for <pgsql-hackers@postgreSQL.org>;
Thu, 28 Oct 1999 16:32:41 -0400 (EDT)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m11gwDZ-000LEEC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgreSQL.org; Thu, 28 Oct 1999 15:32:17 -0500 (CDT)
Date: Thu, 28 Oct 1999 15:32:17 -0500
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: Oliver Elphick <olly@lfix.co.uk>
Cc: pgsql-hackers@postgreSQL.org, Brian Ristuccia <brianr@osiris.978.org>,
48582@bugs.debian.org
Subject: Re: [HACKERS] Bug#48582: psql spends hours computing results it
already knows (fwd)
Message-ID: <19991028153217.C32120@wallace.ece.rice.edu>
References: <199910281953.UAA31930@linda.lfix.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
In-Reply-To: <199910281953.UAA31930@linda.lfix.co.uk>;
from Oliver Elphick on Thu, Oct 28, 1999 at 08:53:31PM +0100

Oliver (& Brian) -
Hmm, that happens to not be the case. The rows=XXXX number is drawn
from the statistics for the table, which are only updated on VACUUM
ANALYZE of that table. Easily tested: just INSERT a couple rows and do
the EXPLAIN again. The rows=XXX won't change. Ah, here's an example:
a table I've never vacuumed, until now (it's in a test copy of a db)

test=> select count(*) from "Personnel";
count
-----
177
(1 row)

test=> explain select count(*) from "Personnel";
NOTICE: QUERY PLAN:

Aggregate (cost=43.00 rows=1000 width=4)
-> Seq Scan on Personnel (cost=43.00 rows=1000 width=4)

EXPLAIN
test=> vacuum analyze "Personnel";
VACUUM
test=> explain select count(*) from "Personnel";
NOTICE: QUERY PLAN:

Aggregate (cost=7.84 rows=177 width=4)
-> Seq Scan on Personnel (cost=7.84 rows=177 width=4)

EXPLAIN
test=>

Ross

On Thu, Oct 28, 1999 at 08:53:31PM +0100, Oliver Elphick wrote:

This is a Debian bug report, which needs upstream attention.

------- Forwarded Message

Date: Thu, 28 Oct 1999 13:45:18 -0400
From: Brian Ristuccia <brianr@osiris.978.org>
To: submit@bugs.debian.org
Subject: Bug#48582: psql spends hours computing results it already knows

Package: postgresql
Version: 6.5.2-3

massive_db=> explain select count(*) from huge_table;
NOTICE: QUERY PLAN:

Aggregate (cost=511.46 rows=9923 width=12)
-> Seq Scan on huge_table (cost=511.46 rows=9923 width=12)

EXPLAIN

If huge_table really is huge -- like 9,000,000 rows instead of 9923, after
postgresql already knows the number of rows (that's how it determines the
cost), it proceeds to do a very long and CPU/IO intensive seq scan to
determine the count().

- --
Brian Ristuccia
brianr@osiris.978.org
bristucc@nortelnetworks.com
bristucc@cs.uml.edu

From bouncefilter Thu Oct 28 16:38:30 1999
Received: from osiris.978.org (qmailr@bluebox.ne.mediaone.net [24.218.185.2])
by hub.org (8.9.3/8.9.3) with SMTP id QAA31898
for <pgsql-hackers@postgreSQL.org>;
Thu, 28 Oct 1999 16:38:11 -0400 (EDT)
(envelope-from brianr@osiris.978.org)
Received: (qmail 15726 invoked by uid 1000); 28 Oct 1999 20:35:53 -0000
Date: Thu, 28 Oct 1999 16:35:53 -0400
From: Brian Ristuccia <brianr@osiris.978.org>
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Cc: Oliver Elphick <olly@lfix.co.uk>, pgsql-hackers@postgreSQL.org,
48582@bugs.debian.org
Subject: Re: [HACKERS] Bug#48582: psql spends hours computing results it
already knows (fwd)
Message-ID: <19991028163553.B3255@osiris.978.org>
References: <199910281953.UAA31930@linda.lfix.co.uk>
<19991028153217.C32120@wallace.ece.rice.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0pre4i
In-Reply-To: <19991028153217.C32120@wallace.ece.rice.edu>;
from reedstrm@wallace.ece.rice.edu on Thu, Oct 28, 1999 at
03:32:17PM -0500

On Thu, Oct 28, 1999 at 03:32:17PM -0500, Ross J. Reedstrom wrote:

Oliver (& Brian) -
Hmm, that happens to not be the case. The rows=XXXX number is drawn
from the statistics for the table, which are only updated on VACUUM
ANALYZE of that table. Easily tested: just INSERT a couple rows and do
the EXPLAIN again. The rows=XXX won't change. Ah, here's an example:
a table I've never vacuumed, until now (it's in a test copy of a db)

Aah.. Is there any other more efficient way of determining the number of
rows in a table? It seems a sequential scan takes forever, but the database
must already have some idea (somewhere) of how many records are in the table
otherwise how would it know where to start/stop the sequential scan?

test=> select count(*) from "Personnel";
count
-----
177
(1 row)

test=> explain select count(*) from "Personnel";
NOTICE: QUERY PLAN:

Aggregate (cost=43.00 rows=1000 width=4)
-> Seq Scan on Personnel (cost=43.00 rows=1000 width=4)

EXPLAIN
test=> vacuum analyze "Personnel";
VACUUM
test=> explain select count(*) from "Personnel";
NOTICE: QUERY PLAN:

Aggregate (cost=7.84 rows=177 width=4)
-> Seq Scan on Personnel (cost=7.84 rows=177 width=4)

EXPLAIN
test=>

Ross

On Thu, Oct 28, 1999 at 08:53:31PM +0100, Oliver Elphick wrote:

This is a Debian bug report, which needs upstream attention.

------- Forwarded Message

Date: Thu, 28 Oct 1999 13:45:18 -0400
From: Brian Ristuccia <brianr@osiris.978.org>
To: submit@bugs.debian.org
Subject: Bug#48582: psql spends hours computing results it already knows

Package: postgresql
Version: 6.5.2-3

massive_db=> explain select count(*) from huge_table;
NOTICE: QUERY PLAN:

Aggregate (cost=511.46 rows=9923 width=12)
-> Seq Scan on huge_table (cost=511.46 rows=9923 width=12)

EXPLAIN

If huge_table really is huge -- like 9,000,000 rows instead of 9923, after
postgresql already knows the number of rows (that's how it determines the
cost), it proceeds to do a very long and CPU/IO intensive seq scan to
determine the count().

- --
Brian Ristuccia
brianr@osiris.978.org
bristucc@nortelnetworks.com
bristucc@cs.uml.edu

--
Brian Ristuccia
brianr@osiris.978.org
bristucc@nortelnetworks.com
bristucc@cs.uml.edu

From bouncefilter Thu Oct 28 18:59: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 SAA50589
for <hackers@postgreSQL.org>; Thu, 28 Oct 1999 18:59:03 -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 SAA29578;
Thu, 28 Oct 1999 18:58:12 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, hackers@postgreSQL.org
Subject: Re: [HACKERS] psql Week 4.142857
In-reply-to: Your message of Thu, 28 Oct 1999 18:46:39 +0200 (CEST)
<Pine.LNX.4.10.9910281841220.17464-100000@peter-e.yi.org>
Date: Thu, 28 Oct 1999 18:58:12 -0400
Message-ID: <29576.941151492@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

Oh, I defined it in that file, it's used in psql. Unfortunately, it seems
to be used internally in readline as well. In now figured out that this
causes problems only with static linking, but not dynamic. I'm no expert
on linking, does anyone have an idea or do I have to make up a different
name?

Pick another name --- you're just *asking* for trouble with that one.
People tend to invent macros with names like that...

regards, tom lane

From bouncefilter Thu Oct 28 19:07: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 TAA51743
for <pgsql-hackers@postgreSQL.org>;
Thu, 28 Oct 1999 19:07: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 TAA29604;
Thu, 28 Oct 1999 19:05:57 -0400 (EDT)
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
cc: Oliver Elphick <olly@lfix.co.uk>, pgsql-hackers@postgreSQL.org,
Brian Ristuccia <brianr@osiris.978.org>, 48582@bugs.debian.org
Subject: Re: [HACKERS] Bug#48582: psql spends hours computing results it
already knows (fwd)
In-reply-to: Your message of Thu, 28 Oct 1999 15:32:17 -0500
<19991028153217.C32120@wallace.ece.rice.edu>
Date: Thu, 28 Oct 1999 19:05:56 -0400
Message-ID: <29602.941151956@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:

Hmm, that happens to not be the case. The rows=XXXX number is drawn
from the statistics for the table, which are only updated on VACUUM
ANALYZE of that table. Easily tested: just INSERT a couple rows and do
the EXPLAIN again. The rows=XXX won't change.

The short answer to this is that maintaining a perfectly accurate tuple
count on-the-fly would almost certainly cost more, totalled over all
operations that modify a table, than we could ever hope to make back
by short-circuiting "select count(*)" operations. (Consider
concurrent transactions running in multiple backends, some of which
may abort instead of committing, and others of which may already have
committed but your transaction is not supposed to be able to see their
effects...)

The optimizer is perfectly happy with approximate tuple counts, so it
makes do with stats recorded at the last VACUUM.

This has been discussed quite recently on pg-hackers; see the archives
for more info.

regards, tom lane

From bouncefilter Thu Oct 28 20:28:32 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 UAA60455
for <hackers@postgreSQL.org>; Thu, 28 Oct 1999 20:28: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 UAA29144;
Thu, 28 Oct 1999 20:27:43 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910290027.UAA29144@candle.pha.pa.us>
Subject: Re: [HACKERS] psql Week 4.142857
In-Reply-To: <Pine.LNX.4.10.9910281841220.17464-100000@peter-e.yi.org> from
Peter Eisentraut at "Oct 28, 1999 06:46:39 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 28 Oct 1999 20:27:43 -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

Oh, I defined it in that file, it's used in psql. Unfortunately, it seems
to be used internally in readline as well. In now figured out that this
causes problems only with static linking, but not dynamic. I'm no expert
on linking, does anyone have an idea or do I have to make up a different
name?

Yes, very different name. We are supporting tons of platforms. You
need something very 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 Thu Oct 28 21:06:33 1999
Received: from ext16.sra.co.jp (IDENT:root@ykh28DS45.kng.mesh.ad.jp
[133.205.214.45]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA65118
for <pgsql-hackers@postgreSQL.org>;
Thu, 28 Oct 1999 21:05:57 -0400 (EDT)
(envelope-from t-ishii@ext16.sra.co.jp)
Received: from ext16.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id JAA00770;
Fri, 29 Oct 1999 09:56:56 +0900
Message-Id: <199910290056.JAA00770@ext16.sra.co.jp>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org,
paul.becker@awl.com
Subject: Re: [HACKERS] PostgreSQL book translation
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 21:38:11 -0400.
<199910280138.VAA29841@candle.pha.pa.us>
Date: Fri, 29 Oct 1999 09:56:56 +0900
Sender: t-ishii@ext16.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).

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.

Thanks. I will contact him.

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.

Great!
---
Tatsuo Ishii

From bouncefilter Thu Oct 28 21:48:44 1999
Received: from thelab.hub.org (nat198.58.mpoweredpc.net [142.177.198.58] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id VAA82398;
Thu, 28 Oct 1999 21:48:11 -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 WAA49164;
Thu, 28 Oct 1999 22:45:37 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 28 Oct 1999 22:45:37 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
"Marc G. Fournier" <scrappy@postgreSQL.org>
Subject: Re: 6.5.3
In-Reply-To: <199910272139.RAA20320@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9910282245250.404-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 27 Oct 1999, Bruce Momjian wrote:

When are we packaging 6.5.3 with the pgaccess addition?

Monday, 4:30ADT?

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

From bouncefilter Thu Oct 28 22:44:34 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 WAA03130
for <pgsql-hackers@postgreSQL.org>;
Thu, 28 Oct 1999 22:44:14 -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 WAA14161
for <pgsql-hackers@postgreSQL.org>;
Thu, 28 Oct 1999 22:44:12 -0400 (EDT)
Date: 28 Oct 1999 22:44:12 -0400
Message-ID: <emacs-smtp-1573-14361-2556-312146@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: <29602.941151956@sss.pgh.pa.us>
Subject: Re: [HACKERS] Bug#48582: psql spends hours computing results it
already knows (fwd)
References: <29602.941151956@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_Thu_Oct_28_22:44:11_1999-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit

--pgp-sign-Multipart_Thu_Oct_28_22:44:11_1999-1
Content-Type: text/plain; charset=US-ASCII

Then <tgl@sss.pgh.pa.us> spoke up and said:

The short answer to this is that maintaining a perfectly accurate tuple
count on-the-fly would almost certainly cost more, totalled over all
operations that modify a table, than we could ever hope to make back
by short-circuiting "select count(*)" operations. (Consider
concurrent transactions running in multiple backends, some of which
may abort instead of committing, and others of which may already have
committed but your transaction is not supposed to be able to see their
effects...)

So, does the planner allow counting from a unique index (if one
exists)? In general, an index scan on a unique index should be faster
than a table scan. Of course, I'm sure someone already thought of this...

--
=====================================================================
| 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_Thu_Oct_28_22:44:11_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

iQBUAwUBOBkJ/IdzVnzma+gdAQFJKAH4saCZpjWWTE/TYP3B1b71cpdXlFsVC7Be
AapBuWrFowwdY1cOiNBB4RJ4NNaNXIgJvru1UuOmmfmWgdBhutDV
=zONO
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Thu_Oct_28_22:44:11_1999-1--

From bouncefilter Thu Oct 28 23:59:35 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 XAA20239
for <pgsql-hackers@postgreSQL.org>;
Thu, 28 Oct 1999 23:58: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 XAA01068;
Thu, 28 Oct 1999 23:57:59 -0400 (EDT)
To: Brian E Gallew <geek+@cmu.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Bug#48582: psql spends hours computing results it
already knows (fwd)
In-reply-to: Your message of 28 Oct 1999 22:44:12 -0400
<emacs-smtp-1573-14361-2556-312146@export.andrew.cmu.edu>
Date: Thu, 28 Oct 1999 23:57:59 -0400
Message-ID: <1066.941169479@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Brian E Gallew <geek+@cmu.edu> writes:

So, does the planner allow counting from a unique index (if one
exists)? In general, an index scan on a unique index should be faster
than a table scan. Of course, I'm sure someone already thought of this...

Vadim will have to check me on this, but I believe that index entries
don't contain transaction information --- that is, you can determine
whether a tuple matches a specified search key by examining the index,
but in order to discover whether the tuple is actually *valid*
(according to your transaction's worldview) you must fetch the tuple
itself from the main table. So scanning an index cannot be cheaper than
a sequential scan of the main table, except when the index allows you to
avoid visiting most of the tuples in the main table.

There has been some discussion of allowing scans of indexes without
fetching the underlying tuples, but AFAICS that would mean replicating
the tuple transaction status information into (each!) index, which'd
be a big hit in both disk space and number of disk writes implied by
committing a tuple. I've got my doubts about it being a win...

regards, tom lane

From bouncefilter Fri Oct 29 00:52:36 1999
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA29663
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 00:51:54 -0400 (EDT) (envelope-from geek+@cmu.edu)
Received: from export.andrew.cmu.edu (EXPORT.ANDREW.CMU.EDU [128.2.23.2])
by smtp2.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id AAA18026
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 00:51:52 -0400 (EDT)
Date: 29 Oct 1999 00:51:51 -0400
Message-ID: <emacs-smtp-1573-14361-10215-998688@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: <1066.941169479@sss.pgh.pa.us>
Subject: Re: [HACKERS] Bug#48582: psql spends hours computing results it
already knows (fwd)
References: <1066.941169479@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_29_00:51:50_1999-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit

--pgp-sign-Multipart_Fri_Oct_29_00:51:50_1999-1
Content-Type: text/plain; charset=US-ASCII

Then <tgl@sss.pgh.pa.us> spoke up and said:

Vadim will have to check me on this, but I believe that index entries
don't contain transaction information --- that is, you can determine
whether a tuple matches a specified search key by examining the index,
but in order to discover whether the tuple is actually *valid*
(according to your transaction's worldview) you must fetch the tuple
itself from the main table. So scanning an index cannot be cheaper than
a sequential scan of the main table, except when the index allows you to
avoid visiting most of the tuples in the main table.

Right. As usual, I've overlooked something obvious. So, this really
wouldn't work unless we had an exclusive table lock ('cause then there
wouldn't be any other transactions to worry about, except for our
own). Feh.

--
=====================================================================
| 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_29_00:51:50_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

iQBVAwUBOBkn54dzVnzma+gdAQGPegH9FasjqU2inwmIInqOOH2DGCqhEW8BvtxX
ECsJ3/0G03rEMbuphgvxLJcs2CIDFGd1NFwjni80SR8vq4dBC6tvcw==
=Hz7l
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Fri_Oct_29_00:51:50_1999-1--

From bouncefilter Fri Oct 29 05:37:39 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 FAA76297
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 05:36:41 -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 LAA16140
for <pgsql-hackers@postgreSQL.org>; Fri, 29 Oct 1999 11:23:54 +0200
Date: Fri, 29 Oct 1999 11:23:54 +0200 (CEST)
From: Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: view vs. inheritance hierarchy (was: Bug(?) in pg_get_ruledef())
In-Reply-To: <Pine.LNX.3.96.991027123327.6743A-100000@ara.zf.jcu.cz>
Message-ID: <Pine.LNX.3.96.991029105037.14899A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

my first question was without answer, I try it again:

IMHO is a problem with the routine pg_get_ruledef(), this routine is used in
any query in the pg_dump for view dumping. But the pg_get_ruledef() not discern
contrast between view rules defined as 'select * table' and rules defined as
'select * table*' (the query should be run over all classes in the
inheritance hierarchy).

Is it a bug or a limitation? (The pg_dump is unworkable for a views tables
runnig over the inheritance hierarchy?)

Problem 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)
^^^^^^^^^^^^
but right is "mother_tab*"

---

Any comments? (Please)

Karel Z.

From bouncefilter Fri Oct 29 05:35:39 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 FAA75838
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 05:35:01 -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 LAA81344
for <pgsql-hackers@postgreSQL.org>; Fri, 29 Oct 1999 11:34:53 +0200
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXNQX3>; Fri, 29 Oct 1999 11:34:52 +0200
Message-ID:
<219F68D65015D011A8E000006F8590C60339E157@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas IZ5 <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Bug#48582: psql spends hours computing results it a
lready knows (fwd)
Date: Fri, 29 Oct 1999 11:34:44 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

The optimizer is perfectly happy with approximate tuple counts, so it
makes do with stats recorded at the last VACUUM.

This has been discussed quite recently on pg-hackers; see the archives
for more info.

Yes, the problem is not the optimizer. The problem is the select count(*).
A lot of DB's (like Informix) have a shortcut on this, and even though they
have it,
they don't use it for the optimizer.

If our btrees have an accurate count (deleted rows ?), scanning the smallest
index
would also be alot faster.

Andreas

From bouncefilter Fri Oct 29 06:42:40 1999
Received: from mail.psn.ne.jp (mail.psn.ne.jp [210.167.249.5])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA84636
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 06:42:23 -0400 (EDT)
(envelope-from sakaida@psn.co.jp)
Received: from ppp119 (ppp119.psn.ne.jp [210.167.249.119])
by mail.psn.ne.jp (8.9.1/3.7W) with SMTP id TAA07501
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 19:42:22 +0900 (JST)
Date: Fri, 29 Oct 1999 19:45:05 +0900
From: SAKAIDA <sakaida@psn.co.jp>
To: pgsql-hackers@postgreSQL.org
Subject: pgbash-1.2.1 released
Message-Id: <38197AB12C6.179DSAKAIDA@smtp.psn.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.25.07

Hi,

I have released pgbash-1.2.1.
http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html

Main updating content is next.

1.The improvement of the interactive operational environment.
2.The addition of the original COPY (with -y option) function.
3.It is not necessary to change Makefile.

# Pgbash was more excellent than psql in the shell program,
but it was not excellent in the interactive environment.
However, in this improvement, Pgbash will be more excellent
than psql in the interactive environment too.

1. The improvement of the interactive operational environment.

Type 'pgbash'.
pgbash> l -------------------- list databases
pgbash> sel test ------------- select * from test
pgbash> ins test col1,col2 --- copy test(col1,col2) from stdin
111 abc efg
\.
pgbash> dt ------------------- equal to "psql \dt"
pgbash> d table_name --------- equal to "psql \d "

2.The addition of the original COPY (with -y option) function.

pgbash> exec_sql -y "copy test(col1,col2) from /tmp/oo"

In COPY with -y option, it is possible to designate the column.
And, line number and error message are displayed, when the error
arises.

3. It is not necessary to change Makefile.

Until now, changes of Makefile were necessary in order to require
the include file of bash, when the version of bash changed. But,
in the pgbash-1.2.1, it is not necessary to change Makefile.

--
Regards.

SAKAIDA Masaaki -- Osaka, Japan

From bouncefilter Fri Oct 29 09:04:42 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id JAA00796
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 09:03:49 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11hBYy-0003kLC; Fri, 29 Oct 99 14:55 MET DST
Message-Id: <m11hBYy-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] view vs. inheritance hierarchy (was: Bug(?) in
pg_get_ruledef())
To: zakkr@zf.jcu.cz (Zakkr)
Date: Fri, 29 Oct 1999 14:55:24 +0200 (MET DST)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <Pine.LNX.3.96.991029105037.14899A-100000@ara.zf.jcu.cz> from
"Zakkr" at Oct 29, 99 11:23:54 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Hi,

my first question was without answer, I try it again:

IMHO is a problem with the routine pg_get_ruledef(), this routine is used in
any query in the pg_dump for view dumping. But the pg_get_ruledef() not discern
contrast between view rules defined as 'select * table' and rules defined as
'select * table*' (the query should be run over all classes in the
inheritance hierarchy).

Is it a bug or a limitation? (The pg_dump is unworkable for a views tables
runnig over the inheritance hierarchy?)

Surely a bug!

Unfortunately I'm too busy at the moment to tackle it down.
The location where the inheritance is ignored is

src/backend/utils/adt/ruleutils.c

or a similar name - you'll find that file - it's the source
where that damned pg_get_ruledef() is defined. If you can
loacate and fix the problem therein depends on how familiar
you are with interpreting querytrees. At some place the table
name is printed, but I don't know if it is possible to tell
from the data at hand if it is an inheritance. Maybe another
catalog lookup is required there.

Oh man, this little 'piece of magic' (as someone else called
it) was only intended to demonstrate that it is POSSIBLE AT
ALL to translate a querytree back into it's original SQL
statement. Why the hell did I assist in making use of it in
pg_dump?

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 29 09:36:42 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 JAA06359
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 09:36:20 -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 PAA20858;
Fri, 29 Oct 1999 15:23:22 +0200
Date: Fri, 29 Oct 1999 15:23:21 +0200 (CEST)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Jan Wieck <wieck@debis.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] view vs. inheritance hierarchy (was: Bug(?) in
pg_get_ruledef())
In-Reply-To: <m11hBYy-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.LNX.3.96.991029150644.20593A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 29 Oct 1999, Jan Wieck wrote:

Is it a bug or a limitation? (The pg_dump is unworkable for a views tables
runnig over the inheritance hierarchy?)

Surely a bug!

Unfortunately I'm too busy at the moment to tackle it down.
The location where the inheritance is ignored is

src/backend/utils/adt/ruleutils.c

or a similar name - you'll find that file - it's the source
where that damned pg_get_ruledef() is defined. If you can
loacate and fix the problem therein depends on how familiar
you are with interpreting querytrees. At some place the table
name is printed, but I don't know if it is possible to tell
from the data at hand if it is an inheritance. Maybe another
catalog lookup is required there.

Well, I try see to the source and fix it.

Oh man, this little 'piece of magic' (as someone else called

But, more good details make very good PosgreSQL :-))

it) was only intended to demonstrate that it is POSSIBLE AT
ALL to translate a querytree back into it's original SQL
statement. Why the hell did I assist in making use of it in
pg_dump?

If exist handle, why not open the door? Pg_dump is backup util which allow
dump _all_ definition and data, we need it right if we allow it.

(I use pg_dump only for data backup.)

Thank Jan!
Karel Z.

From bouncefilter Fri Oct 29 09:49: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 JAA08280
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 09:48: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 JAA01924;
Fri, 29 Oct 1999 09:47:44 -0400 (EDT)
To: Zakkr <zakkr@zf.jcu.cz>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] view vs. inheritance hierarchy (was: Bug(?) in
pg_get_ruledef())
In-reply-to: Your message of Fri, 29 Oct 1999 11:23:54 +0200 (CEST)
<Pine.LNX.3.96.991029105037.14899A-100000@ara.zf.jcu.cz>
Date: Fri, 29 Oct 1999 09:47:44 -0400
Message-ID: <1922.941204864@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Zakkr <zakkr@zf.jcu.cz> writes:

But the pg_get_ruledef() not discern contrast between view rules
defined as 'select * table' and rules defined as 'select * table*'
(the query should be run over all classes in the inheritance
hierarchy).

Is it a bug or a limitation?

Sounds like a bug to me too. The fix is probably just a small addition
of code, but I haven't had time to look into it.

regards, tom lane

From bouncefilter Fri Oct 29 10:26: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 KAA14042
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 10:26:39 -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 KAA02176;
Fri, 29 Oct 1999 10:25:28 -0400 (EDT)
To: wieck@debis.com (Jan Wieck)
cc: zakkr@zf.jcu.cz (Zakkr), pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] view vs. inheritance hierarchy (was: Bug(?) in
pg_get_ruledef())
In-reply-to: Your message of Fri, 29 Oct 1999 14:55:24 +0200 (MET DST)
<m11hBYy-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Fri, 29 Oct 1999 10:25:28 -0400
Message-ID: <2174.941207128@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

Oh man, this little 'piece of magic' (as someone else called
it) was only intended to demonstrate that it is POSSIBLE AT
ALL to translate a querytree back into it's original SQL
statement. Why the hell did I assist in making use of it in
pg_dump?

Because it solved a necessary problem. Don't beat yourself up about
it...

regards, tom lane

From bouncefilter Fri Oct 29 17:29: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 RAA73127
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 17:29:48 -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 RAA13358
for pgsql-hackers@postgreSQL.org; Fri, 29 Oct 1999 17:29:19 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910292129.RAA13358@candle.pha.pa.us>
Subject: Serial and NULL values
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Fri, 29 Oct 1999 17:29:19 -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 just received a message from someone complaining about SERIAL/sequence. I
think there is a problem:

test=> create table test (x int, y serial);
NOTICE: CREATE TABLE will create implicit sequence 'test_y_seq' for SERIAL column 'test.y'
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'test_y_key' for table 'test'
CREATE
test=> insert into test (x) values (100);
INSERT 19359 1
test=> insert into test (x) values (100);
INSERT 19360 1

These work fine, but why does this fail:

test=> insert into test values (100, null);
ERROR: ExecAppend: Fail to add null value in not null attribute y
test=> insert into test values (100, 0);
INSERT 19363 1
test=> insert into test values (100, 0);
ERROR: Cannot insert a duplicate key into a unique index

Can't they use zero or null, and have the sequence value be computed?
Is there some design decision we made to prevent this?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Fri Oct 29 18:02:48 1999
Received: from nsi.edu (amethea.nsi.edu [198.133.185.9])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA78917
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 18:02:32 -0400 (EDT) (envelope-from reina@nsi.edu)
Received: from nsi.edu (o21.nsi.edu [204.128.156.216])
by nsi.edu (8.9.1/8.9.1) with ESMTP id PAA03770
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 15:02:30 -0700 (PDT)
Sender: reina@nsi.edu
Message-ID: <381A1B63.6C5C5578@nsi.edu>
Date: Fri, 29 Oct 1999 15:10:44 -0700
From: "G. Anthony Reina" <reina@nsi.edu>
Organization: The Neurosciences Institute
X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: MATLAB PostgreSQL interface
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It looks like we're going to give a go at a native interface between
MATLAB and PostgreSQL. I think if we can just define the enumerated
types for PGresult and PGconnect plus some of the enumerated constants
(PGRES_TUPLES_OK, PGRES_COMMAND_OK), then we can just write cmex wrapper
functions from the existing C function library of PostgreSQL.

Does anyone happen to have a nice PGresult and PGconnect definition
(i.e. no references to other enumerated types)? The way these look now
(in the header file libpq-int.h) it may take some time to go through all
of the embedded enumerated types.

Also, just so we don't have to re-invent the wheel: Are there any
MATLAB/PostgreSQL interfaces already written?

Thanks.
-Tony Reina

From bouncefilter Fri Oct 29 18:19: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 SAA81275
for <pgsql-hackers@postgresql.org>;
Fri, 29 Oct 1999 18:19:29 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id SAA17988;
Fri, 29 Oct 1999 18:18:43 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910292218.SAA17988@candle.pha.pa.us>
Subject: Re: [HACKERS] MATLAB PostgreSQL interface
In-Reply-To: <381A1B63.6C5C5578@nsi.edu> from "G. Anthony Reina" at "Oct 29,
1999 03:10:44 pm"
To: "G. Anthony Reina" <reina@nsi.edu>
Date: Fri, 29 Oct 1999 18:18:43 -0400 (EDT)
CC: "pgsql-hackers@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

It looks like we're going to give a go at a native interface between
MATLAB and PostgreSQL. I think if we can just define the enumerated
types for PGresult and PGconnect plus some of the enumerated constants
(PGRES_TUPLES_OK, PGRES_COMMAND_OK), then we can just write cmex wrapper
functions from the existing C function library of PostgreSQL.

Grab them from the source or include file.

-- 
  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 29 19:46: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 TAA93799
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 19:45:54 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id TAA03697;
Fri, 29 Oct 1999 19:44:44 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Serial and NULL values
In-reply-to: Your message of Fri, 29 Oct 1999 17:29:19 -0400 (EDT)
<199910292129.RAA13358@candle.pha.pa.us>
Date: Fri, 29 Oct 1999 19:44:44 -0400
Message-ID: <3695.941240684@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

test=> create table test (x int, y serial);
CREATE
test=> insert into test values (100, null);
ERROR: ExecAppend: Fail to add null value in not null attribute y

gram.y thinks SERIAL is defined to mean NOT NULL:

| ColId SERIAL ColPrimaryKey
{
ColumnDef *n = makeNode(ColumnDef);
n->colname = $1;
n->typename = makeNode(TypeName);
n->typename->name = xlateSqlType("integer");
n->raw_default = NULL;
n->cooked_default = NULL;
=================> n->is_not_null = TRUE;
n->is_sequence = TRUE;
n->constraints = $3;

$$ = (Node *)n;
}

Offhand I don't see any fundamental reason why serial columns should
be restricted to be nonnull, but evidently someone did at some point.

regards, tom lane

From bouncefilter Fri Oct 29 20:22:50 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 UAA98398
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 20:22:27 -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 UAA25008;
Fri, 29 Oct 1999 20:20:30 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910300020.UAA25008@candle.pha.pa.us>
Subject: Re: [HACKERS] Serial and NULL values
In-Reply-To: <3695.941240684@sss.pgh.pa.us> from Tom Lane at "Oct 29,
1999 07:44:44 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 29 Oct 1999 20:20:30 -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

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

test=> create table test (x int, y serial);
CREATE
test=> insert into test values (100, null);
ERROR: ExecAppend: Fail to add null value in not null attribute y

gram.y thinks SERIAL is defined to mean NOT NULL:

| ColId SERIAL ColPrimaryKey
{
ColumnDef *n = makeNode(ColumnDef);
n->colname = $1;
n->typename = makeNode(TypeName);
n->typename->name = xlateSqlType("integer");
n->raw_default = NULL;
n->cooked_default = NULL;
=================> n->is_not_null = TRUE;
n->is_sequence = TRUE;
n->constraints = $3;

$$ = (Node *)n;
}

Offhand I don't see any fundamental reason why serial columns should
be restricted to be nonnull, but evidently someone did at some point.

The actual null is not the issue. The issue is that if we have a
SERIAL column, and we try to put a NULL in there, shouldn't it put the
default sequence number in there?

-- 
  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 29 21:28:50 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 VAA06407
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 21:27:50 -0400 (EDT)
(envelope-from bhirt@loopy.berkhirt.com)
Received: (from bhirt@localhost)
by loopy.berkhirt.com (8.9.3/8.8.7) id VAA25023;
Fri, 29 Oct 1999 21:26:42 -0400
Date: Fri, 29 Oct 1999 21:26:42 -0400
From: Brian Hirt <bhirt@mobygames.com>
To: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Serial and NULL values
Message-ID: <19991029212642.A24778@loopy.berkhirt.com>
Reply-To: bhirt@mobygames.com
References: <3695.941240684@sss.pgh.pa.us>
<199910300020.UAA25008@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <199910300020.UAA25008@candle.pha.pa.us>;
from Bruce Momjian on Fri, Oct 29, 1999 at 08:20:30PM -0400
X-PC-Gaming: http://www.mobygames.com/

On Fri, Oct 29, 1999 at 08:20:30PM -0400, Bruce Momjian wrote:

Offhand I don't see any fundamental reason why serial columns should
be restricted to be nonnull, but evidently someone did at some point.

The actual null is not the issue. The issue is that if we have a
SERIAL column, and we try to put a NULL in there, shouldn't it put the
default sequence number in there?

It seems logical that if a value was supplied for a serial column that
it would override the default. After all, SERIAL is just an int column
with a default based on a sequence, right?. If the default is always
used (even when a value is supplied) then that would be a REAL BIG problem.

Without making SERIAL a distinctly different datatype, I can't see how
a default sequence could behave differently for two tables created with
different syntax.

My 2 cents is that the current behavior is the correct behavior.

As far as the NULL goes, since the SERIAL column is assumed to be a
key and a unique index is created, having it NOT NULL seems like a
good idea. I don't know anyone who would have a key value be NULL,
and even if it could be NULL, you would olny be allowd one NULL.

--
The world's most ambitious and comprehensive PC game database project.

http://www.mobygames.com

From bouncefilter Fri Oct 29 22:29:52 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 WAA12990
for <pgsql-hackers@postgreSQL.org>;
Fri, 29 Oct 1999 22:29:45 -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 WAA05279;
Fri, 29 Oct 1999 22:28:41 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Serial and NULL values
In-reply-to: Your message of Fri, 29 Oct 1999 20:20:30 -0400 (EDT)
<199910300020.UAA25008@candle.pha.pa.us>
Date: Fri, 29 Oct 1999 22:28:40 -0400
Message-ID: <5277.941250520@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Offhand I don't see any fundamental reason why serial columns should
be restricted to be nonnull, but evidently someone did at some point.

The actual null is not the issue. The issue is that if we have a
SERIAL column, and we try to put a NULL in there, shouldn't it put the
default sequence number in there?

No, I wouldn't expect that at all. A default is inserted when you
don't supply anything at all for the column. Inserting an explicit
NULL means you want a NULL, and barring a NOT NULL constraint on
the column, that's what the system ought to insert. I can see no
possible justification for creating a type-specific exception to
that behavior.

If the original asker really wants to substitute something else for
an explicit null insertion, he could do it with a rule or a trigger.
But I don't think SERIAL ought to act that way all by itself.

regards, tom lane

From bouncefilter Sat Oct 30 08:13:16 1999
Received: from flame.flame.co.za (flame.flame.co.za [160.124.170.1])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA90326
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 08:13:12 -0400 (EDT)
(envelope-from theo@flame.co.za)
Received: from flame.co.za (flame [160.124.170.1])
by flame.flame.co.za (8.8.7/8.8.7) with ESMTP id OAA08669
for <pgsql-hackers@postgreSQL.org>; Sat, 30 Oct 1999 14:11:35 +0200
Sender: theo@flame.flame.co.za
Message-ID: <381AE077.9FBA34A0@flame.co.za>
Date: Sat, 30 Oct 1999 14:11:35 +0200
From: Theo Kramer <theo@flame.co.za>
Organization: Flame Computing Enterprises
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.35 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] 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:

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.

Sounds like good material for the manual... and the book.
--------
Regards
Theo

From bouncefilter Sat Oct 30 09:46:17 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 JAA99712
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 09:45:20 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11hYgh-0003kLC; Sat, 30 Oct 99 15:36 MET DST
Message-Id: <m11hYgh-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Serial and NULL values
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Sat, 30 Oct 1999 15:36:55 +0200 (MET DST)
Cc: maillist@candle.pha.pa.us, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <5277.941250520@sss.pgh.pa.us> from "Tom Lane" at Oct 29,
99 10:28:40 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

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

Offhand I don't see any fundamental reason why serial columns should
be restricted to be nonnull, but evidently someone did at some point.

The actual null is not the issue. The issue is that if we have a
SERIAL column, and we try to put a NULL in there, shouldn't it put the
default sequence number in there?

No, I wouldn't expect that at all. A default is inserted when you
don't supply anything at all for the column. Inserting an explicit
NULL means you want a NULL, and barring a NOT NULL constraint on
the column, that's what the system ought to insert. I can see no
possible justification for creating a type-specific exception to
that behavior.

If the original asker really wants to substitute something else for
an explicit null insertion, he could do it with a rule or a trigger.
But I don't think SERIAL ought to act that way all by itself.

regards, tom lane

I agree with tom.

If you don't want the user to be able to insert NULL, specify
NOT NULL explicitly. And if you want to force a default
behaviour, use a trigger (a rule can't do - sorry).

Jan

--

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

From bouncefilter Sat Oct 30 11:41:19 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 LAA11101
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 11:41:03 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11haV3-0003kzC; Sat, 30 Oct 99 17:33 MET DST
Message-Id: <m11haV3-0003kzC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: missing mugshots
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Sat, 30 Oct 1999 17:33:00 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

http://www.PostgreSQL.org/~wieck/

The new developers globe is updated with all photos I got so
far. Still missing are:

Andrew Martin
Bruce Momjian
Byron Nikolaidis
Constantin Teodorescu
Edmund Mergl
Goran Thyni
Hiroshi Inoue
Massimo dal Zotto
Michael Meskes
Tatsuo Ishii
Thomas Lockhart
Tom Lane

Since I don't expect that we get all of them soon, I reverted
and took out the photos from the text part again.

Who should maintain this page finally? If it's me, I would
and update the content of the main site now. If not, tell me
who and when to transfer.

BTW: There are alot of files on the main site where cvs stat
doesn't tell up-to-date. Some are locally modified but not
committed, some need a merge.

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 Sat Oct 30 11:54: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 LAA12481
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 11:52: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 LAA04444;
Sat, 30 Oct 1999 11:50:27 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910301550.LAA04444@candle.pha.pa.us>
Subject: Re: [HACKERS] missing mugshots
In-Reply-To: <m11haV3-0003kzC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 30, 1999 05:33:00 pm"
To: Jan Wieck <wieck@debis.com>
Date: Sat, 30 Oct 1999 11:50:27 -0400 (EDT)
CC: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM941298627-4399-0_
Content-Transfer-Encoding: 7bit

--ELM941298627-4399-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

http://www.PostgreSQL.org/~wieck/

The new developers globe is updated with all photos I got so
far. Still missing are:

Andrew Martin
Bruce Momjian
Byron Nikolaidis
Constantin Teodorescu
Edmund Mergl
Goran Thyni
Hiroshi Inoue
Massimo dal Zotto
Michael Meskes
Tatsuo Ishii
Thomas Lockhart
Tom Lane

OK, mine is attached. As I mentioned on the phone, I was waiting for a
haircut, but it seems it is not coming soon enough. Here is a recent
photo I liked.

Since I don't expect that we get all of them soon, I reverted
and took out the photos from the text part again.

Who should maintain this page finally? If it's me, I would
and update the content of the main site now. If not, tell me
who and when to transfer.

If you would be willing to, that would be great.

BTW: There are alot of files on the main site where cvs stat
doesn't tell up-to-date. Some are locally modified but not
committed, some need a merge.

You mean files on the site that are not in cvs, or are newer than the
cvs copies. Either Vince or I did that, I suppose. How did you find
which ones they were? Vince, any ideas?

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

--ELM941298627-4399-0_
Content-Type: image/jpeg
Content-Disposition: inline; filename="/bjm/momjian.jpg"
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQAAAQABAAD//gBYQ1JFQVRPUjogWFYgVmVyc2lvbiAzLjEwYSAgUmV2OiAx
Mi8yOS85NCAoUE5HIHBhdGNoIDEuMikgIFF1YWxpdHkgPSA3NSwgU21vb3RoaW5nID0gMAr/2wBD
AAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5
PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABQAFADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAA
AAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKB
kaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZn
aGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT
1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcI
CQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAV
YnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6
goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDh8fvFPfH9al7Gq+SZBz2qXP5GuY70SqBj71Sq
EQjznCZ7E8/lVCW5khB2r07mt3wn4PuPEkxuLlz5KZ3yE9OM4x+NKVkrsiVRIyNS1KKBQkJDN356
1FYanLvLMQwPUZIA/Kt/XPAk8Nyz2il4+g3EZP8AX865ldIvllZY4iCD2NVGUGtBTjPc3Ybu2unJ
3bJP7rdD9DQeJVB4HNYslrNZxBrmIox+63UZ/Cr1tctMVOckLwfXpUuPVFxk78rLLj5uarR/c49f
61M78moE6FT6mpRoymCQ34f1qQElsHpUIOW/D+tS/wAIq7kIidJLu4jjXGNxHPSvojwxZadp/huF
Y/LWED55GOMk9Tmvn23aW9vYbGKMCWR1TI44PevYtd8M6tcRQRafAhigQLGZGBA9yM8mom1dJnLU
gpvllKx0b3fhwP5f22zZ24x5isax7vRNEs3F3JepFGOWXy+D+Oa5WP4d3rOks9zMb0tlpPLXyyPQ
L2+ua6nxd4d1HUvDVnBayxxTwgrISDg5+mfSqtB7II2pSUVU3MzW9E0XxFoU5067ti4GVaMjgg+n
4V5xpVpEEnjbmSI7TzyTXTWXhPWNOWGNgJicksEwyHnlW/nmuRuIprfWLxXUoyzOvX3PSiy1UWdC
i0ld3FZs/lUaHlvqaccZyaiB+Z/rSRoyUz2qYeKBSM85Bx+Gami1y0tmy+nW8oHZk61kw2i2scm+
6V5GGNg7f5zVW4YKuOvY1appnLdnoNpYKdZ0jULgKiSqJEAGOCAVH0AIr2i2nYxK7EeXjsOcV4FF
4ri1ey0u1CSJJp0Ihw2CCAAARwDzjOD0ruPDnjKNbL7NfRnKkgMXxkY+lZqLiysRS9vFSW53Otak
tlpkk8bxRMvIaU9f55rzay+Imtzanb2d9NamMzIHZY8AqTzziqF1Df8AifVZpmZYLBPuNKeDjjj1
p97olre2bW9rNaefCp27Y9jN7Zyc1qpdiqWEhGFtLnsMk8CwNIhDZHB6g15gll4Yvte1OLWpZIJz
PviZG2rg5yPTr/OsnQPE95o8Eml6jEyhB8jucFfauP124N3q003d2JGfrScU2ZQoOlCTT6ne+IPA
KWdk+oaPfLdWiDc0bsDIOQOCBgjn2rguRLJn1qfSdZudLkDoSyH70ecZqGTUBqd5PcCPyyzcgnPb
1qVFr0NaUna0mYsNwqfe2sT3xzUFxcbyQOlVml7D86iLnPWuixz3L2l3Bt78N/e61u/2kW5LHAOA
B+tc5YBmv4ABks4GPXtWtqVpNZzSJk9egqJW5rM2hzcrsdhbeJLVtK+zSMFVenrWfFqFrb3hkimb
d1BrjHkkBIyfWmCSTIO9qfIinXZ1esaut7MHJy3AzWNcXe+5bec+ntVcF44HmbJCjv61S80sxZup
601FETqN6s0nuC3IYDPTNWNOcF3XgseSRWQDu6GtLSlxI7ewFKWxNP4kWJvCN3GuBPHuAzjB/nTb
PwzLFIJbwqY15whz+fFfRKeBdFDZa3U/nUp8CeH2Uj7GQT1xIw/rURc5bIweIorqfOUcv9g6sl2k
EUyiTdEJgSuf+AkfrW/qvibS9bt1e60+e1u1AXMZV0YepGB/WvWdS+FmhX0Jjj82LOf4t2PzrzbX
vhTregWU14k9veWsQyfLJEgH+6R/Wm4q95rU0p4iL+F7nFST2TOQh4HqMUsUuno6tLvIB6KtV5IR
3XP86QIuDzg/TIq7I05nc0dTvLPUoEgsopY9pyS+OfypNJ0O11Pes80kcqlVAVgN35jrVWJSoznI
9hT84UZ45z6YpeSE5Nu7NWTwbanHk6jICfuh48//AKqkbQ59OgjVFV8EhmDZLZ710BDXKpMMZkAJ
9m/+vVa8ml+xblOHibJJ6ilyt9Rq25//2Q==

--ELM941298627-4399-0_

--ELM941298627-4399-0_--

From bouncefilter Sat Oct 30 12:39:19 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 MAA20157
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 12:38:50 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11hbOe-0003kLC; Sat, 30 Oct 99 18:30 MET DST
Message-Id: <m11hbOe-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] missing mugshots
To: maillist@candle.pha.pa.us (Bruce Momjian)
Date: Sat, 30 Oct 1999 18:30:27 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199910301550.LAA04444@candle.pha.pa.us> from "Bruce Momjian" at
Oct 30, 99 11:50:27 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

BTW: There are alot of files on the main site where cvs stat
doesn't tell up-to-date. Some are locally modified but not
committed, some need a merge.

You mean files on the site that are not in cvs, or are newer than the
cvs copies. Either Vince or I did that, I suppose. How did you find
which ones they were? Vince, any ideas?

[wieck@hub] ~pgsql/ftp/www/html > cvs stat |& less

The locally modified ones don't seem to be a problem to me
since they are what's visible outside and simply need a
commit.

But the ones telling Needs Merge are! This status means,
that the working file is a locally modified copy of an older
revision in the CVS. A cvs update would try to merge both
modifications into the new working file and this is required
before a commit! Let's take devel-contrib.html as an example:

[wieck@hub] ~pgsql/ftp/www/html > cvs stat devel-contrib.html
===================================================================
File: devel-contrib.html Status: Needs Merge

Working revision: 1.29 Mon Mar 29 16:43:09 1999
Repository revision: 1.44 /usr/local/cvsroot/www/html/devel-contrib.html,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)

The last cvs update brought the working copy (that one
actually on the web site) into sync with 1.29. Since then,
there have been 15 commits from other working directories
plus local modifications to the file. Looking at the diff it
seems that the authors (momjian and vev :-) have a checkout
of the repository on their home system, commit modifications
there and instead of checking them out on the main site they
just copy their working files onto the site, ignoring that
the main site is another working directory of the same
repository. That's just what I guess from what I see.

Just to be complete (don't know if there are any) the state
Needs Patch means, that the working file is an unmodified one
needing a cvs update because there where modifications to the
CVS from somewhere else.

To fix this situation I think we should first commit the ones
that are modified locally via

cvs commit <file>

and do a

cvs update <file>

for any one that needs a patch.

Finally we have all those left that need a merge. I'm not
sure, but can we say that what's actually on the site is
correct? If so, we could take the files one by one, move the
actual file out of the way and do a

cvs update <file>

This will checkout the file in the state, the repository
thinks is correct. Then we move back what we know is actual
and do a commit. After this move-update-moveback cvs thinks
it's a locally modified one and the new cvs revision is then
what anybody can see on the web.

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 Sat Oct 30 13:38:20 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 NAA26609
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 13:37: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 NAA14050;
Sat, 30 Oct 1999 13:37:10 -0400 (EDT)
To: t-ishii@sra.co.jp
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
In-reply-to: Your message of Tue, 19 Oct 1999 17:49:22 +0900
<199910190849.RAA29403@srapc451.sra.co.jp>
Date: Sat, 30 Oct 1999 13:37:10 -0400
Message-ID: <14048.941305030@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

It worked with 2GB+ table but was much slower than before.
Before(with 8MB sort memory): 22 minutes
After(with 8MB sort memory): 1 hour and 5 minutes
After(with 80MB sort memory): 42 minutes.

I've committed some changes to tuplesort.c to try to improve
performance. Would you try your test case again with current
sources? Also, please see if you can record the CPU time
consumed by the backend while doing the sort.

regards, tom lane

From bouncefilter Sat Oct 30 16:43:22 1999
Received: from druid.net (root@druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA44930
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 16:42:39 -0400 (EDT) (envelope-from darcy@druid.net)
Received: from localhost (1292 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m11hfKa-0000bFC@druid.net> for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 16:42:32 -0400 (EDT)
(Smail-3.2.0.104 1998-Nov-20 #4 built 1999-Apr-13)
Message-Id: <m11hfKa-0000bFC@druid.net>
Subject: Re: [HACKERS] missing mugshots
In-Reply-To: <m11haV3-0003kzC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 30, 1999 05:33:00 pm"
To: wieck@debis.com
Date: Sat, 30 Oct 1999 16:42:32 -0400 (EDT)
From: "D'Arcy" "J.M." Cain <darcy@druid.net>
Cc: 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 Jan Wieck

The new developers globe is updated with all photos I got so

One thing I notice is that mine and the server share a pin (reasonable
as we are in the same place) but the way it is presented is a little
confusing. It will get more confusing as time goes on and we get more
than one person in the same city. At least in this case it's obvious that
the server didn't work on stuff. There should be a cleaner delineation
between people sharing the same location.

-- 
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 Sat Oct 30 16:53:22 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 QAA46243
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 16:52:26 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11hfKb-0003kLC; Sat, 30 Oct 99 22:42 MET DST
Message-Id: <m11hfKb-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: Sat, 30 Oct 1999 22:42:33 +0200 (MET DST)
Cc: maillist@candle.pha.pa.us, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <22606.940946519@sss.pgh.pa.us> from "Tom Lane" at Oct 26,
99 10:01:59 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Tom Lane wrote:

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.

Right. A major release is what it is. And porting
applications to a new major release too, it is a conversion,
not an upgrade. Therefore a major release should drop as much
backward compatibility code for minor releases as possible.

Thus, we should think about getting rid of the broken design
for functions returning tuple sets in 7.0. As far as I
understand the books I have, there are a couple of different
types of functions/procedures out, and not every database
implements all types, nor do they all name one and the same
type equally so that something called function in one
database is a stored procedure in another. Anyway, the
different types are:

1. Functions returning a scalar value taking only input-
arguments.

2. Functions returning a scalar value taking input-, output-
and in/out-arguments.

3. Functions returning nothing taking only input-arguments.

4. Functions returning nothing taking input-, output- and
in/out-arguments.

5. Functions returning a set of result rows taking only
input-arguments.

6. Functions returning a set of result rows taking input-,
output- and in/out-arguments.

I don't think that we have to implement everything, and since
we don't have host variables, output- and in/out-arguments
would make sense only for calls from procedural languages.
OTOH they would cause much trouble so they are one detail to
let out for PostgreSQL.

Three cases left. Type number 1. we have already. And it is
advanced, because the arguments can be either single values,
or single rows.

And type number 3. is easy, because invoking something that
returns a dummy that is thrown away is absolutely no work.

So the only thing that's really left is number 5. The funny
detail is, that those functions or procedures can't be used
inside regular SELECT queries. Instead a CALL FUNCTION or
EXECUTE PROCEDURE statement is used from the client
application or inside a PL block. CALL FUNCTION then returns
a tuple set as a SELECT does. The result in our world
therefore has a tuple descriptor and depending on the invoker
is sent to the client or stored in an SPI tuple table.

So we do not need to call functions returning sets through
the normal function manager. It could competely deny calls to
set functions, and the interface for them can be a total
different one. I have something in mind that could work
without temp tables, but it requires a redesign for PL/pgSQL
and causes some limitations for PL/Tcl. Let's leave that for
a past 7.0 release.

I correct my previous statements and vote to deny calls to
set functions through the default function manager in 7.0.

And there is another detail I found while browsing through
the books. Functions can be defined as [NOT] NULL CALL (IBM
DB2). Functions defined as NOT NULL CALL will be called only
if all their arguments aren't NULL. So we can prevent much
NULL handling inside the functions if we simply define that a
function that is NOT NULL CALL will allways return NULL if
any of it's input arguments is NULL. This case can then be
handled at the function manager level without calling the
function itself. Nearly all our builtin functions behave that
way but have all the tests inside.

Another detail I'm missing now is a new, really defined
interface for type input/output functions. The fact that they
are defined taking one opaque (yepp, should be something
different as already discussed) argument but in fact get more
information from the attribute is ugly.

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 Sat Oct 30 16:56:22 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 QAA46742
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 16:56:17 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11hfQ5-0003kLC; Sat, 30 Oct 99 22:48 MET DST
Message-Id: <m11hfQ5-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] missing mugshots
To: pgsql-hackers@postgreSQL.org
Date: Sat, 30 Oct 1999 22:48:13 +0200 (MET DST)
Cc: wieck@debis.com
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <m11hfKa-0000bFC@druid.net> from "D'Arcy" "J.M." Cain" at Oct 30,
99 04:42:32 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Thus spake Jan Wieck

The new developers globe is updated with all photos I got so

One thing I notice is that mine and the server share a pin (reasonable
as we are in the same place) but the way it is presented is a little
confusing. It will get more confusing as time goes on and we get more
than one person in the same city. At least in this case it's obvious that
the server didn't work on stuff. There should be a cleaner delineation
between people sharing the same location.

Hmmmm,

does that mean the server is only close to you, not where you
are?

From the wording in the original page "... and location of
hub.org" I assumed that it is the SAME location, not just
another one in Toronto. Therefore I just colored the pin a
little different. But if it's a separate location it must be
a separate pin with it's own popup.

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 Sat Oct 30 16:59: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 QAA46998
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 16:58:49 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 3432 invoked by uid 1001); 30 Oct 1999 20:58:53 -0000
Message-ID: <XFMail.991030165853.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <m11hbOe-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Sat, 30 Oct 1999 16:58:53 -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: (Jan Wieck) <wieck@debis.com>
Subject: Re: [HACKERS] missing mugshots
Cc: pgsql-hackers@postgreSQL.org, (Bruce Momjian) <maillist@candle.pha.pa.us>

On 30-Oct-99 Jan Wieck wrote:

Bruce Momjian wrote:

BTW: There are alot of files on the main site where cvs stat
doesn't tell up-to-date. Some are locally modified but not
committed, some need a merge.

You mean files on the site that are not in cvs, or are newer than the
cvs copies. Either Vince or I did that, I suppose. How did you find
which ones they were? Vince, any ideas?

[wieck@hub] ~pgsql/ftp/www/html > cvs stat |& less

The locally modified ones don't seem to be a problem to me
since they are what's visible outside and simply need a
commit.

But the ones telling Needs Merge are! This status means,
that the working file is a locally modified copy of an older
revision in the CVS. A cvs update would try to merge both
modifications into the new working file and this is required
before a commit! Let's take devel-contrib.html as an example:

[wieck@hub] ~pgsql/ftp/www/html > cvs stat devel-contrib.html
===================================================================
File: devel-contrib.html Status: Needs Merge

Working revision: 1.29 Mon Mar 29 16:43:09 1999
Repository revision: 1.44 /usr/local/cvsroot/www/html/devel-contrib.html,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)

The last cvs update brought the working copy (that one
actually on the web site) into sync with 1.29. Since then,
there have been 15 commits from other working directories
plus local modifications to the file. Looking at the diff it
seems that the authors (momjian and vev :-) have a checkout
of the repository on their home system, commit modifications
there and instead of checking them out on the main site they
just copy their working files onto the site, ignoring that
the main site is another working directory of the same
repository. That's just what I guess from what I see.

Must have been a long time ago. Can I just do a cvs release or
something like that? I do all my work on hub.

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 Sat Oct 30 17:23:22 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 RAA49779
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 17:22:26 -0400 (EDT) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 496CF529E; Sun, 31 Oct 1999 00:32:26 +0300 (EEST)
Sender: hannu@hu.tm.ee
Message-ID: <381B63EA.DC8F1F4@tm.ee>
Date: Sat, 30 Oct 1999 21:32:26 +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: Jan Wieck <wieck@debis.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, maillist@candle.pha.pa.us,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
References: <m11hfKb-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Wieck wrote:

...

5. Functions returning a set of result rows taking only
input-arguments.

...

So the only thing that's really left is number 5. The funny
detail is, that those functions or procedures can't be used
inside regular SELECT queries. Instead a CALL FUNCTION or
EXECUTE PROCEDURE statement is used from the client
application or inside a PL block. CALL FUNCTION then returns
a tuple set as a SELECT does. The result in our world
therefore has a tuple descriptor and depending on the invoker
is sent to the client or stored in an SPI tuple table.

So we do not need to call functions returning sets through
the normal function manager. It could competely deny calls to
set functions, and the interface for them can be a total
different one. I have something in mind that could work
without temp tables, but it requires a redesign for PL/pgSQL
and causes some limitations for PL/Tcl. Let's leave that for
a past 7.0 release.

I correct my previous statements and vote to deny calls to
set functions through the default function manager in 7.0.

It would be very nice if we could use the tuple-set-returning
functions in place of tables/views,

SELECT * FROM LOGGED_IN_USERS_INFO_PROC;

or at least define views on them:

CREATE VIEV LOGGED_IN_USERS AS CALL FUNCTION LOGGED_IN_USERS_INFO_PROC;

We would not need to call them in place of functions that return
either single-value or tuple.

On the topic of 2x3=6 kinds of functions you mentioned I think we
could use jet another type of functions - the one returning a
tuple/row as is ofteh case in python and possibly other languages
that do automatic tuple packing/unpacking.

It could be used in cases like this:

INSERT INTO MY_TABLE CALL FUNCTION MY_ROW_VALUE;

or

DELETE FROM MY_TABLE WHERE * = CALL FUNCTION MY_ROW_VALUE;

(The last example is not ansi and does not work currently),

OTOH, these exaples would jus be redundant cases for your 5th case.

OTOOH, all the functions returning less than a set of rows are
redundadnt cases of the functions that do ;)

-----------
Hannu

From bouncefilter Sat Oct 30 17:30:22 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 RAA50360
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 17:29:54 -0400 (EDT) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 42708529E; Sun, 31 Oct 1999 00:39:54 +0300 (EEST)
Sender: hannu@hu.tm.ee
Message-ID: <381B65AA.9374CE7B@tm.ee>
Date: Sat, 30 Oct 1999 21:39:54 +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: Jan Wieck <wieck@debis.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, maillist@candle.pha.pa.us,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
References: <m11hfKb-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Wieck wrote:

Another detail I'm missing now is a new, really defined
interface for type input/output functions. The fact that they
are defined taking one opaque (yepp, should be something
different as already discussed) argument but in fact get more
information from the attribute is ugly.

Can we currently return a list of the same type ?

I guess we can, as lists (or arrays) are fundamentl types in
PostgreSQL, but I'm not sure.

I would like to define aggregate functions list() and set()

Could I define then just once and specify that they return an array
of their input type ?

Half of that is currently done for count() - i.e. it can take any
type of argument, but I guess the return-array-of-input-type is more
complicated.

Also (probably off topic) how hard would it be to add another type
of aggregate funtions tha operate on pairs of values ?

I would like to have FOR_MIN and FOR_MAX (and possibly MIN_MIN and
MAX_MAX) functions that return _another_ field from a table for a
minimal value in one field.

-------------
Hannu

From bouncefilter Sat Oct 30 18:02:23 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 SAA53879;
Sat, 30 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 RAA09201;
Sat, 30 Oct 1999 17:43:09 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910302143.RAA09201@candle.pha.pa.us>
Subject: pgaccess for 6.5.3
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Sat, 30 Oct 1999 17:43:09 -0400 (EDT)
CC: teo@flex.ro, "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

Still problems with pgaccess.

While the new Makefile I made properly copies pgaccess to the bin
directory, it does not deal with PGACCESS_HOME properly, and I believe
configure should be table to set PATH_TO_WISH.

Please hold 6.5.3 until someone comes up with a good solution to this.

Do we want to copy the entire pgaccess tree to the pgsql install
directory?

Can someone suggest a line for PATH_TO_WISH that can be set by configure?

-- 
  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 30 22:18:25 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 WAA95608
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 22:17:42 -0400 (EDT)
(envelope-from frankpit@pop.dn.net)
From: frankpit@pop.dn.net
Received: from pop.dn.net (pm-94.ppp.wdc.dn.net [207.226.188.94])
by postal.dn.net (102199-jg) with ESMTP id WAA02185;
Sat, 30 Oct 1999 22:17:08 -0400 (EDT)
Sender: bernie@postal.dn.net
Message-ID: <381B6BC1.C90C98C3@pop.dn.net>
Date: Sat, 30 Oct 1999 18:05:53 -0400
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.34 i686)
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
References: <m11hgq6-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I think that the proposals for the revision of the function interface
are all an improvement on what is there, and I hope to try to find time
to help implement whatever is decided. Here are some more thoughts in
relation to the question of set valued and tuple valued (or complex
type?) arguments.

Another place that user defined functions are used in the PostgreSQL
backend is in association with access methods. Both as boolean
operators for search predicates, and as auxiliary functions for the
access methods. Allowing set valued and tuple valued arguments and
return values for functions and operators in this setting can be
valuable.

For instance, suppose I have a table t that stores geometric objects in
some space, and I have a spatial index such as R*-tree, or even a GIST
index. Given a set of points pts I want to do a query of the form

SELECT * FORM t WHERE t.object <intersects> pts;

Under these circumstances it would be really nice to be able to pass a
set of objects (as an SPI tuple table for instance) into the index.

Currently, the way I do this (with a custom access method) is to create
a temp table, put the key set into the temp table, and pass the name of
the temp table to the access method in the search key. The access
method then does an SPI select on the temp table and stores the returned
items into the private scan state for use during the scan.

While I realize that implementing this example requires much more than a
change to the function interface, I hope that it illustrates that it is
perhaps a good idea to keep as much flexibility in the function
interface as possible.

Bernie Franpitt

From bouncefilter Sat Oct 30 18:19:23 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 SAA55487
for <pgsql-hackers@postgresql.org>;
Sat, 30 Oct 1999 18:18:27 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <V58Z05JR>; Sun, 31 Oct 1999 00:17:29 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C1DE@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: pg_dump, and strings
Date: Sun, 31 Oct 1999 00:09:38 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Hi, all

In pg_dump there is a file called common.c. This file has some string
handling routines in it that return a pointer to a fixed-length, static
string (char *). I need to remove the fixed-length bit (besides the fact
fact that this is horrendously un-threadsafe). So, what is the best
mechanism to use on replacement? There seem to be two fairly standard
methods to use, a) make the calling function allocate the memory it
requires, and pass that in to the called function, or b) the called function
allocates memory using a documented call (say, malloc), and hands
responsibility for freeing the memory to the calling function. Given the
non-fixed-length constraint, the second option would appear better, but does
any body out there have any other ideas?

MikeA

From bouncefilter Sat Oct 30 18:27:23 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 SAA56576
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 18:27:16 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11hgq6-0003kLC; Sun, 31 Oct 99 00:19 MET DST
Message-Id: <m11hgq6-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
To: hannu@tm.ee (Hannu Krosing)
Date: Sun, 31 Oct 1999 00:19:10 +0200 (MET DST)
Cc: wieck@debis.com, tgl@sss.pgh.pa.us, maillist@candle.pha.pa.us,
pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <381B63EA.DC8F1F4@tm.ee> from "Hannu Krosing" at Oct 30,
99 09:32:26 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Hannu Krosing wrote:

Jan Wieck wrote:

I correct my previous statements and vote to deny calls to
set functions through the default function manager in 7.0.

It would be very nice if we could use the tuple-set-returning
functions in place of tables/views,

SELECT * FROM LOGGED_IN_USERS_INFO_PROC;

Exactly that's something I want for long now. Sticking
another querytree, that returns a tuple set, into a
rangetable entry. This other querytree could be either a
SELECT as in

SELECT A.x, A.y, B.z FROM table1 A, (SELECT ...) B
WHERE A.x = B.x;

or a function returning a set as in

SELECT A.x, A.y, B.z FROM table1 A, setfunc('arg') B
WHERE A.x = B.x;

Finally, the form

CALL setfunc('arg');

would be equivalent to a

SELECT * FROM setfunc('arg');

but closer to the IBM DB2 calling syntax. The first one is
required to get rid of some problems in the rule system,
especially views with aggregate columns that need their own
GROUP BY clause. The other ones are what we need to implement
stored procedures.

or at least define views on them:

CREATE VIEV LOGGED_IN_USERS AS CALL FUNCTION LOGGED_IN_USERS_INFO_PROC;

Wrong syntax since the statement after AS must be a SELECT.
But a

CREATE VIEW v AS SELECT * FROM setfunc();

would do the trick.

We would not need to call them in place of functions that return
either single-value or tuple.

On the topic of 2x3=6 kinds of functions you mentioned I think we
could use jet another type of functions - the one returning a
tuple/row as is ofteh case in python and possibly other languages
that do automatic tuple packing/unpacking.

It could be used in cases like this:

INSERT INTO MY_TABLE CALL FUNCTION MY_ROW_VALUE;

Let's clearly distinguish between scalar, row and set return
values. A scalar return value is one single datum. A row
return value is exactly one tuple of 1...n datums and a set
return value is a collection of 0...n rows.

What we have now (at least what works properly) are only
scalar return values from functions. And I don't see the
point of a row return, so I think we don't need them.

or

DELETE FROM MY_TABLE WHERE * = CALL FUNCTION MY_ROW_VALUE;

(The last example is not ansi and does not work currently),

OTOH, these exaples would jus be redundant cases for your 5th case.

OTOOH, all the functions returning less than a set of rows are
redundadnt cases of the functions that do ;)

But please don't forget that it isn't enough to write down
the syntax and specify the behaviour with some english words.
We must define the behaviour in C too, and in that language
it's a little more than a redundant case of something,
because we don't have that something.

Jan

--

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

From bouncefilter Sat Oct 30 19:00:24 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 TAA60489;
Sat, 30 Oct 1999 19:00: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 SAA05835;
Sat, 30 Oct 1999 18:57:19 -0400
Message-ID: <381B77C4.F90D4FD8@wgcr.org>
Date: Sat, 30 Oct 1999 18:57:08 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>, teo@flex.ro,
"Marc G. Fournier" <scrappy@postgreSQL.org>
Subject: Re: [HACKERS] pgaccess for 6.5.3
References: <199910302143.RAA09201@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Still problems with pgaccess.

While the new Makefile I made properly copies pgaccess to the bin
directory, it does not deal with PGACCESS_HOME properly, and I believe
configure should be table to set PATH_TO_WISH.

Please hold 6.5.3 until someone comes up with a good solution to this.

Do we want to copy the entire pgaccess tree to the pgsql install
directory?

Can someone suggest a line for PATH_TO_WISH that can be set by configure?

Hmmm.... Under the RPM installation, there is installed, by the build
script in the spec file, a shell script into /usr/bin called pgaccess --
this script is as follows:
-----------
#!/bin/sh

PATH_TO_WISH=/usr/bin/wish
PGACCESS_HOME=/usr/lib/pgsql/pgaccess

export PATH_TO_WISH
export PGACCESS_HOME

exec ${PATH_TO_WISH} ${PGACCESS_HOME}/main.tcl "$@"
----------

PGACCESS_HOME should, under the standard installation, be set to
something more inline with the standard installation's idea of where
pgaccess/main.tcl is located.

PATH_TO_WISH should likely be /usr/bin/wish on most systems.

The RPM packages have not relied upon the tarball's inclusion of
pgaccess -- rather, a separate tarball of just the latest pgaccess is
grafted in -- so there may be some other differences that I am not aware
of.

--
Lamar Owen
WGCR Internet Radio

From bouncefilter Sat Oct 30 18:49:23 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 SAA58889
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 18:48:47 -0400 (EDT) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 1CCDB52D0; Sun, 31 Oct 1999 01:58:47 +0300 (EEST)
Sender: hannu@hu.tm.ee
Message-ID: <381B7826.EB0B8249@tm.ee>
Date: Sat, 30 Oct 1999 22:58:46 +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: Jan Wieck <wieck@debis.com>
Cc: tgl@sss.pgh.pa.us, maillist@candle.pha.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
References: <m11hgq6-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Wieck wrote:

Hannu Krosing wrote:

Jan Wieck wrote:

What we have now (at least what works properly) are only
scalar return values from functions. And I don't see the
point of a row return, so I think we don't need them.

That's what I mant by the OTOH below

(The last example is not ansi and does not work currently),

OTOH, these exaples would jus be redundant cases for your 5th case.

OTOOH, all the functions returning less than a set of rows are
redundadnt cases of the functions that do ;)

But please don't forget that it isn't enough to write down
the syntax and specify the behaviour with some english words.
We must define the behaviour in C too, and in that language
it's a little more than a redundant case of something,
because we don't have that something.

Yes, that's the hard part.

---------
Hannu

From bouncefilter Sat Oct 30 19:01:23 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 TAA60529
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 19:00: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 SAA18672;
Sat, 30 Oct 1999 18:59:44 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Performance glitch in GetCurrentAbsoluteTime()
Date: Sat, 30 Oct 1999 18:59:44 -0400
Message-ID: <18669.941324384@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I have been doing some profiling this weekend in response to Vadim's
challenge to reduce the amount of overhead in a simple INSERT command.
I've found a number of simple improvements that I hope to check in
shortly. I came across something in the time code that I thought I'd
better check with you before changing.

In utils/adt/nabstime.c, the function GetCurrentAbsoluteTime() is called
during each StartTransaction in order to save the transaction's start
time. It shows up unreasonably high in my profile (> 1% of runtime):

0.62 10.22 100001/100001 StartTransaction [65]
[91]: 1.4 0.62 10.22 100001 GetCurrentAbsoluteTime [91] 0.92 8.30 100001/100001 localtime [105] 0.88 0.00 100001/100004 time [305] 0.12 0.00 100001/104713 strcpy [479]
0.92 8.30 100001/100001 localtime [105]
0.88 0.00 100001/100004 time [305]
0.12 0.00 100001/104713 strcpy [479]

Now the interesting thing about this is that the essential part of the
function is just the time() call, AFAICS, and that's quite cheap. More
than 90% of the runtime is being spent in the "if (!HasCTZSet)" branch.
I see no reason for that code to be run during every single transaction.
It sets the following variables:

CTimeZone
CDayLight
CTZName

CDayLight is not used *anywhere* except for debug printouts, and could
go away completely. CTZName is not used if USE_POSIX_TIME is defined,
which is true on most platforms. CTimeZone is not quite as useless, but
there are only a couple places where it's used when USE_POSIX_TIME is
true, and they don't look like critical-path stuff to me.

We could almost say that these variables need only be set once per
backend startup, but I suppose that would do the wrong thing in a
backend that's left running over a daylight-savings transition.

What I'm inclined to do is arrange for these variables to be calculated
only on-demand, at most once per transaction. It'd be even nicer to
get rid of them entirely, but I don't think I understand the time code
well enough to venture that.

Do you have any comments pro or con on this?

regards, tom lane

From bouncefilter Sat Oct 30 19:34: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 TAA64324
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 19:33: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 TAA18988;
Sat, 30 Oct 1999 19:32:52 -0400 (EDT)
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
cc: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] pg_dump, and strings
In-reply-to: Your message of Sun, 31 Oct 1999 00:09:38 +0200
<1BF7C7482189D211B03F00805F8527F748C1DE@S-NATH-EXCH2>
Date: Sat, 30 Oct 1999 19:32:52 -0400
Message-ID: <18986.941326372@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:

In pg_dump there is a file called common.c. This file has some string
handling routines in it that return a pointer to a fixed-length, static
string (char *). I need to remove the fixed-length bit (besides the fact
fact that this is horrendously un-threadsafe). So, what is the best
mechanism to use on replacement? There seem to be two fairly standard
methods to use, a) make the calling function allocate the memory it
requires, and pass that in to the called function, or b) the called function
allocates memory using a documented call (say, malloc), and hands
responsibility for freeing the memory to the calling function. Given the
non-fixed-length constraint, the second option would appear better, but does
any body out there have any other ideas?

The first approach requires that the caller know in advance how much
result space the callee will need; unless the return type is fixed-size
that's usually a bad design.

Another possibility is to do something like the backend's palloc()
stuff, wherein responsibility for eventually cleaning up the garbage
is handed to a third party. But that's probably overkill for pg_dump.

regards, tom lane

From bouncefilter Sat Oct 30 19:44:24 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 TAA65580
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 19:44:09 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11hi2Q-0003kLC; Sun, 31 Oct 99 01:35 MET DST
Message-Id: <m11hi2Q-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] missing mugshots
To: vev@michvhf.com (Vince Vielhaber)
Date: Sun, 31 Oct 1999 01:35:58 +0200 (MET DST)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org, maillist@candle.pha.pa.us
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <XFMail.991030165853.vev@michvhf.com> from "Vince Vielhaber" at
Oct 30, 99 04:58:53 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Vince Vielhaber wrote:

Must have been a long time ago. Can I just do a cvs release or
something like that? I do all my work on hub.

I don't know about such a command. And the real problem seems
to me that there are multiple maintainers that treat it
differently.

The content provided on the net should NOT be a checked out
working copy. Any maintainter of the files should have it's
own checkout local, ideally at a location where a web server
can present it (like an apache virtual host). The files on
the web site should be updated automatically by CVS rules at
commit time.

In this setup, one could test changes local until anything is
O.K. and do a commit that automatically presents all the
changes at once to the world.

An advance is, that if you want to do heavy modifications to
a couple of files, you could do a

cvs admin -l <file> [...]

and be sure, noone else can do a commit until you're done.
Well, another user could explicitly break the lock with
another "cvs admin -l", but then you, as the original locker,
are notified via mail about it. If you ensure that there is
at least a little modification in the locked file (adding a
space somewhere immediately after locking it), you are sure
that the next commit will checkin a new revision. At this
time, the lock implicitly is done and the file is unlocked
again. Otherwise you must do an explicit

cvs admin -u <file> [...]

to release the lock with no changes made. And that bears the
risk of forgetting locks.

I'll play around a little with CVS rules (don't know exactly
how to set them up but I know that they exist). Will tell you
later if this is something worth to try.

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 Sun Oct 31 18:07:40 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 SAA32759
for <pgsql-hackers@postgresql.org>;
Sun, 31 Oct 1999 18:07:20 -0500 (EST)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:1757 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s5AiN12638>;
Mon, 1 Nov 1999 00:07:05 +0100
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11hiBW-0000hX-00; Sun, 31 Oct 1999 01:45:22 +0200
Date: Sun, 31 Oct 1999 01:45:21 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
cc: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] pg_dump, and strings
In-Reply-To: <1BF7C7482189D211B03F00805F8527F748C1DE@S-NATH-EXCH2>
Message-ID: <Pine.LNX.4.10.9910310141310.462-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 31, Ansley, Michael mentioned:

Hi, all

In pg_dump there is a file called common.c. This file has some string
handling routines in it that return a pointer to a fixed-length, static
string (char *). I need to remove the fixed-length bit (besides the fact
fact that this is horrendously un-threadsafe). So, what is the best
mechanism to use on replacement? There seem to be two fairly standard
methods to use, a) make the calling function allocate the memory it
requires, and pass that in to the called function, or b) the called function
allocates memory using a documented call (say, malloc), and hands
responsibility for freeing the memory to the calling function. Given the
non-fixed-length constraint, the second option would appear better, but does
any body out there have any other ideas?

MikeA

Of course malloc is not very thread-safe either.

But as far is I'm concerned, the difference between a) and b) is cosmetic.

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

From bouncefilter Sat Oct 30 20:20:25 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id UAA82228
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 20:19:46 -0400 (EDT) (envelope-from vev@michvhf.com)
Received: (qmail 3789 invoked by uid 1001); 31 Oct 1999 00:19:50 -0000
Message-ID: <XFMail.991030201950.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <m11hi2Q-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Sat, 30 Oct 1999 20:19:50 -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: (Jan Wieck) <wieck@debis.com>
Subject: Re: [HACKERS] missing mugshots
Cc: pgsql-hackers@postgreSQL.org, maillist@candle.pha.pa.us

On 31-Oct-99 Jan Wieck wrote:

Vince Vielhaber wrote:

Must have been a long time ago. Can I just do a cvs release or
something like that? I do all my work on hub.

I don't know about such a command. And the real problem seems
to me that there are multiple maintainers that treat it
differently.

The content provided on the net should NOT be a checked out
working copy. Any maintainter of the files should have it's
own checkout local, ideally at a location where a web server
can present it (like an apache virtual host). The files on
the web site should be updated automatically by CVS rules at
commit time.

In this setup, one could test changes local until anything is
O.K. and do a commit that automatically presents all the
changes at once to the world.

An advance is, that if you want to do heavy modifications to
a couple of files, you could do a

cvs admin -l <file> [...]

and be sure, noone else can do a commit until you're done.
Well, another user could explicitly break the lock with
another "cvs admin -l", but then you, as the original locker,
are notified via mail about it. If you ensure that there is
at least a little modification in the locked file (adding a
space somewhere immediately after locking it), you are sure
that the next commit will checkin a new revision. At this
time, the lock implicitly is done and the file is unlocked
again. Otherwise you must do an explicit

cvs admin -u <file> [...]

to release the lock with no changes made. And that bears the
risk of forgetting locks.

I'll play around a little with CVS rules (don't know exactly
how to set them up but I know that they exist). Will tell you
later if this is something worth to try.

Congrats Jan. You lost me. AFAIK that's how the website works - at least
as long as I've been maintaining it. The thing that's not maintained that
way is the news and announcements which I maintain via a web based tool.
Bruce and Tom (Lockhart) maintain the docs pages. Or am I missing something
totally obvious?

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 Sat Oct 30 20:46:24 1999
Received: from druid.net (root@druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA85387
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 20:45:53 -0400 (EDT) (envelope-from darcy@druid.net)
Received: from localhost (2232 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m11hj82-0000bFC@druid.net> for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 20:45:50 -0400 (EDT)
(Smail-3.2.0.104 1998-Nov-20 #4 built 1999-Apr-13)
Message-Id: <m11hj82-0000bFC@druid.net>
Subject: Re: [HACKERS] missing mugshots
In-Reply-To: <m11hfQ5-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 30, 1999 10:48:13 pm"
To: wieck@debis.com
Date: Sat, 30 Oct 1999 20:45:50 -0400 (EDT)
From: "D'Arcy" "J.M." Cain <darcy@druid.net>
Cc: 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 Jan Wieck

One thing I notice is that mine and the server share a pin (reasonable
as we are in the same place) but the way it is presented is a little
confusing. It will get more confusing as time goes on and we get more
than one person in the same city. At least in this case it's obvious that
the server didn't work on stuff. There should be a cleaner delineation
between people sharing the same location.

Hmmmm,

does that mean the server is only close to you, not where you
are?

From the wording in the original page "... and location of
hub.org" I assumed that it is the SAME location, not just
another one in Toronto. Therefore I just colored the pin a
little different. But if it's a separate location it must be
a separate pin with it's own popup.

I just assumed that there wasn't enough room to stick two pins in the same
city. Well, we aren't in exactly the same place. However, I connect
directly to the system that provides hub.org it's bandwidth so logically
we are next door neighbours.

However, it really is a different place but, as I said, we have to
deal with when we get big enough that one city might get crowded.
Why not just have the popup be a list of developers rather than one
and allow for more than one.

Then again, more pins looks better. In any case, perhaps the server
should have its own pin.

-- 
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 Sat Oct 30 21:03:25 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 VAA87143
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 21:03:11 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11hjGv-0003kLC; Sun, 31 Oct 99 02:55 MET DST
Message-Id: <m11hjGv-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] missing mugshots
To: wieck@debis.com
Date: Sun, 31 Oct 1999 02:55:01 +0200 (MET DST)
Cc: vev@michvhf.com, pgsql-hackers@postgreSQL.org, maillist@candle.pha.pa.us
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <m11hi2Q-0003kLC@orion.SAPserv.Hamburg.dsh.de> from "Jan Wieck"
at Oct 31, 99 01:35:58 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

I'll play around a little with CVS rules (don't know exactly
how to set them up but I know that they exist). Will tell you
later if this is something worth to try.

Whow, never thought it would be that easy!

If we place a tiny little script

#!/bin/sh
cd /home/projects/pgsql/ftp/www
cvs update </dev/null >/dev/null 2>&1 &
echo ""
echo "Main WEBsite will be updated automatically."
echo "The appropriate 'cvs update' is already waiting"
echo "in background for your locks to be released."
echo ""

into the same directory it cd's to, we only need to add the
line

www -i /home/projects/pgsql/ftp/www/<script> www

to the modules file in the CVSROOT and anyone with a local
checkout must do a new checkout. Also we checkout the actual
working directory of the real site again and voila, anytime
someone does a commit a 'cvs update' is automatically started
in the web sites root directory. It must run in background to
avoid a deadlock, so be it. The echo messages are visible to
the one doing the commit, so it's just to remind that he's
doing something visible to the world.

As said, anybody should WORK in his private checked out
working directory at home. This would prevent side effects if
multiple maintainers work on the real files.

But for very small changes, it would be O.K. to do it on the
main site and commit them there, because the cvs update
started in background would be a noop in fact.

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 Sat Oct 30 21:08:25 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 VAA87759
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 21:08:07 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11hjLr-0003kLC; Sun, 31 Oct 99 02:00 MET
Message-Id: <m11hjLr-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] missing mugshots
To: pgsql-hackers@postgreSQL.org
Date: Sun, 31 Oct 1999 02:00:07 +0100 (MET)
Cc: wieck@debis.com
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <m11hj82-0000bFC@druid.net> from "D'Arcy" "J.M." Cain" at Oct 30,
99 08:45:50 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Then again, more pins looks better. In any case, perhaps the server
should have its own pin.

Not allways, at least if more than 50% of the area not
occupied by water gets hidden by pins :-).

Anyway, I'll make it a separate one and will work on the list
approach when we need it bacause of space shortage for new
pins.

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 Sat Oct 30 21:32:25 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 VAA90322
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 21:32:05 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11hjit-0003kLC; Sun, 31 Oct 99 02:23 MET
Message-Id: <m11hjit-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] missing mugshots
To: vev@michvhf.com (Vince Vielhaber)
Date: Sun, 31 Oct 1999 02:23:55 +0100 (MET)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org, maillist@candle.pha.pa.us
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <XFMail.991030201950.vev@michvhf.com> from "Vince Vielhaber" at
Oct 30, 99 08:19:50 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Vince Vielhaber wrote:

I'll play around a little with CVS rules (don't know exactly
how to set them up but I know that they exist). Will tell you
later if this is something worth to try.

Congrats Jan. You lost me. AFAIK that's how the website works - at least
as long as I've been maintaining it. The thing that's not maintained that
way is the news and announcements which I maintain via a web based tool.
Bruce and Tom (Lockhart) maintain the docs pages. Or am I missing something
totally obvious?

Hmmm,

maybe I lost you, but then again what you knew can't be
right. The only CVSROOT files, where the module www occurs,
are the history and the loginfo. And loginfo is just
something that send's logging info via mail. It is not
intended to do other automatic jobs, and the one entry for
www in it in fact only sends them to
committers@postgresql.org.

If it works that way, it must be very tricky hidden and not
implemented the way it should be. At least it doesn't work
anymore. I cannot imagine how it otherwise could be that from
58 files in the www repository

19 have state Up-to-Date
24 have state Needs Merge
and
4 have state Locally Modified.

And there are files, like overlib.*, that are totally unknown
to the repository!

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 Sat Oct 30 22:01:25 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 VAA93040
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 21:59: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 VAA14501;
Sat, 30 Oct 1999 21:57:06 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910310157.VAA14501@candle.pha.pa.us>
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
In-Reply-To: <m11hfKb-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 30, 1999 10:42:33 pm"
To: Jan Wieck <wieck@debis.com>
Date: Sat, 30 Oct 1999 21:57:06 -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

Tom Lane wrote:

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.

Right. A major release is what it is. And porting
applications to a new major release too, it is a conversion,
not an upgrade. Therefore a major release should drop as much
backward compatibility code for minor releases as possible.

If this was simple stuff, we could keep compatibility with little
problem. But, with complex stuff like this, keeping backward
compatibility sometimes make things more confusing. They can code
things two ways, and that makes people get confused as to which one to
follow.

-- 
  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 30 22:06:26 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 WAA93941
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 22:05: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 WAA15562;
Sat, 30 Oct 1999 22:04:47 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910310204.WAA15562@candle.pha.pa.us>
Subject: Re: [HACKERS] missing mugshots
In-Reply-To: <m11hi2Q-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 31, 1999 01:35:58 am"
To: Jan Wieck <wieck@debis.com>
Date: Sat, 30 Oct 1999 22:04:47 -0400 (EDT)
CC: Vince Vielhaber <vev@michvhf.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

Vince Vielhaber wrote:

Must have been a long time ago. Can I just do a cvs release or
something like that? I do all my work on hub.

I don't know about such a command. And the real problem seems
to me that there are multiple maintainers that treat it
differently.

The content provided on the net should NOT be a checked out
working copy. Any maintainter of the files should have it's
own checkout local, ideally at a location where a web server
can present it (like an apache virtual host). The files on
the web site should be updated automatically by CVS rules at
commit time.

I am sorry, but I am totally confused.

I have a cvs copy here. I do cvs commits, and I ftp the files to the
web site when I make a change. Yes, it would be nice to have cvs commit
automatically install them on the web site.

-- 
  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 30 22:06:25 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 WAA94001
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 22:06: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 WAA15579;
Sat, 30 Oct 1999 22:05:26 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910310205.WAA15579@candle.pha.pa.us>
Subject: Re: [HACKERS] missing mugshotsu
In-Reply-To: <XFMail.991030201950.vev@michvhf.com> from Vince Vielhaber at
"Oct
30, 1999 08:19:50 pm"
To: Vince Vielhaber <vev@michvhf.com>
Date: Sat, 30 Oct 1999 22:05:26 -0400 (EDT)
CC: 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'll play around a little with CVS rules (don't know exactly
how to set them up but I know that they exist). Will tell you
later if this is something worth to try.

Congrats Jan. You lost me. AFAIK that's how the website works - at least
as long as I've been maintaining it. The thing that's not maintained that
way is the news and announcements which I maintain via a web based tool.
Bruce and Tom (Lockhart) maintain the docs pages. Or am I missing something
totally obvious?

Yea, now we are both lost.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sat Oct 30 22:38:26 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 WAA97599
for <pgsql-hackers@postgreSQL.org>;
Sat, 30 Oct 1999 22:37:42 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11hkkW-0003kLC; Sun, 31 Oct 99 03:29 MET
Message-Id: <m11hkkW-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
To: frankpit@pop.dn.net
Date: Sun, 31 Oct 1999 03:29:39 +0100 (MET)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <381B6BC1.C90C98C3@pop.dn.net> from "frankpit@pop.dn.net" at Oct
30, 99 06:05:53 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bernie Franpitt wrote:

SELECT * FORM t WHERE t.object <intersects> pts;

Under these circumstances it would be really nice to be able to pass a
set of objects (as an SPI tuple table for instance) into the index.

Currently, the way I do this (with a custom access method) is to create
a temp table, put the key set into the temp table, and pass the name of
the temp table to the access method in the search key. The access
method then does an SPI select on the temp table and stores the returned
items into the private scan state for use during the scan.

While I realize that implementing this example requires much more than a
change to the function interface, I hope that it illustrates that it is
perhaps a good idea to keep as much flexibility in the function
interface as possible.

Uhhh - it is a good idea, but passing tuple sets as arguments
to functions, that will cause headaches, man.

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 Sun Oct 31 01:56:29 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 BAA19020
for <pgsql-hackers@postgreSQL.org>;
Sun, 31 Oct 1999 01:56:04 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA19412;
Sun, 31 Oct 1999 01:54:45 -0400 (EDT)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>, teo@flex.ro
Subject: Re: [HACKERS] pgaccess for 6.5.3
In-reply-to: Your message of Sat, 30 Oct 1999 18:57:08 -0400
<381B77C4.F90D4FD8@wgcr.org>
Date: Sun, 31 Oct 1999 01:54:45 -0400
Message-ID: <19410.941349285@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Can someone suggest a line for PATH_TO_WISH that can be set by configure?

You should use autoconf's standard mechanism for testing for a
program's existence and location. To wit,
AC_PATH_PROG(PATH_TO_WISH, wish)
or one of its variants.

regards, tom lane

From bouncefilter Sun Oct 31 05:48:32 1999
Received: from fep01-svc.tin.it (mta01-acc.tin.it [212.216.176.32])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA44693
for <pgsql-hackers@postgresql.org>;
Sun, 31 Oct 1999 05:47:46 -0500 (EST)
(envelope-from mario.simeone@tin.it)
Received: from galileo ([212.216.204.211]) by fep01-svc.tin.it
(InterMail v4.01.01.02 201-229-111-106) with SMTP
id <19991031104714.SOIT8422.fep01-svc@galileo>
for <pgsql-hackers@postgresql.org>; Sun, 31 Oct 1999 11:47:14 +0100
Message-ID: <001f01bf2385$4a072cf0$d3ccd8d4@galileo>
From: "Mario Simeone" <mario.simeone@tin.it>
To: <pgsql-hackers@postgresql.org>
Subject: subscribe
Date: Sun, 31 Oct 1999 10:49:55 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

From bouncefilter Sun Oct 31 07:52:33 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA56333
for <pgsql-hackers@postgreSQL.org>;
Sun, 31 Oct 1999 07:52:14 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id HAA25923;
Sun, 31 Oct 1999 07:49:04 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910311249.HAA25923@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess for 6.5.3
In-Reply-To: <19410.941349285@sss.pgh.pa.us> from Tom Lane at "Oct 31,
1999 01:54:45 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 31 Oct 1999 07:49:04 -0500 (EST)
CC: Lamar Owen <lamar.owen@wgcr.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>, teo@flex.ro
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Can someone suggest a line for PATH_TO_WISH that can be set by configure?

You should use autoconf's standard mechanism for testing for a
program's existence and location. To wit,
AC_PATH_PROG(PATH_TO_WISH, wish)
or one of its variants.

Thanks. That's what I used. See my other message outlining my changes
to get this working.

-- 
  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 Sun Oct 31 07:51:33 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA56292
for <pgsql-hackers@postgreSQL.org>;
Sun, 31 Oct 1999 07:50:59 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id HAA25986
for pgsql-hackers@postgreSQL.org; Sun, 31 Oct 1999 07:50:09 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910311250.HAA25986@candle.pha.pa.us>
Subject: pgaccess 0.98
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Sun, 31 Oct 1999 07:50:09 -0500 (EST)
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 wrote:

Do we want to copy the entire pgaccess tree to the pgsql install
directory?

Why not? Of course, on UNIX systems without DLL's

OK, I have installed it in the current tree and stable tree. I will
keep pgaccess up-to-date in both trees in the future.

The tricky part is that pgaccess must know the 'wish' path that is
determined by configure, and the POSTGRESDIR path which comes from
Makefile.global, so I had to create a Makefile.in, and a pgaccess.sh.
Makefile.in is set a configure time, and pgaccess.sh is set at compile
time. The final script pgaccess has hardcoded in it the path to wish,
and the pgaccess directory inside the install directory.

The only problem I see is that wish is determined by a crude directory
search, while our tcl/tk stuff has the ability to target certain
versions of tcl/tk. Any idea how to do that cleanly? On my machine, I
get wish 7.6 because it see it in /usr/contrib/bin first, while for
tcl/tk I tell configure to look in /usr/local/lib first, so I get tck/tk
8.0.

I don't see a 'wish' path defined in any of the tck/tk config files.

I copied the entire pgaccess/lib and pgaccess/images trees into the
install directory. The other stuff seemed like it should stay just in
the source tree.

Would someone please test this?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Oct 31 08:17:33 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA58650
for <pgsql-hackers@postgreSQL.org>;
Sun, 31 Oct 1999 08:17:21 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id IAA29858;
Sun, 31 Oct 1999 08:15:12 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910311315.IAA29858@candle.pha.pa.us>
Subject: Re: [HACKERS] Serial and NULL values
In-Reply-To: <5277.941250520@sss.pgh.pa.us> from Tom Lane at "Oct 29,
1999 10:28:40 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 31 Oct 1999 08:15:12 -0500 (EST)
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

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

Offhand I don't see any fundamental reason why serial columns should
be restricted to be nonnull, but evidently someone did at some point.

The actual null is not the issue. The issue is that if we have a
SERIAL column, and we try to put a NULL in there, shouldn't it put the
default sequence number in there?

No, I wouldn't expect that at all. A default is inserted when you
don't supply anything at all for the column. Inserting an explicit
NULL means you want a NULL, and barring a NOT NULL constraint on
the column, that's what the system ought to insert. I can see no
possible justification for creating a type-specific exception to
that behavior.

If the original asker really wants to substitute something else for
an explicit null insertion, he could do it with a rule or a trigger.
But I don't think SERIAL ought to act that way all by itself.

OK, I see now. In Informix, if you insert 0 into a serial column, you
get the nextval assigned.

However, I can see that is not logical. We have serial which defines a
default for nextval().

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 Sun Oct 31 08:20:33 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA58778
for <pgsql-hackers@postgreSQL.org>;
Sun, 31 Oct 1999 08:19:55 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id IAA29898;
Sun, 31 Oct 1999 08:17:32 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910311317.IAA29898@candle.pha.pa.us>
Subject: Re: [HACKERS] Serial and NULL values
In-Reply-To: <m11hYgh-0003kLC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Oct 30, 1999 03:36:55 pm"
To: Jan Wieck <wieck@debis.com>
Date: Sun, 31 Oct 1999 08:17:32 -0500 (EST)
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

No, I wouldn't expect that at all. A default is inserted when you
don't supply anything at all for the column. Inserting an explicit
NULL means you want a NULL, and barring a NOT NULL constraint on
the column, that's what the system ought to insert. I can see no
possible justification for creating a type-specific exception to
that behavior.

If the original asker really wants to substitute something else for
an explicit null insertion, he could do it with a rule or a trigger.
But I don't think SERIAL ought to act that way all by itself.

regards, tom lane

I agree with tom.

If you don't want the user to be able to insert NULL, specify
NOT NULL explicitly. And if you want to force a default
behaviour, use a trigger (a rule can't do - sorry).

I thought Informix put the nextval with NULL, but I now see they do it
with zero, which is pretty strange.

Never mind.

-- 
  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 Sun Oct 31 09:43:34 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 JAA68044
for <pgsql-hackers@postgreSQL.org>;
Sun, 31 Oct 1999 09:43:00 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA32729;
Sun, 31 Oct 1999 15:26:51 +0100
Date: Sun, 31 Oct 1999 15:26:51 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Tom Lane <tgl@sss.pgh.pa.us>, Jan Wieck <wieck@debis.com>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Patch - Re: [HACKERS] view vs. inheritance hierarchy
In-Reply-To: <1922.941204864@sss.pgh.pa.us>
Message-ID: <Pine.LNX.3.96.991031151806.32618A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 29 Oct 1999, Tom Lane wrote:

Zakkr <zakkr@zf.jcu.cz> writes:

But the pg_get_ruledef() not discern contrast between view rules
defined as 'select * table' and rules defined as 'select * table*'
(the query should be run over all classes in the inheritance
hierarchy).

Is it a bug or a limitation?

Sounds like a bug to me too. The fix is probably just a small addition
of code, but I haven't had time to look into it.

regards, tom lane

Yes, I fix this bug. Here is my patch (for /src/backend/utils/adt/ruleutils)
for it:

*** ruleutils.c.org	Mon Sep  6 00:55:28 1999
--- ruleutils.c	Sun Sep 31 13:37:42 1999
***************
*** 968,971 ****
--- 968,973 ----
  				strcat(buf, "\"");
  				strcat(buf, rte->relname);
+ 				if (rte->inh)
+ 					strcat(buf, "*");
  				strcat(buf, "\"");
  				if (strcmp(rte->relname, rte->refname) != 0)
***************
*** 973,976 ****
--- 975,980 ----
  					strcat(buf, " \"");
  					strcat(buf, rte->refname);
+ 					if (rte->inh)
+ 						strcat(buf, "*");
  					strcat(buf, "\"");
  				}

Add we (Jan or Tom) this code to PostgreSQL source main? (Pease).

Karel

------------------------------------------------------------------------------
Karel Zak <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)
------------------------------------------------------------------------------

From bouncefilter Sun Oct 31 12:01: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 MAA85729
for <pgsql-hackers@postgreSQL.org>;
Sun, 31 Oct 1999 12:01:04 -0500 (EST)
(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 LAA20142;
Sun, 31 Oct 1999 11:59:58 -0500 (EST)
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
cc: Jan Wieck <wieck@debis.com>, pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: Patch - Re: [HACKERS] view vs. inheritance hierarchy
In-reply-to: Your message of Sun, 31 Oct 1999 15:26:51 +0100 (CET)
<Pine.LNX.3.96.991031151806.32618A-100000@ara.zf.jcu.cz>
Date: Sun, 31 Oct 1999 11:59:58 -0500
Message-ID: <20140.941389198@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Karel Zak - Zakkr <zakkr@zf.jcu.cz> writes:

*** ruleutils.c.org	Mon Sep  6 00:55:28 1999
--- ruleutils.c	Sun Sep 31 13:37:42 1999
***************
*** 968,971 ****
--- 968,973 ----
strcat(buf, "\"");
strcat(buf, rte->relname);
+ 				if (rte->inh)
+ 					strcat(buf, "*");
strcat(buf, "\"");
if (strcmp(rte->relname, rte->refname) != 0)
***************
*** 973,976 ****
--- 975,980 ----
strcat(buf, " \"");
strcat(buf, rte->refname);
+ 					if (rte->inh)
+ 						strcat(buf, "*");
strcat(buf, "\"");
}

Add we (Jan or Tom) this code to PostgreSQL source main? (Pease).

That looks about like the right thing to do, but I wonder whether the
"*" doesn't need to go *outside* the quote marks around the table name?
Seems like it would be taken as a name character if inside...

regards, tom lane

From bouncefilter Sun Oct 31 14:34:37 1999
Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194])
by hub.org (8.9.3/8.9.3) with SMTP id OAA02903
for <pgsql-hackers@postgresql.org>;
Sun, 31 Oct 1999 14:34:27 -0500 (EST)
(envelope-from akorud@polynet.lviv.ua)
Received: (qmail 81086 invoked from network); 31 Oct 1999 19:34:24 -0000
Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown)
by unknown with SMTP; 31 Oct 1999 19:34:24 -0000
Received: (qmail 42550 invoked from network); 31 Oct 1999 19:34:23 -0000
Received: (ofmipd unknown); 31 Oct 1999 19:34:01 -0000
Date: 31 Oct 1999 21:34:23 +0200
Message-ID: <Pine.BSF.3.96.991031213049.42375A-100000@NetSurfer.lp.lviv.ua>
From: "Andrij Korud" <akorud@polynet.lviv.ua>
To: pgsql-hackers@postgresql.org
X-Sender: akorud@NetSurfer.lp.lviv.ua
Subject: Trigger aborted on error
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi.
I've such problem :
I table with primary key and in trigger try to insert into this table data
wich violate constrain (not uniq). When ectually executing SPI_execp I got
a message "ERROR: cannot insert a duplicate key into a unique index" and
trigger executing is aborted. What should I do in order to get this error
as a result from SPI_execp and continue trigger execution?

Thanks in advance,
Andriy Korud, Lviv, Ukraine

From bouncefilter Sun Oct 31 15:32: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 PAA12214
for <pgsql-hackers@postgresql.org>;
Sun, 31 Oct 1999 15:31:59 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id PAA01489;
Sun, 31 Oct 1999 15:31:19 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910312031.PAA01489@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess 0.98
In-Reply-To: <99103116314000.00631@lorc.wgcr.org> from Lamar Owen at "Oct 31,
1999 04:29:21 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Sun, 31 Oct 1999 15:31:19 -0500 (EST)
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 Sun, 31 Oct 1999, Bruce Momjian wrote:

Would someone please test this?

If I can figure out how (or if someone will tell me how) to check out the
6.5.3-candidate tree, I'll be glad to. After all, I've got to get a jump on
the RPM's for 6.5.3.

The developement tree has the same treatment, though I would like to
have the stable tree checked too.

I seem to mess this area up often.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Sun Oct 31 15:35: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 PAA12479
for <pgsql-hackers@postgreSQL.org>;
Sun, 31 Oct 1999 15:35:00 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id PAA03283
for pgsql-hackers@postgreSQL.org; Sun, 31 Oct 1999 15:34:23 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910312034.PAA03283@candle.pha.pa.us>
Subject: pgaccess 0.98
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Sun, 31 Oct 1999 15:34:23 -0500 (EST)
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 re-done pgaccess again, both trees.

Because wish is configured via a path search, I moved the WISH= line
into Makefile.global, so people can change it easily there, or in
Makefile.custom. Having in embedded in pgaccess/Makefile was too
goofey.

There is no pgaccess/Makefile.in anymore. It gets its WISH from
Makefile.global, like PERL gets defined.

-- 
  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 Sun Oct 31 15:47: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 PAA14391
for <pgsql-hackers@postgreSQL.org>;
Sun, 31 Oct 1999 15:47:17 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id PAA06863
for pgsql-hackers@postgreSQL.org; Sun, 31 Oct 1999 15:46:40 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910312046.PAA06863@candle.pha.pa.us>
Subject: pgaccess 0.98
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Sun, 31 Oct 1999 15:46:40 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

OK, my 6.5.3 cvs copy works fine for pgaccess.

Actually, we never installed pgaccess this cleanly in earlier releases.

-- 
  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 Sun Oct 31 15:53: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 PAA15067
for <pgsql-hackers@postgresql.org>;
Sun, 31 Oct 1999 15:53:35 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id PAA07520;
Sun, 31 Oct 1999 15:52:54 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910312052.PAA07520@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess 0.98
In-Reply-To: <99103116483601.00631@lorc.wgcr.org> from Lamar Owen at "Oct 31,
1999 04:45:34 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Sun, 31 Oct 1999 15:52:54 -0500 (EST)
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 Sun, 31 Oct 1999, Bruce Momjian wrote:

On Sun, 31 Oct 1999, Bruce Momjian wrote:

Would someone please test this?

If I can figure out how (or if someone will tell me how) to check out the
6.5.3-candidate tree, I'll be glad to. After all, I've got to get a jump on
the RPM's for 6.5.3.

The developement tree has the same treatment, though I would like to
have the stable tree checked too.

I seem to mess this area up often.

As I will be building RPM's for both trees eventually, I am in the midst of a
dual-branch checkout. Painful over my home's 33.6K modem, but necessary.

I did (am doing, actually) a cvs checkout with -r REL6_5 -- that is the correct
tag for the stable branch, right??

Sadly, no. It is REL6_5_PATCHES.

-- 
  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 Sun Oct 31 15:55: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 PAA15183
for <pgsql-hackers@postgresql.org>;
Sun, 31 Oct 1999 15:54:50 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id PAA10357;
Sun, 31 Oct 1999 15:54:09 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199910312054.PAA10357@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess 0.98
In-Reply-To: <99103116483601.00631@lorc.wgcr.org> from Lamar Owen at "Oct 31,
1999 04:45:34 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Sun, 31 Oct 1999 15:54:09 -0500 (EST)
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 Sun, 31 Oct 1999, Bruce Momjian wrote:

On Sun, 31 Oct 1999, Bruce Momjian wrote:

Would someone please test this?

If I can figure out how (or if someone will tell me how) to check out the
6.5.3-candidate tree, I'll be glad to. After all, I've got to get a jump on
the RPM's for 6.5.3.

The developement tree has the same treatment, though I would like to
have the stable tree checked too.

I seem to mess this area up often.

As I will be building RPM's for both trees eventually, I am in the midst of a
dual-branch checkout. Painful over my home's 33.6K modem, but necessary.

I did (am doing, actually) a cvs checkout with -r REL6_5 -- that is the correct
tag for the stable branch, right??

You may want to skip the separate pgaccess rpm now. I have wish found
via configure, and the support files loaded into the install directory
under pgaccess/, and the pgaccess startup script pointing there, so
there isn't any more manual handling of pgaccess.

It should just install and work 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 Sun Oct 31 15:30:38 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 PAA12109
for <pgsql-hackers@postgresql.org>;
Sun, 31 Oct 1999 15:30:32 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org ([207.144.78.5])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id PAA06697;
Sun, 31 Oct 1999 15:30:34 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] pgaccess 0.98
Date: Sun, 31 Oct 1999 16:29:21 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910311250.HAA25986@candle.pha.pa.us>
In-Reply-To: <199910311250.HAA25986@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <99103116314000.00631@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Sun, 31 Oct 1999, Bruce Momjian wrote:

Would someone please test this?

If I can figure out how (or if someone will tell me how) to check out the
6.5.3-candidate tree, I'll be glad to. After all, I've got to get a jump on
the RPM's for 6.5.3.

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

From bouncefilter Sun Oct 31 16:41:39 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id QAA21410
for <pgsql-hackers@postgreSQL.org>;
Sun, 31 Oct 1999 16:41:28 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11i2ap-0003kLC; Sun, 31 Oct 99 22:32 MET
Message-Id: <m11i2ap-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Trigger aborted on error
To: akorud@polynet.lviv.ua (Andrij Korud)
Date: Sun, 31 Oct 1999 22:32:51 +0100 (MET)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <Pine.BSF.3.96.991031213049.42375A-100000@NetSurfer.lp.lviv.ua>
from "Andrij Korud" at Oct 31, 99 09:34:23 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Hi.
I've such problem :
I table with primary key and in trigger try to insert into this table data
wich violate constrain (not uniq). When ectually executing SPI_execp I got
a message "ERROR: cannot insert a duplicate key into a unique index" and
trigger executing is aborted. What should I do in order to get this error
as a result from SPI_execp and continue trigger execution?

Thanks in advance,
Andriy Korud, Lviv, Ukraine

No chance, ERROR messages cannot be caught in any way by a
trigger. They abort the entire transaction.

The only possibility you have is to check via SELECT prior to
the INSERT. Unfortunately you would need an exclusive table
lock to avoid race conditions.

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 Sun Oct 31 16:34:39 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id QAA20573
for pgsql-hackers@postgresql.org; Sun, 31 Oct 1999 16:34:16 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: "gov-boi" <gov-boi@hack.co.za>
X-Newsgroups: alt.music.cracker-cvb, alt.nl.binaries.hack,
alt.recovery.codependency, alt.source-code.mac,
borland.public.codecentral, chinese.text.unicode,
comp.databases.postgresql.hackers, comp.databases.xbase.codebase,
comp.hackers, comp.sys.mac.programmer.codewarr
Subject: exploit update.
Date: Sun, 31 Oct 1999 23:33:07 +0200
Lines: 14
X-Newsreader: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Message-ID: <381cb5c1.0@news1.mweb.co.za>
X-Trace: 31 Oct 1999 23:33:53 +0200, 196.2.156.107
To: pgsql-hackers@postgreSQL.org

www.hack.co.za has been updated today.

[[-Sun 31 October-]]
Added sendmail-8.9.3.tar.gz by icesk. (0-day!)
Added sperl4.036.c FreeBSD 2.2.8 exploit by OVX. (old exploit)
Added tcpdump.c Linux/misc exploit BLADI. (old exploit)
Fixed up the CGI section, thanks to dv8 for submitting the bug. (lots of
500 errors)
Fixed OS colour scheme and exploit outlay. (took hours to do)
Fixed frame border outlays. (invisible now)

++gb

From bouncefilter Sun Oct 31 15:48:38 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 PAA14434
for <pgsql-hackers@postgresql.org>;
Sun, 31 Oct 1999 15:48:14 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org ([207.144.78.5])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id PAA06728;
Sun, 31 Oct 1999 15:47:59 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess 0.98
Date: Sun, 31 Oct 1999 16:45:34 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <199910312031.PAA01489@candle.pha.pa.us>
In-Reply-To: <199910312031.PAA01489@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <99103116483601.00631@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Sun, 31 Oct 1999, Bruce Momjian wrote:

On Sun, 31 Oct 1999, Bruce Momjian wrote:

Would someone please test this?

If I can figure out how (or if someone will tell me how) to check out the
6.5.3-candidate tree, I'll be glad to. After all, I've got to get a jump on
the RPM's for 6.5.3.

The developement tree has the same treatment, though I would like to
have the stable tree checked too.

I seem to mess this area up often.

As I will be building RPM's for both trees eventually, I am in the midst of a
dual-branch checkout. Painful over my home's 33.6K modem, but necessary.

I did (am doing, actually) a cvs checkout with -r REL6_5 -- that is the correct
tag for the stable branch, right??

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

From bouncefilter Sun Oct 31 15:59:38 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 PAA16017
for <pgsql-hackers@postgresql.org>;
Sun, 31 Oct 1999 15:59:26 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org ([207.144.78.5])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id PAA06757;
Sun, 31 Oct 1999 15:59:06 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess 0.98
Date: Sun, 31 Oct 1999 16:57:18 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <199910312052.PAA07520@candle.pha.pa.us>
In-Reply-To: <199910312052.PAA07520@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <99103117000102.00631@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Sun, 31 Oct 1999, Bruce Momjian wrote:

I did (am doing, actually) a cvs checkout with -r REL6_5 -- that is the correct
tag for the stable branch, right??

Sadly, no. It is REL6_5_PATCHES.

I'm glad for the quick reply. I aborted the REL6_5 co, and am now checking out
REL6_5_PATCHES. It'll just take a half hour to do the checkout (I miss my T1
at work right about now....)

Thanks!

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

From bouncefilter Sun Oct 31 16:47:39 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 QAA22027
for <pgsql-hackers@postgreSQL.org>;
Sun, 31 Oct 1999 16:46:43 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org ([207.144.78.5])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id QAA06822;
Sun, 31 Oct 1999 16:46:15 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] pgaccess 0.98
Date: Sun, 31 Oct 1999 17:43:49 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199910312046.PAA06863@candle.pha.pa.us>
In-Reply-To: <199910312046.PAA06863@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <99103117465803.00631@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Sun, 31 Oct 1999, Bruce Momjian wrote:

OK, my 6.5.3 cvs copy works fine for pgaccess.

Actually, we never installed pgaccess this cleanly in earlier releases.

Which is why previous RPM's had such special handling for pgaccess. Your
changes are going to hopefully make things much easier on the RPM side. I'll
know here in a little while.

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

From bouncefilter Mon Nov 1 17:47: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 RAA19075
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 17:47:05 -0500 (EST)
(envelope-from peter@peter-e.yi.org)
Received: from uria.its.uu.se ([130.238.7.14]:1413 "EHLO peter-e.yi.org") by
merganser.its.uu.se with ESMTP id <S.s5VVO94573>;
Mon, 1 Nov 1999 23:46:50 +0100
Received: from peter (helo=localhost)
by peter-e.yi.org with local-esmtp (Exim 3.02 #2)
id 11i4fz-0000C1-00; Mon, 01 Nov 1999 00:46:19 +0100
Date: Mon, 1 Nov 1999 00:46:19 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Jan Wieck <wieck@debis.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>, maillist@candle.pha.pa.us,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
In-Reply-To: <m11hfKb-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.LNX.4.10.9911010039520.342-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 30, Jan Wieck mentioned:

Right. A major release is what it is. And porting
applications to a new major release too, it is a conversion,
not an upgrade. Therefore a major release should drop as much
backward compatibility code for minor releases as possible.

Certainly true. But that would also mean that we'd have to keep
maintaining the 6.* series as well. At least bug-fixing and releasing one
or two more 6.5.x versions. Up until now the usual answer to a bug was
"upgrade to latest version". But if you break compatibility you can't do
that any more. (Compare to Linux 2.0 vs 2.2) I'm just wondering what the
plans are in that regard.

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

From bouncefilter Sun Oct 31 22:05:42 1999
Received: from argh.demon.co.uk (IDENT:grim@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA57692
for <pgsql-hackers@postgreSQL.org>;
Sun, 31 Oct 1999 22:05:20 -0500 (EST)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id EAA02314
for pgsql-hackers@postgreSQL.org; Mon, 1 Nov 1999 04:12:09 GMT
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199911010412.EAA02314@argh.demon.co.uk>
Subject: Backend crashes (6.5.2 linux)
To: pgsql-hackers@postgreSQL.org
Date: Mon, 1 Nov 1999 04:12:09 +0000 (GMT)
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

I am seeing the backend crash on a table I am using for a
searchengine, and I cannot find any answers with the list archives.

Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66]

type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: search

search=> update search_url set stale=941424005 where lowerurl='http://criswell.bizland.com&#39;;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is impossible. Terminating.

psql search
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66]

type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: search

search=> select count(*) from search_url;
count
-----
20334
(1 row)

The postmaster stderr says:

/usr/bin/postmaster: reaping dead processes...
/usr/bin/postmaster: CleanupProc: pid 9788 exited with status 0
FATAL 1: my bits moved right off the end of the world!
/usr/bin/postmaster: reaping dead processes...
/usr/bin/postmaster: CleanupProc: pid 9792 exited with status 0

The postmaster stdout says:

StartTransactionCommand
ProcessQuery
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
CommitTransactionCommand

The stdout IS moving by very quickly so I cant be sure this message matches up
with this error, but it certainly seems to (all the rest are
CommitTransactionCommand/StartTransactionCommand/ProcessQuery)

My biggest problem is that I am using the C libraries, and PQexec()
does not return, gdb shows it is sitting in a select() inside
#0 0xc91954e in __select ()
#1 0xc851428 in pgresStatus ()
#2 0xc84a9ea in PQgetResult ()
#3 0xc84ab77 in PQexec ()

and it hangs there forever (well, 10 minutes so far)

Now, the line I am doing an update on, I can select quite happily, and
it returns the value I expect.

Extra info:
#uname -a
Linux ewtoo.org 2.2.12 #2 SMP Fri Oct 1 21:50:14 BST 1999 i686 unknown

#free -k
total used free shared buffers cached
Mem: 387476 381112 6364 761628 52904 166224
-/+ buffers/cache: 161984 225492
Swap: 526168 19816 506352

Anyone else seen this?

~Michael

From bouncefilter Mon Nov 1 00:44: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 AAA77970
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 00:44:14 -0500 (EST)
(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 AAA28439;
Mon, 1 Nov 1999 00:43:25 -0500 (EST)
To: Michael Simms <grim@argh.demon.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Backend crashes (6.5.2 linux)
In-reply-to: Your message of Mon, 1 Nov 1999 04:12:09 +0000 (GMT)
<199911010412.EAA02314@argh.demon.co.uk>
Date: Mon, 01 Nov 1999 00:43:24 -0500
Message-ID: <28437.941435004@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Michael Simms <grim@argh.demon.co.uk> writes:

The postmaster stderr says:
FATAL 1: my bits moved right off the end of the world!

Hmm. That error is coming out of the btree index code. Vadim knows
that code better than anyone else, so he might have something to say
here, but my past-midnight recollection is that we've seen that error
being triggered when there are oversize entries in the index (where
"oversize" = "more than half a disk page"). It's a bug, for sure,
but what you probably want right now is a workaround. Do you have any
entries in indexed columns that are over 4K, and can you get rid of them?

My biggest problem is that I am using the C libraries, and PQexec()
does not return, gdb shows it is sitting in a select() inside
#0 0xc91954e in __select ()
#1 0xc851428 in pgresStatus ()
#2 0xc84a9ea in PQgetResult ()
#3 0xc84ab77 in PQexec ()

Huh? PQgetResult does not call pgresStatus ... not least because the
latter is an array, not a function. Your gdb is lying to you. Maybe
you have a problem with gdb looking at a different version of the
library than what's actually executing?

regards, tom lane

From bouncefilter Mon Nov 1 00:55: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 AAA79336
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 00:54:50 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id AAA29310;
Mon, 1 Nov 1999 00:53:36 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911010553.AAA29310@candle.pha.pa.us>
Subject: Re: [HACKERS] Backend crashes (6.5.2 linux)
In-Reply-To: <28437.941435004@sss.pgh.pa.us> from Tom Lane at "Nov 1,
1999 00:43:24 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 1 Nov 1999 00:53:36 -0500 (EST)
CC: Michael Simms <grim@argh.demon.co.uk>, 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

Michael Simms <grim@argh.demon.co.uk> writes:

The postmaster stderr says:
FATAL 1: my bits moved right off the end of the world!

That's my favorite error message. Can we make it print more often?
Pru-Hahaha... :-)

-- 
  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 Nov 1 01:18: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 BAA82235
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 01:18:24 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id BAA00953
for pgsql-hackers@postgreSQL.org; Mon, 1 Nov 1999 01:17:45 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911010617.BAA00953@candle.pha.pa.us>
Subject: Datestyle
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 1 Nov 1999 01:17:45 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Is this correct?

test=> SET DATESTYLE = 'European';
SET VARIABLE
test=> SELECT date('2/1/1983'::date);
date
----------
02-01-1983
(1 row)

I have found US, Postgres, European, and NonEuropean as showing the same
date output. Is that correct?

-- 
  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 Nov 1 01:20: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 BAA82599
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 01:20:43 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id BAA01175
for pgsql-hackers@postgreSQL.org; Mon, 1 Nov 1999 01:20:02 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911010620.BAA01175@candle.pha.pa.us>
Subject: DateStyle
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 1 Nov 1999 01:20:02 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I see now. The input is reversed in and out, so it looks the same when
it is different. Never mind.

-- 
  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 Nov 1 01:35:57 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 BAA84528
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 01:35:35 -0500 (EST)
(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 PAA02302;
Mon, 1 Nov 1999 15:35:33 +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 PAA26145;
Mon, 1 Nov 1999 15:35:33 +0900 (JST)
Message-Id: <199911010635.PAA26145@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 Sat, 30 Oct 1999 13:37:10 -0400.
<14048.941305030@sss.pgh.pa.us>
Date: Mon, 01 Nov 1999 15:35:33 +0900
Sender: t-ishii@srapc451.sra.co.jp

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

It worked with 2GB+ table but was much slower than before.
Before(with 8MB sort memory): 22 minutes
After(with 8MB sort memory): 1 hour and 5 minutes
After(with 80MB sort memory): 42 minutes.

I've committed some changes to tuplesort.c to try to improve
performance. Would you try your test case again with current
sources? Also, please see if you can record the CPU time
consumed by the backend while doing the sort.

It's getting better, but still slower than before.

52:50 (with 8MB sort memory)

ps shows 7:15 was consumed by the backend. I'm going to test with 80MB
sort memory.
--
Tatsuo Ishii

From bouncefilter Mon Nov 1 02:02:57 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 CAA87804
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 02:02:32 -0500 (EST)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id OAA08115;
Mon, 1 Nov 1999 14:02:05 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <381D3AEC.C9EA7FBF@krs.ru>
Date: Mon, 01 Nov 1999 14:02:04 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Michael Simms <grim@argh.demon.co.uk>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Backend crashes (6.5.2 linux)
References: <28437.941435004@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Michael Simms <grim@argh.demon.co.uk> writes:

The postmaster stderr says:
FATAL 1: my bits moved right off the end of the world!

Hmm. That error is coming out of the btree index code. Vadim knows
that code better than anyone else, so he might have something to say
here, but my past-midnight recollection is that we've seen that error
being triggered when there are oversize entries in the index (where
"oversize" = "more than half a disk page"). It's a bug, for sure,
but what you probably want right now is a workaround. Do you have any
entries in indexed columns that are over 4K, and can you get rid of them?

This FATAL means that index is broken (some prev insertion
was interrupted by elog(ERROR) or backend crash) - try to rebuild...
WAL should fix this bug.

Vadim

From bouncefilter Mon Nov 1 02:04:56 1999
Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194])
by hub.org (8.9.3/8.9.3) with SMTP id CAA87893
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 02:04:03 -0500 (EST)
(envelope-from akorud@polynet.lviv.ua)
Received: (qmail 23495 invoked from network); 1 Nov 1999 07:03:57 -0000
Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown)
by unknown with SMTP; 1 Nov 1999 07:03:57 -0000
Received: (qmail 77845 invoked from network); 1 Nov 1999 07:03:56 -0000
Received: (ofmipd unknown); 1 Nov 1999 07:03:34 -0000
Date: 1 Nov 1999 09:03:56 +0200
Message-ID: <Pine.BSF.3.96.991101085312.76608B-100000@NetSurfer.lp.lviv.ua>
From: "Andrij Korud" <akorud@polynet.lviv.ua>
To: "Jan Wieck" <wieck@debis.com>
Cc: pgsql-hackers@postgreSQL.org
X-Sender: akorud@NetSurfer.lp.lviv.ua
Subject: Re: [HACKERS] Trigger aborted on error
In-Reply-To: <m11i2ap-0003kLC@orion.SAPserv.Hamburg.dsh.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 31 Oct 1999, Jan Wieck wrote:

Hi.
I've such problem :
I table with primary key and in trigger try to insert into this table data
wich violate constrain (not uniq). When ectually executing SPI_execp I got
a message "ERROR: cannot insert a duplicate key into a unique index" and
trigger executing is aborted. What should I do in order to get this error
as a result from SPI_execp and continue trigger execution?

Thanks in advance,
Andriy Korud, Lviv, Ukraine

No chance, ERROR messages cannot be caught in any way by a
trigger. They abort the entire transaction.

The only possibility you have is to check via SELECT prior to
the INSERT. Unfortunately you would need an exclusive table
lock to avoid race conditions.

Jan

Let's make another question: Is there some way to insert uniq data into
table without first cheking using SELECT. Because this table contain >1M
records and SELECT on it is very slow. If there is no way of doing it I
should consider moving from Postgres to other database :(

Andriy Korud

From bouncefilter Mon Nov 1 02:10:58 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 CAA88940
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 02:10:30 -0500 (EST)
(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 QAA04447;
Mon, 1 Nov 1999 16:10:28 +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 QAA26682;
Mon, 1 Nov 1999 16:10:28 +0900 (JST)
Message-Id: <199911010710.QAA26682@srapc451.sra.co.jp>
To: t-ishii@sra.co.jp
cc: Tom Lane <tgl@sss.pgh.pa.us>, 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 Mon, 01 Nov 1999 15:35:33 JST.
<199911010635.PAA26145@srapc451.sra.co.jp>
Date: Mon, 01 Nov 1999 16:10:27 +0900
Sender: t-ishii@srapc451.sra.co.jp

It worked with 2GB+ table but was much slower than before.
Before(with 8MB sort memory): 22 minutes
After(with 8MB sort memory): 1 hour and 5 minutes
After(with 80MB sort memory): 42 minutes.

I've committed some changes to tuplesort.c to try to improve
performance. Would you try your test case again with current
sources? Also, please see if you can record the CPU time
consumed by the backend while doing the sort.

It's getting better, but still slower than before.

52:50 (with 8MB sort memory)

ps shows 7:15 was consumed by the backend. I'm going to test with 80MB
sort memory.

Done.

32:06 (with 80MB sort memory)
CPU time was 5:11.
--
Tatsuo Ishii

From bouncefilter Mon Nov 1 02:23:56 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 CAA90479
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 02:23:42 -0500 (EST)
(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 QAA05241
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 16:23:40 +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 QAA26801 for
<pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 16:23:40 +0900 (JST)
Message-Id: <199911010723.QAA26801@srapc451.sra.co.jp>
From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: pgsql-hackers@postgreSQL.org
Subject: Log on separate disk?
Date: Mon, 01 Nov 1999 16:23:40 +0900
Sender: t-ishii@srapc451.sra.co.jp

I think it's essential in WAL to have log files(s) on separate disk
drives to recover database while a drive which keeps tables on it
crashes. How could we do this on 7.0?
--
Tatsuo Ishii

From bouncefilter Mon Nov 1 02:53:19 1999
Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194])
by hub.org (8.9.3/8.9.3) with SMTP id CAA93420
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 02:51:57 -0500 (EST)
(envelope-from akorud@polynet.lviv.ua)
Received: (qmail 27386 invoked from network); 1 Nov 1999 07:51:52 -0000
Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown)
by unknown with SMTP; 1 Nov 1999 07:51:52 -0000
Received: (qmail 80978 invoked from network); 1 Nov 1999 07:51:52 -0000
Received: (ofmipd unknown); 1 Nov 1999 07:51:30 -0000
Date: 1 Nov 1999 09:51:51 +0200
Message-ID: <NCBBINEHHJGEONJEMFOIMECFDAAA.akorud@polynet.lviv.ua>
From: "Andrij Korud" <akorud@polynet.lviv.ua>
To: pgsql-hackers@postgreSQL.org
Subject: Getting oid of just inserted record
MIME-Version: 1.0
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi,
I there any way to get an oid of just inserted by (SPI_execp) record without
doing SELECT?

Thanks in advance,
Andriy Korud, Lviv, Ukriane

From bouncefilter Mon Nov 1 04:25: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 EAA06695
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 04:25:33 -0500 (EST)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id KAA12410;
Mon, 1 Nov 1999 10:09:51 +0100
Date: Mon, 1 Nov 1999 10:09:51 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: Patch - Re: [HACKERS] view vs. inheritance hierarchy
In-Reply-To: <20140.941389198@sss.pgh.pa.us>
Message-ID: <Pine.LNX.3.96.991101095155.11387B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 31 Oct 1999, Tom Lane wrote:

That looks about like the right thing to do, but I wonder whether the
"*" doesn't need to go *outside* the quote marks around the table name?
Seems like it would be taken as a name character if inside...

grrr! - it is (my) novice's idiocy...

Sorry Tom, I forget that between the quote is the table name.. next time I
first test & check my patches :-) Now is it good? (I test it this time.)

Karel

*** ruleutils.c.org	Mon Sep  6 00:55:28 1999
--- ruleutils.c	Mon Nov  1 09:26:03 1999
***************
*** 969,972 ****
--- 969,974 ----
  				strcat(buf, rte->relname);
  				strcat(buf, "\"");
+ 				if (rte->inh)
+ 					strcat(buf, "*");
  				if (strcmp(rte->relname, rte->refname) != 0)
  				{
***************
*** 974,977 ****
--- 976,981 ----
  					strcat(buf, rte->refname);
  					strcat(buf, "\"");
+ 					if (rte->inh)
+ 						strcat(buf, "*");
  				}
  			}

From bouncefilter Mon Nov 1 06:55:59 1999
Received: from druid.net (root@druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA24303
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 06:55:44 -0500 (EST)
(envelope-from darcy@druid.net)
Received: from localhost (1733 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m11iG3Q-0000bFC@druid.net>
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 06:55:16 -0500 (EST)
(Smail-3.2.0.104 1998-Nov-20 #4 built 1999-Apr-13)
Message-Id: <m11iG3Q-0000bFC@druid.net>
Subject: Re: [HACKERS] Trigger aborted on error
In-Reply-To: <Pine.BSF.3.96.991101085312.76608B-100000@NetSurfer.lp.lviv.ua>
from Andrij Korud at "Nov 1, 1999 09:03:56 am"
To: akorud@polynet.lviv.ua (Andrij Korud)
Date: Mon, 1 Nov 1999 06:55:16 -0500 (EST)
From: "D'Arcy" "J.M." Cain <darcy@druid.net>
Cc: wieck@debis.com, 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 Andrij Korud

The only possibility you have is to check via SELECT prior to
the INSERT. Unfortunately you would need an exclusive table
lock to avoid race conditions.

Let's make another question: Is there some way to insert uniq data into
table without first cheking using SELECT. Because this table contain >1M
records and SELECT on it is very slow. If there is no way of doing it I
should consider moving from Postgres to other database :(

Have you put an index on the field in question? It shouldn't matter how
many records you have if you do. If you don't, no other database will
help you any better.

The following declaration will create the field, give it the default
and put a unique index on it. How are you declaring the field now?

CREATE TABLE t (pk SERIAL PRIMARY KEY, ...

-- 
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 Mon Nov 1 09:54:01 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 JAA45877
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 09:53:38 -0500 (EST)
(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 JAA01471;
Mon, 1 Nov 1999 09:52:32 -0500 (EST)
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: Patch - Re: [HACKERS] view vs. inheritance hierarchy
In-reply-to: Your message of Mon, 1 Nov 1999 10:09:51 +0100 (CET)
<Pine.LNX.3.96.991101095155.11387B-100000@ara.zf.jcu.cz>
Date: Mon, 01 Nov 1999 09:52:32 -0500
Message-ID: <1469.941467952@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Karel Zak - Zakkr <zakkr@zf.jcu.cz> writes:

*** ruleutils.c.org	Mon Sep  6 00:55:28 1999
--- ruleutils.c	Mon Nov  1 09:26:03 1999
***************
*** 969,972 ****
--- 969,974 ----
strcat(buf, rte->relname);
strcat(buf, "\"");
+ 				if (rte->inh)
+ 					strcat(buf, "*");
if (strcmp(rte->relname, rte->refname) != 0)
{

I applied this part --- I don't think adding a second '*' after the
refname is correct.

regards, tom lane

From bouncefilter Mon Nov 1 10:10:01 1999
Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194])
by hub.org (8.9.3/8.9.3) with SMTP id KAA48201
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 10:09:24 -0500 (EST)
(envelope-from akorud@polynet.lviv.ua)
Received: (qmail 70906 invoked from network); 1 Nov 1999 15:09:16 -0000
Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown)
by unknown with SMTP; 1 Nov 1999 15:09:16 -0000
Received: (qmail 16364 invoked from network); 1 Nov 1999 15:09:16 -0000
Received: (ofmipd unknown); 1 Nov 1999 15:08:54 -0000
Date: 1 Nov 1999 17:09:15 +0200
Message-ID: <NCBBINEHHJGEONJEMFOIKECODAAA.akorud@polynet.lviv.ua>
From: "Andrij Korud" <akorud@polynet.lviv.ua>
To: pgsql-hackers@postgreSQL.org
Subject: Whos idea was this
MIME-Version: 1.0
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hey, I just found that if I "BEGIN", making a lot of inserts (1000) and on
1001 insert I get an error (for example "duplicate key") ALL prev 1000
insertes I LOST.
Give me please author of this %$%$^&%# idea!!! It's really STUPID.

Andriy Korud, Lviv, Ukraine
P.S. Sorry for this letter but I'm really angy. Can postgres give me the way
to store uniq data in datable without checking before each insert if this
data alredy exist or no. Why it cannot give me error about duplicate keys
which I will (or will not) take in care.

From bouncefilter Mon Nov 1 10:43:02 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 KAA53006
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 10:42:35 -0500 (EST)
(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 KAA01682;
Mon, 1 Nov 1999 10:42:00 -0500 (EST)
To: t-ishii@sra.co.jp
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
In-reply-to: Your message of Mon, 01 Nov 1999 16:10:27 +0900
<199911010710.QAA26682@srapc451.sra.co.jp>
Date: Mon, 01 Nov 1999 10:42:00 -0500
Message-ID: <1680.941470920@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

It worked with 2GB+ table but was much slower than before.
Before(with 8MB sort memory): 22 minutes
After(with 8MB sort memory): 1 hour and 5 minutes
After(with 80MB sort memory): 42 minutes.

It's getting better, but still slower than before.
52:50 (with 8MB sort memory)
ps shows 7:15 was consumed by the backend.
32:06 (with 80MB sort memory)
CPU time was 5:11.

OK, so it's basically all I/O time, which is what I suspected.

What's causing this is the changes I made to reduce disk space usage;
the price of that savings is more-random access to the temporary file.
Apparently your setup is not coping very well with that.

The original code used seven separate temp files, each of which was
written and read in a purely sequential fashion. Only problem: as
the merge steps proceed, all the data is read from one temp file and
dumped into another, and because of the way the merges are overlapped,
you end up with total space usage around 4X the actual data volume.

What's in there right now is just the same seven-tape merge algorithm,
but all the "tapes" are stored in a single temp file. As soon as any
block of a "tape" is read in, it's recycled to become available space
for the current "output tape" (since we know we won't need to read that
block again). This is why the disk space usage is roughly actual data
volume and not four times as much. However, the access pattern to this
single temp file looks a lot more random to the OS than the access
patterns for the original temp files.

I figured that I could get away with this from a performance standpoint
because, while the old code processed each temp file sequentially, the
read and write accesses were interleaved --- on average, you'd expect
a merge pass to read one block from each of the N source tapes in the
same time span that it is writing N blocks to the current output tape;
on average, no two successive block read or write requests will go to
the same temp file. So it appears to me that the old code should cause
a disk seek for each block read or written. The new code's behavior
can't be any worse than that; it's just doing those seeks within one
temp file instead of seven.

Of course the flaw in this reasoning is that it assumes the OS isn't
getting in the way. On the HPUX system I've been testing on, the
performance does seem to be about the same, but evidently it's much
worse on your system. (Exactly what OS are you running, anyway, and
on what hardware?) I speculate that your OS is applying some sort of
read-ahead algorithm that is getting hopelessly confused by lots of
seeks within a single file. Perhaps it's reading the next block in
sequence after every program-requested read, and then throwing away that
work when it sees the program lseek the file instead of reading.

Next question is what to do about it. I don't suppose we have any way
of turning off the OS' read-ahead algorithm :-(. We could forget about
this space-recycling improvement and go back to separate temp files.
The objection to that, of course, is that while sorting might be faster,
it doesn't matter how fast the algorithm is if you don't have the disk
space to execute it.

A possible compromise is to use separate temp files but drop the
polyphase merge and go to a balanced merge, which'd still access each
temp file sequentially but would have only a 2X space penalty instead of
4X (since all the data starts on one set of tapes and gets copied to the
other set during a complete merge pass). The balanced merge is a little
slower than polyphase --- more merge passes --- but the space savings
probably justify it.

One thing I'd like to know before we make any decisions is whether
this problem is widespread. Can anyone else run performance tests
of the speed of large sorts, using current sources vs. 6.5.* ?

regards, tom lane

From bouncefilter Mon Nov 1 10:57:02 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 KAA54965
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 10:56:27 -0500 (EST)
(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 SAA81835
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 18:55:53 +0300 (MSK)
Message-ID: <13a501bf2481$794661a0$0d8cdac3@aktrad.ru>
From: "Gene Sokolov" <hook@aktrad.ru>
To: <pgsql-hackers@postgreSQL.org>
Subject: file descriptors leak?
Date: Mon, 1 Nov 1999 18:55:07 +0300
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

Seems like there is (was) a leak of file descriptors somewhere. The
descriptors are being used up like crazy. After a week of work on a small
database (6 tables, 20 or so indexes) Postgres used up well over 800
descriptors. Is this something known/fixed?

[PostgreSQL 6.6.0 on i386-unknown-freebsd3.2, compiled by gcc 2.7.2.1]

downloaded and built about the time of 6.5.2 release, sometime in
mid-September.

Gene Sokolov.

From bouncefilter Mon Nov 1 11:54: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 LAA62619
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 11:53:57 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id LAA17607;
Mon, 1 Nov 1999 11:52:03 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911011652.LAA17607@candle.pha.pa.us>
Subject: Re: [HACKERS] sort on huge table
In-Reply-To: <1680.941470920@sss.pgh.pa.us> from Tom Lane at "Nov 1,
1999 10:42:00 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 1 Nov 1999 11:52:03 -0500 (EST)
CC: t-ishii@sra.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

Of course the flaw in this reasoning is that it assumes the OS isn't
getting in the way. On the HPUX system I've been testing on, the
performance does seem to be about the same, but evidently it's much
worse on your system. (Exactly what OS are you running, anyway, and
on what hardware?) I speculate that your OS is applying some sort of
read-ahead algorithm that is getting hopelessly confused by lots of
seeks within a single file. Perhaps it's reading the next block in
sequence after every program-requested read, and then throwing away that
work when it sees the program lseek the file instead of reading.

Next question is what to do about it. I don't suppose we have any way
of turning off the OS' read-ahead algorithm :-(. We could forget about
this space-recycling improvement and go back to separate temp files.
The objection to that, of course, is that while sorting might be faster,
it doesn't matter how fast the algorithm is if you don't have the disk
space to execute it.

That is the key. On BSDI, the kernel code is more complicated. If it
does a read on an already open file, and the requested buffer is not in
core, it assumes that the readahead that was performed by the previous
read was useless, and scales back the readahead algorithm. At least
that is my interpretation of the code and comments.

I suspect other OS's do similar work, but it is possible they do it more
simplistically, saying if someone does _any_ seek, they must be
accessing it non-sequentially, so read-ahead should be turned off.

Read-ahead on random file access is a terrible thing, and most OS's
figure out a way to turn off read-ahead in non-sequential cases. Of
course, lack of read-ahead in sequential access also is a problem.

Tatsuo, what OS are you using? Maybe I can check the kernel to see how
it is behaving.

A possible compromise is to use separate temp files but drop the
polyphase merge and go to a balanced merge, which'd still access each
temp file sequentially but would have only a 2X space penalty instead of
4X (since all the data starts on one set of tapes and gets copied to the
other set during a complete merge pass). The balanced merge is a little
slower than polyphase --- more merge passes --- but the space savings
probably justify it.

One thing I'd like to know before we make any decisions is whether
this problem is widespread. Can anyone else run performance tests
of the speed of large sorts, using current sources vs. 6.5.* ?

I may be able to test that today on BSDI, but I doubt BSDI is typical.
They are probably state-of-the-art in kernel algorithm design.

-- 
  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 Nov 1 12:11:54 1999
Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194])
by hub.org (8.9.3/8.9.3) with SMTP id MAA65046
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 12:11:01 -0500 (EST)
(envelope-from akorud@polynet.lviv.ua)
Received: (qmail 82872 invoked from network); 1 Nov 1999 17:10:57 -0000
Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown)
by unknown with SMTP; 1 Nov 1999 17:10:57 -0000
Received: (qmail 24963 invoked from network); 1 Nov 1999 17:10:56 -0000
Received: (ofmipd unknown); 1 Nov 1999 17:10:34 -0000
Date: 1 Nov 1999 19:10:56 +0200
Message-ID: <Pine.BSF.3.96.991101190931.23897C-100000@NetSurfer.lp.lviv.ua>
From: "Andrij Korud" <akorud@polynet.lviv.ua>
To: pgsql-hackers@postgresql.org
X-Sender: akorud@NetSurfer.lp.lviv.ua
Subject: Get OID of just inserted record
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,
Is there any way to obtain an OID of record just inserted by SPI_execp?

Thanks in advance,
Andriy Korud, Lviv, Ukraine

From bouncefilter Mon Nov 1 12:17:54 1999
Received: from kampong.aedinc.net (kampong.aedinc.net [208.132.31.130])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA65751
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 12:17:50 -0500 (EST)
(envelope-from Craig.Spannring@aedinc.net)
Received: from KRAKOR (p002.aedinc.net [208.132.31.132])
by kampong.aedinc.net (8.8.8/8.8.8) with ESMTP id KAA17268;
Mon, 1 Nov 1999 10:17:42 -0700 (MST)
(envelope-from Craig.Spannring@aedinc.net)
Date: Mon, 1 Nov 1999 10:17:42 -0700 (MST)
Message-Id: <199911011717.KAA17268@kampong.aedinc.net>
From: Craig Spannring <Craig.Spannring@aedinc.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Andrij Korud" <akorud@polynet.lviv.ua>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Whos idea was this
In-Reply-To: <NCBBINEHHJGEONJEMFOIKECODAAA.akorud@polynet.lviv.ua>
References: <NCBBINEHHJGEONJEMFOIKECODAAA.akorud@polynet.lviv.ua>
X-Mailer: VM 6.31 under Emacs 20.3.1

Andrij Korud writes:

Hey, I just found that if I "BEGIN", making a lot of inserts (1000) and on
1001 insert I get an error (for example "duplicate key") ALL prev 1000
insertes I LOST.
Give me please author of this %$%$^&%# idea!!! It's really STUPID.

Actually, that's the way it's supposed to work. Most modern
relational databases support what are called transactions. A
transaction is an indivisible unit of work for the database engine.

By starting a transaction (using the 'BEGIN') you are telling the
database engine that you want it to make the updates if and only if
_all_ of the updates can succeed. If any updates that will fail the
database engine will make sure that none of the updates take place.

Transactions come in really handy if we have updates on a set of mutually
dependent tables. Frequently we don't want to update any of the
tables unless we can sucdeed in updating all of the tables.

If you have a set of updates that aren't mutually dependent, just use
a 'COMMIT TRANSACTION' between each update.

--
=======================================================================
Life is short. | Craig Spannring
Bike hard, ski fast. | Craig.Spannring@aedinc.net
--------------------------------+------------------------------------
Any sufficiently horrible technology is indistinguishable from Perl.
=======================================================================

From bouncefilter Mon Nov 1 12:20:54 1999
Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194])
by hub.org (8.9.3/8.9.3) with SMTP id MAA66220
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 12:20:07 -0500 (EST)
(envelope-from akorud@polynet.lviv.ua)
Received: (qmail 84019 invoked from network); 1 Nov 1999 17:20:02 -0000
Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown)
by unknown with SMTP; 1 Nov 1999 17:20:02 -0000
Received: (qmail 25588 invoked from network); 1 Nov 1999 17:20:02 -0000
Received: (ofmipd unknown); 1 Nov 1999 17:19:40 -0000
Date: 1 Nov 1999 19:20:01 +0200
Message-ID: <Pine.BSF.3.96.991101191923.23897D-100000@NetSurfer.lp.lviv.ua>
From: "Andrij Korud" <akorud@polynet.lviv.ua>
To: "Craig Spannring" <Craig.Spannring@aedinc.net>
Cc: pgsql-hackers@postgreSQL.org
X-Sender: akorud@NetSurfer.lp.lviv.ua
Subject: Re: [HACKERS] Whos idea was this
In-Reply-To: <199911011717.KAA17268@kampong.aedinc.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Sorry for first angry letter and let close this theme.
Sorry once more.

Andriy Korud, Lviv, Ukraine

From bouncefilter Mon Nov 1 12:52:55 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 MAA71475
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 12:52:13 -0500 (EST)
(envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA31058;
Mon, 1 Nov 1999 18:39:09 +0100
Date: Mon, 1 Nov 1999 18:39:09 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Andrij Korud <akorud@polynet.lviv.ua>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Get OID of just inserted record
In-Reply-To: <Pine.BSF.3.96.991101190931.23897C-100000@NetSurfer.lp.lviv.ua>
Message-ID: <Pine.LNX.3.96.991101182941.29853A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On 1 Nov 1999, Andrij Korud wrote:

Hi,
Is there any way to obtain an OID of record just inserted by SPI_execp?

SELECT max(oid) ... which is not implement now :-)

If is any way for this is prabably good idea add this to SPI API (as
SPI_oidStatus()). What?

Karel

------------------------------------------------------------------------------
Karel Zak <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)
------------------------------------------------------------------------------

From bouncefilter Mon Nov 1 13:02: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 NAA73151
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 13:02:39 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id NAA20652;
Mon, 1 Nov 1999 13:00:21 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911011800.NAA20652@candle.pha.pa.us>
Subject: Re: [HACKERS] sort on huge table
In-Reply-To: <1680.941470920@sss.pgh.pa.us> from Tom Lane at "Nov 1,
1999 10:42:00 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 1 Nov 1999 13:00:21 -0500 (EST)
CC: t-ishii@sra.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

Next question is what to do about it. I don't suppose we have any way
of turning off the OS' read-ahead algorithm :-(. We could forget about
this space-recycling improvement and go back to separate temp files.
The objection to that, of course, is that while sorting might be faster,
it doesn't matter how fast the algorithm is if you don't have the disk
space to execute it.

Look what I found. I downloaded Linux kernel source for 2.2.0, and
started looking for the word 'ahead' in the file system files. I found
that read-ahead seems to be controlled by f_reada, and look where I
found it being turned off? Seems like any seek turns off read-ahead on
Linux.

When you do a read or write, it seems to be turned on again. Once you
read/write, the next read/write will do read-ahead, assuming you don't
do any lseek() before the second read/write().

Seems like the algorithm in psort now is rarely having read-ahead on
Linux, while other OS's check to see if the read-ahead was eventually
used, and control read-ahead that way.

read-head also seems be off on the first read from a file.

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

/*
* linux/fs/ext2/file.c
...
/*
* Make sure the offset never goes beyond the 32-bit mark..
*/
static long long ext2_file_lseek(
struct file *file,
long long offset,
int origin)
{
struct inode *inode = file->f_dentry->d_inode;

switch (origin) {
case 2:
offset += inode->i_size;
break;
case 1:
offset += file->f_pos;
}
if (((unsigned long long) offset >> 32) != 0) {
#if BITS_PER_LONG < 64
return -EINVAL;
#else
if (offset > ext2_max_sizes[EXT2_BLOCK_SIZE_BITS(inode->i_sb)])
return -EINVAL;
#endif
}
if (offset != file->f_pos) {
file->f_pos = offset;
file->f_reada = 0;
file->f_version = ++event;
}
return offset;
}

-- 
  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 Nov 1 13:34: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 NAA77325
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 13:34:23 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id NAA21398;
Mon, 1 Nov 1999 13:32:08 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911011832.NAA21398@candle.pha.pa.us>
Subject: Re: [HACKERS] sort on huge table
In-Reply-To: <1680.941470920@sss.pgh.pa.us> from Tom Lane at "Nov 1,
1999 10:42:00 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 1 Nov 1999 13:32:08 -0500 (EST)
CC: t-ishii@sra.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

Next question is what to do about it. I don't suppose we have any way
of turning off the OS' read-ahead algorithm :-(. We could forget about
this space-recycling improvement and go back to separate temp files.
The objection to that, of course, is that while sorting might be faster,
it doesn't matter how fast the algorithm is if you don't have the disk
space to execute it.

If I am correct on the Linux seek thing, and Tatsuo is running Linux, is
there any way to fake out the kernel on only Linux, so we issue two
reads in a row before doing a seek?

-- 
  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 Nov 1 14:08:55 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 OAA82595
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 14:08:04 -0500 (EST)
(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 MAA17573;
Mon, 1 Nov 1999 12:08:14 -0700
From: "Aaron J. Seigo" <aaron@gtv.ca>
To: Bruce Momjian <maillist@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] sort on huge table
Date: Mon, 1 Nov 1999 12:00:55 -0700
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
References: <199911011800.NAA20652@candle.pha.pa.us>
In-Reply-To: <199911011800.NAA20652@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <99110112054206.24102@stilborne>
Content-Transfer-Encoding: 8bit

hi...

Look what I found. I downloaded Linux kernel source for 2.2.0, and
started looking for the word 'ahead' in the file system files. I found
that read-ahead seems to be controlled by f_reada, and look where I
found it being turned off? Seems like any seek turns off read-ahead on
Linux.

the current kernel is 2.2.13... =)

that said, the fs/ext2/file.c is the same in 2.2.13 as it is in 2.2.0 (just
checked).. i'm going to put this out on the linux kernel mailing list and see
what comes back, though, as this seems to be an issue that should be
resolved if accurate....

--
Aaron J. Seigo
Sys Admin

From bouncefilter Mon Nov 1 14:14: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 OAA83761
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 14:14:45 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id OAA27394;
Mon, 1 Nov 1999 14:13:46 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911011913.OAA27394@candle.pha.pa.us>
Subject: Re: [HACKERS] sort on huge table
In-Reply-To: <99110112054206.24102@stilborne> from "Aaron J. Seigo" at "Nov 1,
1999 12:00:55 pm"
To: "Aaron J. Seigo" <aaron@gtv.ca>
Date: Mon, 1 Nov 1999 14:13:46 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, t-ishii@sra.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

hi...

Look what I found. I downloaded Linux kernel source for 2.2.0, and
started looking for the word 'ahead' in the file system files. I found
that read-ahead seems to be controlled by f_reada, and look where I
found it being turned off? Seems like any seek turns off read-ahead on
Linux.

the current kernel is 2.2.13... =)

I need to know what kernel the tester is using. I doubt it is the most
current one.

that said, the fs/ext2/file.c is the same in 2.2.13 as it is in 2.2.0 (just
checked).. i'm going to put this out on the linux kernel mailing list and see
what comes back, though, as this seems to be an issue that should be
resolved if accurate....

I am not sure I am accurate either, but I think I am.

It would be nice to get the kernel fixed, though a fix for that is
rarely trivial.

Let us know what your find out.

-- 
  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 Nov 1 14:42:56 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 OAA88867
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 14:42:20 -0500 (EST)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id WAA09737
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 22:42:17 +0300 (MSK)
Date: Mon, 1 Nov 1999 22:42:16 +0300 (MSK)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: pgsql-hackers@postgresql.org
Subject: using indices in ORDER BY ... DESC
Message-ID: <Pine.GSO.3.96.SK.991101223350.21751B-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I don't remember who is the author of patch for 6.5.2 which
allows to use indices in ORDER BY ... DESC
The patch was posted to hackers mailing list and I'm using it
without any problem. Today, after cvs'ing 6_5 I had a problem
with this patch. If this patch will not go to 6.5.3
is't possible to create new one ? Also, does it 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 Mon Nov 1 15:16:56 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 PAA93265
for <hackers@postgresql.org>; Mon, 1 Nov 1999 15:16:09 -0500 (EST)
(envelope-from brook@biology.nmsu.edu)
Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id
NAA07215;
Mon, 1 Nov 1999 13:16:08 -0700 (MST)
Date: Mon, 1 Nov 1999 13:16:08 -0700 (MST)
Message-Id: <199911012016.NAA07215@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: hackers@postgresql.org
Subject: change in name of perl?

The installed name of perl in needed in interfaces/Makefile. This
seems to have been changed from perl to perl5 sometime between 6.5 and
6.5.2. I missed discussion of this, I guess.

What was the rationale for making this change?

Cheers,
Brook

From bouncefilter Mon Nov 1 16:18:58 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA03236
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 16:18:47 -0500 (EST)
(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 QAA02613;
Mon, 1 Nov 1999 16:17:01 -0500 (EST)
To: "Gene Sokolov" <hook@aktrad.ru>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] file descriptors leak?
In-reply-to: Your message of Mon, 1 Nov 1999 18:55:07 +0300
<13a501bf2481$794661a0$0d8cdac3@aktrad.ru>
Date: Mon, 01 Nov 1999 16:17:01 -0500
Message-ID: <2611.941491021@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Seems like there is (was) a leak of file descriptors somewhere. The
descriptors are being used up like crazy.

I fixed some problems along that line during the 6.5 cycle, and thought
the issue closed. Perhaps the problem's come back.

After a week of work on a small
database (6 tables, 20 or so indexes) Postgres used up well over 800
descriptors.

Hmm, there must be multiple descriptors open for the same file then?
That's really weird. Can you obtain a listing of just what is open,
using lsof or some similar tool? Even better, can you provide a
reproducible test case that will cause descriptor leakage?

Also, exactly what do you mean by "Postgres used up..." --- is this
one backend, or a total across the whole system (if so, how many
backends are we talking about here?).

regards, tom lane

From bouncefilter Mon Nov 1 16:48:57 1999
Received: from redes.unam.mx (cuk.redes.unam.mx [132.248.204.49])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA07997
for <pgsql-general@postgreSQL.org>; Mon, 1 Nov 1999 16:48:21 -0500 (EST)
(envelope-from altacar@redes.unam.mx)
Received: from localhost (altacar@localhost)
by redes.unam.mx (8.8.8+Sun/8.8.8) with SMTP id PAA01080
for <pgsql-general@postgreSQL.org>; Mon, 1 Nov 1999 15:41:58 -0600 (CST)
Date: Mon, 1 Nov 1999 15:41:58 -0600 (CST)
From: Carlos Vicente Altamirano <altacar@redes.unam.mx>
X-Sender: altacar@cuk
To: pgsql-general <pgsql-general@postgreSQL.org>
Subject: users in Postgresql
Message-ID: <Pine.GSO.3.96.991101154049.993A-100000@cuk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

How can i add a user (root for example) in pg_shadow?

Atte.

=======================================
Carlos A. Vicente Altamirano
Centro de Asistencia Tecnica de RedUNAM
Depto. de Operacion de la Red
DGSCA-UNAM
Tel. 6228526-28
=======================================

From bouncefilter Mon Nov 1 17:04: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 RAA10864
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 17:04:36 -0500 (EST)
(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 RAA02728;
Mon, 1 Nov 1999 17:03:29 -0500 (EST)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
In-reply-to: Your message of Mon, 1 Nov 1999 13:32:08 -0500 (EST)
<199911011832.NAA21398@candle.pha.pa.us>
Date: Mon, 01 Nov 1999 17:03:28 -0500
Message-ID: <2726.941493808@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

If I am correct on the Linux seek thing, and Tatsuo is running Linux, is
there any way to fake out the kernel on only Linux, so we issue two
reads in a row before doing a seek?

I dunno. I see that f_reada is turned off by a seek in the extract you
posted, but I wasn't clear on what turns it on again, nor what happens
after it is turned on.

After further thought I am not sure that read-ahead or lack of it is
the problem. The changes I committed over the weekend were to try to
improve locality of access to the temp file by reading tuples from
logical tapes in bursts --- in a merge pass that's reading N logical
tapes, it now tries to grab SortMem/N bytes worth of tuples off any one
source tape at a time, rather than just reading an 8K block at a time
from each tape as the first cut did. That seemed to improve performance
on both my system and Tatsuo's, but his is still far below the speed of
the 6.5 code. I'm not sure I understand why. The majority of the block
reads or writes *should* be sequential now, given a reasonable SortMem
(and he tested with quite large settings). I'm afraid there is some
aspect of the kernel's behavior on his system that we don't have a clue
about...

regards, tom lane

From bouncefilter Mon Nov 1 17:29:58 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 RAA15211
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 17:28:58 -0500 (EST)
(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 RAA00730;
Mon, 1 Nov 1999 17:25:42 -0500
Message-ID: <381E1364.847D04BB@wgcr.org>
Date: Mon, 01 Nov 1999 17:25:40 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <maillist@candle.pha.pa.us>, t-ishii@sra.co.jp,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] sort on huge table
References: <2726.941493808@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

the 6.5 code. I'm not sure I understand why. The majority of the block
reads or writes *should* be sequential now, given a reasonable SortMem
(and he tested with quite large settings). I'm afraid there is some
aspect of the kernel's behavior on his system that we don't have a clue
about...

How could I go about duplicating this?? Having multiple RedHat systems
available (both of the 2.2 and 2.0 variety), I'd be glad to test it
here. I'm pulling a cvs update as I write this. If possible, I'd like
to duplicate it exactly.

Also, from prior discussions with Thomas, there is a RedHat 6.0 machine
at hub.org for testing purposes.

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

From bouncefilter Mon Nov 1 17:43:58 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 RAA18305
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 17:43:00 -0500 (EST)
(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 HAA17932;
Tue, 2 Nov 1999 07:42:50 +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 HAA26706;
Tue, 2 Nov 1999 07:42:50 +0900 (JST)
Message-Id: <199911012242.HAA26706@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 Mon, 01 Nov 1999 10:42:00 EST.
<1680.941470920@sss.pgh.pa.us>
Date: Tue, 02 Nov 1999 07:42:50 +0900
Sender: t-ishii@srapc451.sra.co.jp

Of course the flaw in this reasoning is that it assumes the OS isn't
getting in the way. On the HPUX system I've been testing on, the
performance does seem to be about the same, but evidently it's much
worse on your system. (Exactly what OS are you running, anyway, and
on what hardware?) I speculate that your OS is applying some sort of
read-ahead algorithm that is getting hopelessly confused by lots of
seeks within a single file. Perhaps it's reading the next block in
sequence after every program-requested read, and then throwing away that
work when it sees the program lseek the file instead of reading.

Ok. Here are my settings.

RedHat Linux 6.0 (kernel 2.2.5-smp)
Pentium III 500MHz x 2
RAM: 512MB
Disk: Ultra Wide SCSI 9GB x 4 + Hardware RAID (RAID 5).

Also, I could provide testing scripts to reproduce my tests.

Next question is what to do about it. I don't suppose we have any way
of turning off the OS' read-ahead algorithm :-(. We could forget about
this space-recycling improvement and go back to separate temp files.
The objection to that, of course, is that while sorting might be faster,
it doesn't matter how fast the algorithm is if you don't have the disk
space to execute it.

A possible compromise is to use separate temp files but drop the
polyphase merge and go to a balanced merge, which'd still access each
temp file sequentially but would have only a 2X space penalty instead of
4X (since all the data starts on one set of tapes and gets copied to the
other set during a complete merge pass). The balanced merge is a little
slower than polyphase --- more merge passes --- but the space savings
probably justify it.

I think it depends on the disk space available. Ideally it should be
able to choice the sort algorithm. If it's impossible, the algorithm
that requires least sort space requires would be the way we go. Since
the performance problem only occurs when a table is huge.

One thing I'd like to know before we make any decisions is whether
this problem is widespread. Can anyone else run performance tests
of the speed of large sorts, using current sources vs. 6.5.* ?

I will test with 6.5.2 again.
--
Tatsuo Ishii

From bouncefilter Mon Nov 1 17:49:58 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA19282
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 17:49:39 -0500 (EST)
(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 RAA04621;
Mon, 1 Nov 1999 17:49:03 -0500 (EST)
To: t-ishii@sra.co.jp
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] sort on huge table
In-reply-to: Your message of Tue, 02 Nov 1999 07:42:50 +0900
<199911012242.HAA26706@srapc451.sra.co.jp>
Date: Mon, 01 Nov 1999 17:49:03 -0500
Message-ID: <4619.941496543@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

RedHat Linux 6.0 (kernel 2.2.5-smp)
Pentium III 500MHz x 2
RAM: 512MB
Disk: Ultra Wide SCSI 9GB x 4 + Hardware RAID (RAID 5).

OK, no problem with inadequate hardware anyway ;-). Bruce's concern
about simplistic read-ahead algorithm in Linux may apply though.

Also, I could provide testing scripts to reproduce my tests.

Please. That would be very handy so that we can make sure we are all
comparing the same thing. I assume the scripts can be tweaked to vary
the amount of disk space used? I can't scare up more than a couple
hundred meg at the moment. (The natural state of a disk drive is
"full" ...)

I think it depends on the disk space available. Ideally it should be
able to choice the sort algorithm.

I was hoping to avoid that, because of the extra difficulty of testing
and maintenance. But it may be the only answer.

regards, tom lane

From bouncefilter Mon Nov 1 18:09: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 SAA22577
for <hackers@postgreSQL.org>; Mon, 1 Nov 1999 18:08:39 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id SAA05557;
Mon, 1 Nov 1999 18:04:42 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911012304.SAA05557@candle.pha.pa.us>
Subject: Re: [HACKERS] change in name of perl?
In-Reply-To: <199911012016.NAA07215@biology.nmsu.edu> from Brook Milligan at
"Nov 1, 1999 01:16:08 pm"
To: Brook Milligan <brook@biology.nmsu.edu>
Date: Mon, 1 Nov 1999 18:04:42 -0500 (EST)
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

The installed name of perl in needed in interfaces/Makefile. This
seems to have been changed from perl to perl5 sometime between 6.5 and
6.5.2. I missed discussion of this, I guess.

You mean the directory name was changed? I don't see any perl-mentioned
changes in these releases.

-- 
  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 Nov 1 18:09:58 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA22627
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 18:09:22 -0500 (EST)
(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 SAA05303;
Mon, 1 Nov 1999 18:05:52 -0500 (EST)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, t-ishii@sra.co.jp,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
In-reply-to: Your message of Mon, 01 Nov 1999 17:25:40 -0500
<381E1364.847D04BB@wgcr.org>
Date: Mon, 01 Nov 1999 18:05:52 -0500
Message-ID: <5301.941497552@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Lamar Owen <lamar.owen@wgcr.org> writes:

How could I go about duplicating this?? Having multiple RedHat systems
available (both of the 2.2 and 2.0 variety), I'd be glad to test it
here. I'm pulling a cvs update as I write this. If possible, I'd like
to duplicate it exactly.

Me too (modulo disk space issues --- maybe we should try to compare
sorts of say 100MB, rather than 2GB). Tatsuo said he'd make his test
script available.

regards, tom lane

From bouncefilter Mon Nov 1 18:17:58 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA24068
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 18:17:49 -0500 (EST)
(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 SAA05539;
Mon, 1 Nov 1999 18:17:16 -0500 (EST)
To: "nicks.emails" <nicks.emails@ic24.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Backend terminated abnormally
In-reply-to: Your message of Mon, 1 Nov 1999 22:18:34 -0800
<007a01bf24fa$18704ca0$41646464@toshiba7020>
Date: Mon, 01 Nov 1999 18:17:16 -0500
Message-ID: <5537.941498236@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"nicks.emails" <nicks.emails@ic24.net> writes:

select l.s # p.ss from LSEG_TBL l, LSEG_TBL1 p;

when I try to execute this intersection on the tables that are in the
regression queries the following message is printed to the screen,

I'm confused --- I don't see any table named LSEG_TBL1 in the standard
regression tests. Are you sure you didn't create that one yourself?

I tried
select l.s # p.s from LSEG_TBL l, LSEG_TBL p;
using the table that is there, and it gave me answers (I have no idea
if they're right though ;-)).

regards, tom lane

From bouncefilter Mon Nov 1 18:30:58 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 SAA26580
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 18:30:34 -0500 (EST)
(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 SAA00843;
Mon, 1 Nov 1999 18:30:33 -0500
Message-ID: <381E2296.C6C167CD@wgcr.org>
Date: Mon, 01 Nov 1999 18:30:30 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] pgaccess 0.98
References: <199910312054.PAA10357@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

It should just install and work now.

In the RPM context, it doesn't. I pulled a cvs update of
REL6_5_PATCHES, tarballed the tree into 'postgresql-6.5.3.tar.gz', and
gave it the 'rpm -ba' treatment after a patch-building and
spec-file-editing session that I'd rather forget (due to some of my
stupid errors) (ask Thomas about the rpm spec file....).

/usr/bin/pgaccess (in the standard install, this is the result of your
munged src/bin/pgaccess/pgaccess.sh) has the following line:

PATH_TO_WISH=@WISH@

Which confuses things. The line should read
'PATH_TO_WISH=/usr/bin/wish' -- which, when I edit pgaccess to read
thus, everything works.

System: RedHat Linux 5.2.

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

From bouncefilter Mon Nov 1 19:13: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 TAA31673
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 19:13:20 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id TAA15555;
Mon, 1 Nov 1999 19:12:29 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911020012.TAA15555@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess 0.98
In-Reply-To: <381E2296.C6C167CD@wgcr.org> from Lamar Owen at "Nov 1,
1999 06:30:30 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Mon, 1 Nov 1999 19:12:29 -0500 (EST)
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

Bruce Momjian wrote:

It should just install and work now.

In the RPM context, it doesn't. I pulled a cvs update of
REL6_5_PATCHES, tarballed the tree into 'postgresql-6.5.3.tar.gz', and
gave it the 'rpm -ba' treatment after a patch-building and
spec-file-editing session that I'd rather forget (due to some of my
stupid errors) (ask Thomas about the rpm spec file....).

/usr/bin/pgaccess (in the standard install, this is the result of your
munged src/bin/pgaccess/pgaccess.sh) has the following line:

PATH_TO_WISH=@WISH@

Which confuses things. The line should read
'PATH_TO_WISH=/usr/bin/wish' -- which, when I edit pgaccess to read
thus, everything works.

Thanks for testing this. I have fixed the problem. Please try it again
and let me know.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

From bouncefilter Mon Nov 1 19:33:59 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 TAA34504
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 19:32:56 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA00047; Tue, 02 Nov 1999 09:32:22 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Oleg Bartunov" <oleg@sai.msu.su>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] using indices in ORDER BY ... DESC
Date: Tue, 2 Nov 1999 09:36:35 +0900
Message-ID: <000301bf24ca$5173cac0$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: <Pine.GSO.3.96.SK.991101223350.21751B-100000@ra>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Oleg Bartunov
Sent: Tuesday, November 02, 1999 4:42 AM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] using indices in ORDER BY ... DESC

I don't remember who is the author of patch for 6.5.2 which
allows to use indices in ORDER BY ... DESC

It's me.
However,it was not for 6.5.2 because it isn't a bug fix.

The patch was posted to hackers mailing list and I'm using it
without any problem. Today, after cvs'ing 6_5 I had a problem
with this patch. If this patch will not go to 6.5.3
is't possible to create new one ? Also, does it already

Hmm,I don't have REL_.. cvs branch on my machine.
But I may be able to help you.
What kind of problem do you have ?

applied to current ?

Yes,it's already applied to current.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Nov 1 20:13:59 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id UAA39454
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 20:13:47 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11iSOS-0003kLC; Tue, 2 Nov 99 02:05 MET
Message-Id: <m11iSOS-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Get OID of just inserted record
To: akorud@polynet.lviv.ua (Andrij Korud)
Date: Tue, 2 Nov 1999 02:05:48 +0100 (MET)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <Pine.BSF.3.96.991101190931.23897C-100000@NetSurfer.lp.lviv.ua>
from "Andrij Korud" at Nov 1, 99 07:10:56 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Hi,
Is there any way to obtain an OID of record just inserted by SPI_execp?

How should that work consistenty? What do you expect as
return if the query executed was an

INSERT INTO t2 SELECT * FROM t1;

The first, a random one or the last of the two million rows
inserted?

Jan

--

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

From bouncefilter Mon Nov 1 20:07:59 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 UAA38814
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 20:07:23 -0500 (EST)
(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 UAA00969;
Mon, 1 Nov 1999 20:07:24 -0500
Message-ID: <381E3948.8D2F84D3@wgcr.org>
Date: Mon, 01 Nov 1999 20:07:20 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "nicks.emails" <nicks.emails@ic24.net>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Backend terminated abnormally
References: <007a01bf24fa$18704ca0$41646464@toshiba7020>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"nicks.emails" wrote:

Hello,

I not sure if I have got the right person for this but if you could
help me it would be extremely helpful;

The problem is with the following query,

select l.s # p.ss from LSEG_TBL l, LSEG_TBL1 p;

Duplicated with PostgreSQL 6.5.2 on RedHat 6.0, egcs 1.1.2.

Will get more details as I have them.

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Mon Nov 1 20:17:00 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 UAA39950
for <hackers@postgreSQL.org>; Mon, 1 Nov 1999 20:16:03 -0500 (EST)
(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 UAA00993;
Mon, 1 Nov 1999 20:15:57 -0500
Message-ID: <381E3B49.1AF23ABD@wgcr.org>
Date: Mon, 01 Nov 1999 20:15:53 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Brook Milligan <brook@biology.nmsu.edu>, hackers@postgreSQL.org
Subject: Re: [HACKERS] change in name of perl?
References: <199911012304.SAA05557@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

The installed name of perl in needed in interfaces/Makefile. This
seems to have been changed from perl to perl5 sometime between 6.5 and
6.5.2. I missed discussion of this, I guess.

You mean the directory name was changed? I don't see any perl-mentioned
changes in these releases.

src/interfaces/Makefile:
-----------
perl5/Makefile: perl5/Makefile.PL
cd perl5 && perl5 Makefile.PL

install-perl5: perl5/Makefile
$(MAKE) -C perl5 clean
cd perl5 && POSTGRES_HOME="$(POSTGRESDIR)" perl5 Makefile.PL
-----------
Should be:
-----------
perl5/Makefile: perl5/Makefile.PL
cd perl5 && perl Makefile.PL

install-perl5: perl5/Makefile
$(MAKE) -C perl5 clean
cd perl5 && POSTGRES_HOME="$(POSTGRESDIR)" perl Makefile.PL
-----------
Which is the way it read in 6.5.1, IIANM. I know that I didn't have to
patch this in 6.5.1.

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

From bouncefilter Mon Nov 1 19:13:59 1999
Received: from argh.demon.co.uk (IDENT:grim@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA31702
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 19:13:43 -0500 (EST)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id BAA03842
for pgsql-hackers@postgreSQL.org; Tue, 2 Nov 1999 01:20:34 GMT
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199911020120.BAA03842@argh.demon.co.uk>
Subject: Re: [HACKERS] Backend crashes (6.5.2 linux)
To: pgsql-hackers@postgreSQL.org
Date: Tue, 2 Nov 1999 01:20:34 +0000 (GMT)
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

Thanks to tom and vadim for the ideas so far. Here is my responses to
these:

Tom wrote:

Hmm. That error is coming out of the btree index code. Vadim knows
that code better than anyone else, so he might have something to say
here, but my past-midnight recollection is that we've seen that error
being triggered when there are oversize entries in the index (where
"oversize" = "more than half a disk page"). It's a bug, for sure,
but what you probably want right now is a workaround. Do you have any
entries in indexed columns that are over 4K, and can you get rid of them?

Okee, Ive looked at all of the text lengths (I didnt bother with the ints)
and got the following

bestadssearch=> select length(url)+length(hostname)+length(title)+length(brief)+length(lowerurl) as length from search_url where title notnull and brief notnull order by length desc;

length
------
841
827
826
825
...

So my maximum length is probably under 1K

Huh? PQgetResult does not call pgresStatus ... not least because the
latter is an array, not a function. Your gdb is lying to you. Maybe
you have a problem with gdb looking at a different version of the
library than what's actually executing?

Nope, I just checked, I only have one version of the libraries.

Vadim Wrote:

This FATAL means that index is broken (some prev insertion
was interrupted by elog(ERROR) or backend crash) - try to rebuild...
WAL should fix this bug.

Vadim

Thats curious cos look at this explain...

bestadssearch=> explain update search_url set stale=941424005 where lowerurl='http://criswell.bizland.com&#39;;
NOTICE: QUERY PLAN:

Seq Scan on search_url (cost=1546.06 rows=2 width=122)

EXPLAIN

That does a seq scan not an index scan.

This came to light when I realised my initialisation script for the database
added a bogus index (oops). However, that is probably not a good sign if
the seq scan fails for this reason.

The only index associated with this table is the one created with a serial
type.

I am going to rebuild the table (dump and reload) but before I do,
does anyone want me to try anything on it to see if you can get any
more information you may need for debugging? If so, let me know asap
{:-)

~Michael

From bouncefilter Mon Nov 1 20:22:00 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 UAA40606
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 20:21:11 -0500 (EST)
(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 UAA01012;
Mon, 1 Nov 1999 20:21:10 -0500
Message-ID: <381E3C82.E002AB3F@wgcr.org>
Date: Mon, 01 Nov 1999 20:21:06 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] pgaccess 0.98
References: <199911020012.TAA15555@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Thanks for testing this. I have fixed the problem. Please try it again
and let me know.

I'll let you know as soon as I rebuild -- which won't be tonight (gotta
spend some time with my wife). First thing in the morning.

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

From bouncefilter Mon Nov 1 21:03:00 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 VAA45735
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 21:02:55 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11iT17-0003kLC; Tue, 2 Nov 99 02:45 MET
Message-Id: <m11iT17-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
To: peter_e@gmx.net (Peter Eisentraut)
Date: Tue, 2 Nov 1999 02:45:45 +0100 (MET)
Cc: wieck@debis.com, tgl@sss.pgh.pa.us, maillist@candle.pha.pa.us,
pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <Pine.LNX.4.10.9911010039520.342-100000@peter-e.yi.org> from
"Peter Eisentraut" at Nov 1, 99 00:46:19 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Peter Eisentraut wrote:

On Oct 30, Jan Wieck mentioned:

Right. A major release is what it is. And porting
applications to a new major release too, it is a conversion,
not an upgrade. Therefore a major release should drop as much
backward compatibility code for minor releases as possible.

Certainly true. But that would also mean that we'd have to keep
maintaining the 6.* series as well. At least bug-fixing and releasing one
or two more 6.5.x versions. Up until now the usual answer to a bug was
"upgrade to latest version". But if you break compatibility you can't do
that any more. (Compare to Linux 2.0 vs 2.2) I'm just wondering what the
plans are in that regard.

Sometimes ago, I already pointed out that we have to support
one or too older releases for some time. Not only because we
might drop some compatibility code. Each release usually
declares one or the other new keyword, making existing
applications probably fail with the new release. And no
amount of compatibility code would help in that case! It's a
deadlock trap, an application that cannot be easily ported to
a newer release because of incompatibilities in the
querylaguage cannot use the last release it is compatible to
because of a bug.

There is a new aspect in this discussion since then. The new
corporation PostgreSQL Inc. offers commercial support for our
database (look at www.pgsql.com). If they offer support, they
must support older releases as well, so they need to
backpatch already.

Wouldn't it be a good idea if their return into our project
are bugfix releases of older versions (created by
backpatching release branches)? In the case of a customers
accident, they have to do it anyway. And doing it for
critical bugs during idle time could avoid accidents, so it's
good customer service.

Marc, what do you think about a such an agreement?

Jan

--

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

From bouncefilter Mon Nov 1 21:25:00 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 VAA48175
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 21:24:04 -0500 (EST)
(envelope-from mascarim@yahoo.com)
Message-ID: <19991102022403.17189.rocketmail@web2101.mail.yahoo.com>
Received: from [24.26.131.45] by web2101.mail.yahoo.com;
Mon, 01 Nov 1999 18:24:03 PST
Date: Mon, 1 Nov 1999 18:24:03 -0800 (PST)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] sort on huge table
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: t-ishii@sra.co.jp, pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

RedHat Linux 6.0 (kernel 2.2.5-smp)
Pentium III 500MHz x 2
RAM: 512MB
Disk: Ultra Wide SCSI 9GB x 4 + Hardware RAID (RAID 5).

OK, no problem with inadequate hardware anyway ;-). Bruce's concern
about simplistic read-ahead algorithm in Linux may apply though.

Also, I could provide testing scripts to reproduce my tests.

Please. That would be very handy so that we can make sure we are all
comparing the same thing. I assume the scripts can be tweaked to vary
the amount of disk space used? I can't scare up more than a couple
hundred meg at the moment. (The natural state of a disk drive is
"full" ...)

I think it depends on the disk space available. Ideally it should be
able to choice the sort algorithm.

I was hoping to avoid that, because of the extra difficulty of testing
and maintenance. But it may be the only answer.

regards, tom lane

I know this is a VERY long shot, but... what were the READ/WRITE ratios
between the old version and the new version? Perhaps the computation
of the checksum (sic) blocks under RAID5 caused the unexpected behavior.
With RAID 5 increasing read performance but decreasing writes, one might
expect a new algorithm which say, halves reads, but increases writes
slightly to not realize the same benefits as under a normal disk system or
a RAID 1 (or, better yet, a RAID 0+1) array.

Like I said...a VERY long shot theory.

Mike Mascari
(mascarim@yahoo.com)

=====

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

From bouncefilter Mon Nov 1 21:38:01 1999
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA50081
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 21:37:48 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id SAA01068;
Mon, 1 Nov 1999 18:36:30 -0800 (PST)
Message-Id: <3.0.1.32.19991101183500.00ab5d80@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 01 Nov 1999 18:35:00 -0800
To: Mike Mascari <mascarim@yahoo.com>, Tom Lane <tgl@sss.pgh.pa.us>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] sort on huge table
Cc: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
In-Reply-To: <19991102022403.17189.rocketmail@web2101.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 06:24 PM 11/1/99 -0800, Mike Mascari wrote:

I know this is a VERY long shot, but... what were the READ/WRITE ratios
between the old version and the new version? Perhaps the computation
of the checksum (sic) blocks under RAID5 caused the unexpected behavior.
With RAID 5 increasing read performance but decreasing writes, one might
expect a new algorithm which say, halves reads, but increases writes
slightly to not realize the same benefits as under a normal disk system or
a RAID 1 (or, better yet, a RAID 0+1) array.

RAID 5, not the operating system, might be getting in the way...it
would be interesting to test this on a Linux 2.2 kernel without
the RAID 5 complication.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

From bouncefilter Mon Nov 1 21:38: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 VAA50051
for <hackers@postgreSQL.org>; Mon, 1 Nov 1999 21:37:03 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id VAA06571;
Mon, 1 Nov 1999 21:35:48 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911020235.VAA06571@candle.pha.pa.us>
Subject: Re: [HACKERS] change in name of perl?
In-Reply-To: <381E3B49.1AF23ABD@wgcr.org> from Lamar Owen at "Nov 1,
1999 08:15:53 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Mon, 1 Nov 1999 21:35:48 -0500 (EST)
CC: Brook Milligan <brook@biology.nmsu.edu>, 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 wrote:

The installed name of perl in needed in interfaces/Makefile. This
seems to have been changed from perl to perl5 sometime between 6.5 and
6.5.2. I missed discussion of this, I guess.

You mean the directory name was changed? I don't see any perl-mentioned
changes in these releases.

src/interfaces/Makefile:
-----------
perl5/Makefile: perl5/Makefile.PL
cd perl5 && perl5 Makefile.PL

install-perl5: perl5/Makefile
$(MAKE) -C perl5 clean
cd perl5 && POSTGRES_HOME="$(POSTGRESDIR)" perl5 Makefile.PL
-----------
Should be:
-----------
perl5/Makefile: perl5/Makefile.PL
cd perl5 && perl Makefile.PL

install-perl5: perl5/Makefile
$(MAKE) -C perl5 clean
cd perl5 && POSTGRES_HOME="$(POSTGRESDIR)" perl Makefile.PL
-----------
Which is the way it read in 6.5.1, IIANM. I know that I didn't have to
patch this in 6.5.1.

Thanks again.

I had applied someone's patch so perl5 would be used, but that broke
many things. I fixed the current tree to use $(PERL) as defined in
Makefile.global. I just patched stable the same way. Please test.
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 Mon Nov 1 22:02:02 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 WAA53496
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 22:01:39 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id VAA06661;
Mon, 1 Nov 1999 21:41:59 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911020241.VAA06661@candle.pha.pa.us>
Subject: Re: [HACKERS] sort on huge table
In-Reply-To: <5301.941497552@sss.pgh.pa.us> from Tom Lane at "Nov 1,
1999 06:05:52 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 1 Nov 1999 21:41:59 -0500 (EST)
CC: Lamar Owen <lamar.owen@wgcr.org>, t-ishii@sra.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

Lamar Owen <lamar.owen@wgcr.org> writes:

How could I go about duplicating this?? Having multiple RedHat systems
available (both of the 2.2 and 2.0 variety), I'd be glad to test it
here. I'm pulling a cvs update as I write this. If possible, I'd like
to duplicate it exactly.

Me too (modulo disk space issues --- maybe we should try to compare
sorts of say 100MB, rather than 2GB). Tatsuo said he'd make his test
script available.

I would be very interested if Tatsuo could comment out the f_reada line
in the function I posted, and see if the new kernel is faster on 7.0
sorts. That would clearly show the cause. I wouldn't be surprised if
7.0 sorts became faster than 6.5.* sorts.

-- 
  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 Nov 1 22:08: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 WAA54083
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 22:07:04 -0500 (EST)
(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 WAA09686;
Mon, 1 Nov 1999 22:06:27 -0500 (EST)
To: Michael Simms <grim@argh.demon.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Backend crashes (6.5.2 linux)
In-reply-to: Your message of Tue, 2 Nov 1999 01:20:34 +0000 (GMT)
<199911020120.BAA03842@argh.demon.co.uk>
Date: Mon, 01 Nov 1999 22:06:27 -0500
Message-ID: <9684.941511987@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Michael Simms <grim@argh.demon.co.uk> writes:

Vadim Wrote:

This FATAL means that index is broken (some prev insertion
was interrupted by elog(ERROR) or backend crash) - try to rebuild...

Thats curious cos look at this explain...

bestadssearch=> explain update search_url set stale=941424005 where lowerurl='http://criswell.bizland.com&#39;;
NOTICE: QUERY PLAN:

Seq Scan on search_url (cost=1546.06 rows=2 width=122)

That does a seq scan not an index scan.

No, the elog message is coming out of btree index *update*, not
btree scan. Since you're doing an update, new index entries have
to be made for the tuple being updated, regardless of what kind
of scan was used to find it. And the message comes out because
the attempt to insert an index entry is finding that the index is
already corrupt.

Vadim's advice is probably the best: drop and recreate the index(es)
on that table. You shouldn't need to dump the table itself, unless
there's more going on than is apparent from the info so far.

I am going to rebuild the table (dump and reload) but before I do,
does anyone want me to try anything on it to see if you can get any
more information you may need for debugging? If so, let me know asap

If you can reproduce the sequence of events that led to the index
becoming corrupted, that'd be *really* useful debugging info. But
it's probably too late to reconstruct anything very helpful from
the current state of the index.

regards, tom lane

From bouncefilter Mon Nov 1 22:17:01 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 WAA55310
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 22:16:35 -0500 (EST)
(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 WAA09751;
Mon, 1 Nov 1999 22:15:24 -0500 (EST)
To: wieck@debis.com (Jan Wieck)
cc: peter_e@gmx.net (Peter Eisentraut), maillist@candle.pha.pa.us,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)
In-reply-to: Your message of Tue, 2 Nov 1999 02:45:45 +0100 (MET)
<m11iT17-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Mon, 01 Nov 1999 22:15:24 -0500
Message-ID: <9749.941512524@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

There is a new aspect in this discussion since then. The new
corporation PostgreSQL Inc. offers commercial support for our
database (look at www.pgsql.com). If they offer support, they
must support older releases as well, so they need to
backpatch already.

Yes, but who's the "them" here? If PostgreSQL Inc. has any warm
bodies other than the existing group of developers, I sure haven't
heard from them...

I agree 100% with Jan's basic point: we must provide a degree of
backwards compatibility from release to release. In some cases
that might create enough pain to be worth debating, but in this
particular case it seems like the choice is a no-brainer. We just
leave in the transition fmgr code that we're going to write anyway.
I don't understand why it even got to be a topic of discussion.

regards, tom lane

From bouncefilter Mon Nov 1 22:20:01 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 WAA55564
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 22:19:35 -0500 (EST)
(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 WAA09782;
Mon, 1 Nov 1999 22:18:31 -0500 (EST)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: "nicks.emails" <nicks.emails@ic24.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Backend terminated abnormally
In-reply-to: Your message of Mon, 01 Nov 1999 20:07:20 -0500
<381E3948.8D2F84D3@wgcr.org>
Date: Mon, 01 Nov 1999 22:18:31 -0500
Message-ID: <9780.941512711@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Lamar Owen <lamar.owen@wgcr.org> writes:

The problem is with the following query,
select l.s # p.ss from LSEG_TBL l, LSEG_TBL1 p;

Duplicated with PostgreSQL 6.5.2 on RedHat 6.0, egcs 1.1.2.

Hmm, does everyone but me have a table named LSEG_TBL1 in the
regress tests? I've grepped both current and REL6_5 and I'll
be durned if I can find any use of that name. I'd look into it
if I had a reproducible test case...

regards, tom lane

From bouncefilter Mon Nov 1 22:35:01 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 WAA57743
for <pgsql-general@postgreSQL.org>; Mon, 1 Nov 1999 22:34:35 -0500 (EST)
(envelope-from ctassell@isn.net)
Received: from niki (goat10.isn.net [198.167.161.229])
by kiln.isn.net (8.9.3/8.9.3) with ESMTP id XAA09382;
Mon, 1 Nov 1999 23:34:00 -0400
Message-Id: <4.2.0.58.19991101233122.009e8970@mailer.isn.net>
X-Sender: ctassell@mailer.isn.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Mon, 01 Nov 1999 23:33:04 -0400
To: Carlos Vicente Altamirano <altacar@redes.unam.mx>,
pgsql-general <pgsql-general@postgreSQL.org>
From: Charles Tassell <ctassell@isn.net>
Subject: Re: [GENERAL] users in Postgresql
In-Reply-To: <Pine.GSO.3.96.991101154049.993A-100000@cuk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Use the command createuser in your pgsql/bin directory. Not sure how to
do it in SQL, maybe alter user or create user?

At 05:41 PM 11/1/99, Carlos Vicente Altamirano wrote:

How can i add a user (root for example) in pg_shadow?

Atte.

=======================================
Carlos A. Vicente Altamirano
Centro de Asistencia Tecnica de RedUNAM
Depto. de Operacion de la Red
DGSCA-UNAM
Tel. 6228526-28
=======================================

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

From bouncefilter Mon Nov 1 22:40:01 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 WAA58244
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 22:39:09 -0500 (EST)
(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 WAA09952;
Mon, 1 Nov 1999 22:37:57 -0500 (EST)
To: Don Baccus <dhogaza@pacifier.com>
cc: Mike Mascari <mascarim@yahoo.com>, t-ishii@sra.co.jp,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
In-reply-to: Your message of Mon, 01 Nov 1999 18:35:00 -0800
<3.0.1.32.19991101183500.00ab5d80@mail.pacifier.com>
Date: Mon, 01 Nov 1999 22:37:57 -0500
Message-ID: <9950.941513877@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

At 06:24 PM 11/1/99 -0800, Mike Mascari wrote:

I know this is a VERY long shot, but... what were the READ/WRITE ratios
between the old version and the new version? Perhaps the computation
of the checksum (sic) blocks under RAID5 caused the unexpected behavior.

Good try but no cigar --- we're dealing with a merge algorithm here,
and it's inherently the same amount of data in and out. You write
a block once, you read the same block once later on. But...

Don Baccus <dhogaza@pacifier.com> writes:

RAID 5, not the operating system, might be getting in the way...it
would be interesting to test this on a Linux 2.2 kernel without
the RAID 5 complication.

... I agree this'd be worth trying. There could be some subtle effect
somewhere in RAID5 that's tripping things up. It'd also be useful if
someone could try it on similar RAID hardware with a non-Linux kernel.

regards, tom lane

From bouncefilter Mon Nov 1 22:47:01 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 WAA59399
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 22:46:30 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org (dial-39.r12.ncbrvr.infoave.net [207.144.84.109])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id WAA01150;
Mon, 1 Nov 1999 22:46:29 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] Backend terminated abnormally
Date: Mon, 1 Nov 1999 22:46:20 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: "nicks.emails" <nicks.emails@ic24.net>, pgsql-hackers@postgreSQL.org
References: <9780.941512711@sss.pgh.pa.us>
In-Reply-To: <9780.941512711@sss.pgh.pa.us>
MIME-Version: 1.0
Message-Id: <99110122474300.07347@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Mon, 01 Nov 1999, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

The problem is with the following query,
select l.s # p.ss from LSEG_TBL l, LSEG_TBL1 p;

Duplicated with PostgreSQL 6.5.2 on RedHat 6.0, egcs 1.1.2.

Hmm, does everyone but me have a table named LSEG_TBL1 in the
regress tests? I've grepped both current and REL6_5 and I'll
be durned if I can find any use of that name. I'd look into it
if I had a reproducible test case...

regards, tom lane

Oh, sorry, Tom. SELECT * INTO TABLE LSEG_TBL1 FROM LSEG_TBL; first.

Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Mon Nov 1 22:50:01 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 WAA59703
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 22:49:11 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org (dial-39.r12.ncbrvr.infoave.net [207.144.84.109])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id WAA01159;
Mon, 1 Nov 1999 22:49:12 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess 0.98
Date: Mon, 1 Nov 1999 22:49:38 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <199911020012.TAA15555@candle.pha.pa.us>
<381E3C82.E002AB3F@wgcr.org>
In-Reply-To: <381E3C82.E002AB3F@wgcr.org>
MIME-Version: 1.0
Message-Id: <99110122502601.07347@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Mon, 01 Nov 1999, Lamar Owen wrote:

Bruce Momjian wrote:

Thanks for testing this. I have fixed the problem. Please try it again
and let me know.

I'll let you know as soon as I rebuild -- which won't be tonight (gotta
spend some time with my wife). First thing in the morning.

Well, turns out I did have time tonight to rebuild -- and it works.

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

From bouncefilter Mon Nov 1 23:01:59 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 XAA61830
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 23:01:01 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org (dial-39.r12.ncbrvr.infoave.net [207.144.84.109])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id XAA01184
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 23:01:03 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: pgsql-hackers@postgresql.org
Subject: Regression Testing on REL6_5_PATCHES
Date: Mon, 1 Nov 1999 22:56:14 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99110123021602.07347@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

I have hit an unexpected error in regression testing the REL6_5_PATCHES branch
in preparing for 6.5.3.  For the first time, a test other than float or
geometry failed -- with a weird result.  Datetime failed.  Here is the section
of regression.diffs for datetime:
----------------------------
*** expected/datetime.out	Wed Apr 14 22:19:01 1999
--- results/datetime.out	Mon Nov  1 22:40:45 1999
***************
*** 1,7 ****
  QUERY: SELECT ('today'::datetime = ('yesterday'::datetime + '1 day'::timespan)) as "True";
  True
  ----
! t   
  (1 row)

  QUERY: SELECT ('today'::datetime = ('tomorrow'::datetime - '1 day'::timespan)) as "True";
--- 1,7 ----
  QUERY: SELECT ('today'::datetime = ('yesterday'::datetime + '1 day'::timespan)) as "True";
  True
  ----
! f   
  (1 row)

QUERY: SELECT ('today'::datetime = ('tomorrow'::datetime - '1 day'::timespan)) as "True";
***************
*** 13,19 ****
QUERY: SELECT ('tomorrow'::datetime = ('yesterday'::datetime + '2 days'::timespan)) as "True";
True
----
! t
(1 row)

  QUERY: SELECT ('current'::datetime = 'now'::datetime) as "True";
--- 13,19 ----
  QUERY: SELECT ('tomorrow'::datetime = ('yesterday'::datetime + '2 days'::timespan)) as "True";
  True
  ----
! f   
  (1 row)

QUERY: SELECT ('current'::datetime = 'now'::datetime) as "True";
***************
*** 69,75 ****
QUERY: SELECT count(*) AS one FROM DATETIME_TBL WHERE d1 = 'today'::datetime - '1 day'::timespan;
one
---
! 1
(1 row)

  QUERY: SELECT count(*) AS one FROM DATETIME_TBL WHERE d1 = 'now'::datetime;
--- 69,75 ----
  QUERY: SELECT count(*) AS one FROM DATETIME_TBL WHERE d1 = 'today'::datetime - '1 day'::timespan;
  one
  ---
!   0
  (1 row)

QUERY: SELECT count(*) AS one FROM DATETIME_TBL WHERE d1 = 'now'::datetime;

-------------------------------
Misc also failed -- but that was due to the pgaccess relations from my pgaccess
testing.

System: RedHat Linux 6.1 -- kernel 2.2.12 w/ glibc 2.1.2.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Mon Nov 1 23:06:02 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 XAA63192
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 23:05:39 -0500 (EST)
(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 XAA10111;
Mon, 1 Nov 1999 23:04:35 -0500 (EST)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: "nicks.emails" <nicks.emails@ic24.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Backend terminated abnormally
In-reply-to: Your message of Mon, 1 Nov 1999 22:46:20 -0500
<99110122474300.07347@lorc.wgcr.org>
Date: Mon, 01 Nov 1999 23:04:35 -0500
Message-ID: <10109.941515475@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Lamar Owen <lamar.owen@wgcr.org> writes:

On Mon, 01 Nov 1999, Tom Lane wrote:

Hmm, does everyone but me have a table named LSEG_TBL1 in the
regress tests? I've grepped both current and REL6_5 and I'll
be durned if I can find any use of that name. I'd look into it
if I had a reproducible test case...

Oh, sorry, Tom. SELECT * INTO TABLE LSEG_TBL1 FROM LSEG_TBL; first.

Actually, the missing clue seems to be that it's cool on HPUX and
coredumps on Linux. Bigendian vs. littleendian bug maybe? I'm on
it...

regards, tom lane

From bouncefilter Mon Nov 1 23:06:02 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 XAA63250
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 23:06:00 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id XAA08274;
Mon, 1 Nov 1999 23:05:09 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911020405.XAA08274@candle.pha.pa.us>
Subject: Re: [HACKERS] pgaccess 0.98
In-Reply-To: <99110122502601.07347@lorc.wgcr.org> from Lamar Owen at "Nov 1,
1999 10:49:38 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Mon, 1 Nov 1999 23:05:09 -0500 (EST)
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 Mon, 01 Nov 1999, Lamar Owen wrote:

Bruce Momjian wrote:

Thanks for testing this. I have fixed the problem. Please try it again
and let me know.

I'll let you know as soon as I rebuild -- which won't be tonight (gotta
spend some time with my wife). First thing in the morning.

Well, turns out I did have time tonight to rebuild -- and it works.

OK, 6.5.3 is ready for packaging.

-- 
  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 Nov 1 23:07:02 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 XAA63358
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 23:06:36 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id XAA08289
for pgsql-hackers@postgreSQL.org; Mon, 1 Nov 1999 23:05:47 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911020405.XAA08289@candle.pha.pa.us>
Subject: 6.5.3 is ready
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 1 Nov 1999 23:05:47 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Marc, 6.5.3 is ready for packaging.

-- 
  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 Nov 1 23:08:02 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 XAA63574
for <pgsql-hackers@postgreSQL.org>; Mon, 1 Nov 1999 23:07:35 -0500 (EST)
(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 NAA08544;
Tue, 2 Nov 1999 13:07:33 +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 NAA01247;
Tue, 2 Nov 1999 13:07:32 +0900 (JST)
Message-Id: <199911020407.NAA01247@srapc451.sra.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Don Baccus <dhogaza@pacifier.com>, Mike Mascari <mascarim@yahoo.com>,
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 Mon, 01 Nov 1999 22:37:57 EST.
<9950.941513877@sss.pgh.pa.us>
Date: Tue, 02 Nov 1999 13:07:32 +0900
Sender: t-ishii@srapc451.sra.co.jp

At 06:24 PM 11/1/99 -0800, Mike Mascari wrote:

I know this is a VERY long shot, but... what were the READ/WRITE ratios
between the old version and the new version? Perhaps the computation
of the checksum (sic) blocks under RAID5 caused the unexpected behavior.

Good try but no cigar --- we're dealing with a merge algorithm here,
and it's inherently the same amount of data in and out. You write
a block once, you read the same block once later on. But...

Don Baccus <dhogaza@pacifier.com> writes:

RAID 5, not the operating system, might be getting in the way...it
would be interesting to test this on a Linux 2.2 kernel without
the RAID 5 complication.

... I agree this'd be worth trying. There could be some subtle effect
somewhere in RAID5 that's tripping things up. It'd also be useful if
someone could try it on similar RAID hardware with a non-Linux kernel.

I have compared current with 6.5 using 1000000 tuple-table (243MB) (I
wanted to try 2GB+ table but 6.5 does not work in this case). The
result was strange in that current is *faster* than 6.5!

RAID5
current 2:29
6.5.2 3:15

non-RAID
current 1:50
6.5.2 2:13

Seems my previous testing was done in wrong way or the behavior of
sorting might be different if the table size is changed?

Anyway, here is my test script.
First, edit Makefile to set DB and number of tuples. Then run type
make. That's all.
--
Tatsuo Ishii
--------------------------------------------------------------------
begin 644 sort.tar.gz
M'XL(`(-F'C@``^V737/:,!"&N5:_8@MD@@D8VQ@\`R$S!=)V.J3I).TIR<'8
M,H@:F]@BDTQ+?WNU_H#2-L.ED![T<$`?[Z[6R"LM<1CQQH7]E7K,IX7]H&M:
MVS2A`-!LZDW\UJV6AM\I+5,#L#3-,LVV9NIBVA"?`FA[BF>+9<SM"*#`ZRR>
M,O:L;CZ)#A'.H2GM@I3`I9Z]]#G$E',63&+PP@@XC;&CDF$?>DF/?/S\Y=/H
M_%ITQ8XC9+=W,A@(_<1QR.#MZ,T[-*Y?&N3Z_?EH)-J-,0L:\91<7>2=:`YU
MCUQ?#5`ZH8'JD,O^A[P3$F+[?@>B99"$1+)&!V?)JW(E<:R`VG`B:G.JQE,H
M5[+`%=$<]A5"A+8CVNA70:/!`*?2`+&%JRM0#Q.GQ/&I'710=W6AX%!N"M4?
MY*7W=Q<QYG_R,^YOC9WYWVZE^6\8>E/'_->;EBGS_Q"46.#X2Y?":<Q=%JK3
M,T+F-@LJ+.!@1Q.G!LY4_$#5JN@\*.0;`<`I5IMULV:0)WR7X(@'%;2#,]`5
M0#DD"IN'#"<>;O0[!4U7J/86D7#A5<3B-(IJ1=P,/%;@R`4G7#P5:T$B1JDX
M="JLIW79:=!E)R>Y\\Q#\<B]Y<4:2^29>B;4LU-#1#;;Z#<6C\5,O-IR=!OD
MX_@L["AY-NCU0-NX^#UN]5=7J[\\F!L&5$T]K_ZG0R')__PLO/?WLL:N_(>6
ME>6_WFZU+;S_35.3^7\(W"A<`+?'/@6N=TGZ)JP'*@PSO`9<7/"/7+R[+QVN
MY!^SE?_3_:RQ*_]-2\_J_Z:E-S7,?Z-MR/P_!*77ZQI;W'8W4"Y!/:!@P%V7
M3T5UB_LS[/>28AK;6:G<2RY%0OV8;@V7]=RB;!"/$;(0EXHHV&%SQ4!YV"=J
M(ZF3,[/OJ<J!8[SSQ;D#7A3.`2N2X#C14V<:0K&'P(/M+)=S2#I%DO;<,=3K
M^:GUA\6ZJKA?TN@IM^1L3F&]<DQ]ZG"HIDL+)V$D;FX8/P$3?X!B!WPV9QP+
FG32BE]XXB40BD4@D$HE$(I%()!*)1"*12"229_@)GWZ*5``H````
`
end

From bouncefilter Mon Nov 1 23:34:02 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 XAA67932
for <hackers@postgresql.org>; Mon, 1 Nov 1999 23:33:56 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org (dial-39.r12.ncbrvr.infoave.net [207.144.84.109])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id XAA01263;
Mon, 1 Nov 1999 23:33:50 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] change in name of perl?
Date: Mon, 1 Nov 1999 23:30:35 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Brook Milligan <brook@biology.nmsu.edu>, hackers@postgresql.org
References: <199911020235.VAA06571@candle.pha.pa.us>
In-Reply-To: <199911020235.VAA06571@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <99110123350403.07347@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Mon, 01 Nov 1999, Bruce Momjian wrote:

I had applied someone's patch so perl5 would be used, but that broke
many things. I fixed the current tree to use $(PERL) as defined in
Makefile.global. I just patched stable the same way. Please test.
Thanks.

No joy. the $(PERL) variable is apparently not being set -- the make goes out
at the line:
cd perl5 && Makefile.PL

(which should have that $(PERL) in there.....)

It is beginning to storm here, so I think I'd better shut down and unplug.
Will have at it at work tomorrow.

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

From bouncefilter Mon Nov 1 23:46:02 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 XAA69500
for <hackers@postgreSQL.org>; Mon, 1 Nov 1999 23:45:53 -0500 (EST)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id XAA09227;
Mon, 1 Nov 1999 23:44:56 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199911020444.XAA09227@candle.pha.pa.us>
Subject: Re: [HACKERS] change in name of perl?
In-Reply-To: <99110123350403.07347@lorc.wgcr.org> from Lamar Owen at "Nov 1,
1999 11:30:35 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Mon, 1 Nov 1999 23:44:55 -0500 (EST)
CC: Brook Milligan <brook@biology.nmsu.edu>, 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 Mon, 01 Nov 1999, Bruce Momjian wrote:

I had applied someone's patch so perl5 would be used, but that broke
many things. I fixed the current tree to use $(PERL) as defined in
Makefile.global. I just patched stable the same way. Please test.
Thanks.

No joy. the $(PERL) variable is apparently not being set -- the make goes out
at the line:
cd perl5 && Makefile.PL

(which should have that $(PERL) in there.....)

It is beginning to storm here, so I think I'd better shut down and unplug.
Will have at it at work tomorrow.

OK, fix applied. Seems like that fix wasn't in stable tree either.

-- 
  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 Nov 2 00:10:03 1999
Received: from csb.terror.de (csb.terror.de [195.243.98.220])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA81556
for <hackers@postgreSQL.org>; Tue, 2 Nov 1999 00:09:44 -0500 (EST)
(envelope-from wicki@terror.de)
Received: from localhost (wicki@localhost)
by csb.terror.de (8.8.8/8.8.8) with SMTP id GAA23644
for <hackers@postgreSQL.org>; Tue, 2 Nov 1999 06:09:42 +0100
X-Authentication-Warning: csb.terror.de: wicki owned process doing -bs
Date: Tue, 2 Nov 1999 05:09:42 +0000 (GMT)
From: "Victoria W." <wicki@terror.de>
To: hackers@postgreSQL.org
Subject: unsubscribe
Message-ID: <Pine.LNX.3.95.991102050853.23642A-100000@csb.terror.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

unsubscribe
unsubscribe hackers
unsubscribe hackers@postgreSQL.org

From bouncefilter Tue Nov 2 00:21:03 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 AAA88884
for <pgsql-hackers@postgreSQL.org>; Tue, 2 Nov 1999 00:20:22 -0500 (EST)
(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 AAA10590;
Tue, 2 Nov 1999 00:19:45 -0500 (EST)
To: "nicks.emails" <nicks.emails@ic24.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Backend terminated abnormally
In-reply-to: Your message of Mon, 01 Nov 1999 23:04:35 -0500
<10109.941515475@sss.pgh.pa.us>
Date: Tue, 02 Nov 1999 00:19:44 -0500
Message-ID: <10588.941519984@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I wrote:

Actually, the missing clue seems to be that it's cool on HPUX and
coredumps on Linux. Bigendian vs. littleendian bug maybe? I'm on
it...

Well, isn't *this* special: it seems that memmove(dest, NULL, n)
doesn't cause a coredump on HPUX, it just silently does nothing.
Sheesh. I hardly ever use memmove, or I would've found this out
before (and complained about it!).

Anyway, the answer to the original complaint is that geo_ops.c
is brimful of operators that think they can return a NULL pointer
and it'll be interpreted as returning an SQL NULL. They are
sadly misinformed. In the present state of fmgr() there isn't
any way for a binary operator to return NULL when its operands
are not null. Another reason we gotta redo the fmgr interface.

Nick, I'm afraid '#' is pretty seriously broken: it'll coredump
whenever presented non-intersecting segments, unless you are able
to recompile the system so that dereferencing a NULL pointer is
not a fatal error. Several of the other geometric operators have
similar problems. AFAICS there is not much that can be done to
patch around this; a proper fix will require some major changes
that we are planning for release 7.0. Sorry the news isn't better.

regards, tom lane

From bouncefilter Tue Nov 2 00:32:03 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 AAA90578
for <pgsql-hackers@postgreSQL.org>; Tue, 2 Nov 1999 00:31:39 -0500 (EST)
(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 AAA10626;
Tue, 2 Nov 1999 00:31:04 -0500 (EST)
To: t-ishii@sra.co.jp
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
In-reply-to: Your message of Tue, 02 Nov 1999 13:07:32 +0900
<199911020407.NAA01247@srapc451.sra.co.jp>
Date: Tue, 02 Nov 1999 00:31:04 -0500
Message-ID: <10624.941520664@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

I have compared current with 6.5 using 1000000 tuple-table (243MB) (I
wanted to try 2GB+ table but 6.5 does not work in this case). The
result was strange in that current is *faster* than 6.5!

RAID5
current 2:29
6.5.2 3:15

non-RAID
current 1:50
6.5.2 2:13

Seems my previous testing was done in wrong way or the behavior of
sorting might be different if the table size is changed?

Well, I feel better now, anyway ;-). I thought that my first cut
ought to have been about the same speed as 6.5, and after I added
the code to slurp up multiple tuples in sequence, it should've been
faster than 6.5. The above numbers seem to be in line with that
theory. Next question: is there some additional effect that comes
into play once the table size gets really huge? I am thinking maybe
there's some glitch affecting performance once the temp file size
goes past one segment (1Gb). Tatsuo, can you try sorts of say
0.9 and 1.1 Gb to see if something bad happens at 1Gb? I could
try rebuilding here with a small RELSEG_SIZE, but right at the
moment I'm not certain I'd see the same behavior you do...

regards, tom lane

From bouncefilter Tue Nov 2 00:45:03 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 AAA91808
for <pgsql-hackers@postgreSQL.org>; Tue, 2 Nov 1999 00:44:22 -0500 (EST)
(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 AAA10666;
Tue, 2 Nov 1999 00:43:21 -0500 (EST)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Regression Testing on REL6_5_PATCHES
In-reply-to: Your message of Mon, 1 Nov 1999 22:56:14 -0500
<99110123021602.07347@lorc.wgcr.org>
Date: Tue, 02 Nov 1999 00:43:21 -0500
Message-ID: <10664.941521401@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Lamar Owen <lamar.owen@wgcr.org> writes:

I have hit an unexpected error in regression testing the
REL6_5_PATCHES branch in preparing for 6.5.3. For the first time, a
test other than float or geometry failed -- with a weird result.
Datetime failed.

Yup, it's the biannual daylight-savings-time transition weirdness.
If you look closely, all those tests assume that today midnight to
tomorrow midnight is 24 hours. Guess what: at this time of year it
ain't. In another day or so the results will be back to normal, at
least in the US of A. We'll likely see another gripe or two from
overseas before the DST-switch season is over.

I've been around this project for a year and a half now, and we've
heard complaints like this at each of the three DST transitions that
I remember. (I sent in some alarmed reports myself, first time I
saw it.) I've tried to interest Thomas in DST-proofing the regress
tests, but he doesn't seem to think it's worth fixing.

There should be something about this in the "expected failures"
section of the regress test docs, but right at the moment I don't
see anything there.

regards, tom lane

From bouncefilter Mon Nov 1 17:20:59 1999
Received: from smtp.ic24.net (smtp-outbound2.ic24.net [195.44.63.15])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA13742
for <pgsql-hackers@postgresql.org>; Mon, 1 Nov 1999 17:20:30 -0500 (EST)
(envelope-from nicks.emails@ic24.net)
Received: from toshiba7020 ([195.44.209.228]) by smtp.ic24.net with Microsoft
SMTPSVC(5.5.1877.197.19); Mon, 1 Nov 1999 22:19:05 +0000
Message-ID: <007a01bf24fa$18704ca0$41646464@toshiba7020>
From: "nicks.emails" <nicks.emails@ic24.net>
To: <pgsql-hackers@postgresql.org>
Subject: Backend terminated abnormally
Date: Mon, 1 Nov 1999 22:18:34 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0077_01BF24B7.0958E8A0"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0077_01BF24B7.0958E8A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

I not sure if I have got the right person for this but if you could help =
me it would be extremely helpful;

The problem is with the following query,

select l.s # p.ss from LSEG_TBL l, LSEG_TBL1 p;

when I try to execute this intersection on the tables that are in the =
regression queries the following message is printed to the screen,

I created two tables with the exact lseg coordinates in both to see what =
happened and also with disimilar lseg points so that there was lines =
intersecting,
and recieved the same message

pgReadData() --backend closed the channel unexpectedly.

This problem means the backend terminated abnormally=20
before or while processing the request

We have lost the connection to the backend, so further processing is =
impossible.
Terminating.
=20
Please could give me some pointers as to where I could look or if =
necesarry download any patches to fix it.

I am running Redhat 5.2 on an i486-pc-linux-gnu
version of postgres is 6.5.2
version of gcc is 2.7.2.3

Thank you in advance.

Nick O'Malley nicks.emails@ic24.net=20

------=_NextPart_000_0077_01BF24B7.0958E8A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I not sure if I have got the right =
person for this=20
but if you could help me it would be extremely helpful;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The problem is with the following=20
query,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>select l.s # p.ss from LSEG_TBL l, =
LSEG_TBL1=20
p;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>when I try to execute this intersection =
on the=20
tables that are in the regression&nbsp;queries the following message is =
printed=20
to the screen,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>I created two tables with the exact lseg coordinates in both to see =
what=20
happened and also with disimilar lseg points so that there was lines=20
intersecting,</DIV>
<DIV>and recieved the same message</DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG><FONT face=3DArial size=3D3>pgReadData() --backend closed =
the channel=20
unexpectedly.</FONT></STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG><FONT face=3DArial size=3D3>This problem means the backend =
terminated=20
abnormally </FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3DArial size=3D3>before or while processing the=20
request</FONT></STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG><FONT face=3DArial size=3D3>We have lost the connection to =
the backend,=20
so further processing is impossible.</FONT></STRONG></DIV>
<DIV><FONT face=3DArial =
size=3D3><STRONG>Terminating.</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Please could give me some pointers as =
to where I=20
could look or if&nbsp;necesarry download any patches to fix =
it.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I&nbsp;am running Redhat 5.2 on an=20
i486-pc-linux-gnu</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>version of postgres is =
6.5.2</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>version of gcc is 2.7.2.3</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you in advance.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Nick O'Malley&nbsp;<A=20
href=3D"mailto:nicks.emails@ic24.net">nicks.emails@ic24.net</A></FONT>&nb=
sp;</DIV></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0077_01BF24B7.0958E8A0--

From bouncefilter Tue Nov 2 03:05:07 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 DAA09539
for <pgsql-hackers@postgreSQL.org>; Tue, 2 Nov 1999 03:04:52 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id A4CF94156; Tue, 2 Nov 1999 09:03:55 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <381E8CDA.D9B3FB43@tm.ee>
Date: Tue, 02 Nov 1999 07:03: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: t-ishii@sra.co.jp
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Don Baccus <dhogaza@pacifier.com>,
Mike Mascari <mascarim@yahoo.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] sort on huge table
References: <199911020407.NAA01247@srapc451.sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tatsuo Ishii wrote:

... I agree this'd be worth trying. There could be some subtle effect
somewhere in RAID5 that's tripping things up. It'd also be useful if
someone could try it on similar RAID hardware with a non-Linux kernel.

I have compared current with 6.5 using 1000000 tuple-table (243MB) (I
wanted to try 2GB+ table but 6.5 does not work in this case). The
result was strange in that current is *faster* than 6.5!

RAID5
current 2:29
6.5.2 3:15

non-RAID
current 1:50
6.5.2 2:13

Seems my previous testing was done in wrong way or the behavior of
sorting might be different if the table size is changed?

Or the behaviour of RAID5 changes at some size.

I have set up an IBM Netfinity server with specs similar to yours, except
that it has 1G memory and 5x9GB disks. The RAID controller is IBM ServeRAID.

It seems that when I try to write over 60 MB sequentially, the write
performance drops from over 50MB/s to under 2MB/s.

Maybe such behaviour would suggest that building an index and traversing
that could be faster than full sort ?

The same tests on my single Celeron 450 produced ~10MB/s writes
whatever the size.

Anyway, here is my test script.
First, edit Makefile to set DB and number of tuples. Then run type
make. That's all.

I'll try to run it tonight (in GMT+2 tz).

Can't run it earlyer as it is a production site and a highly
visible web-server.

If I have the time I'll even try my index theory.

--------
Hannu

From bouncefilter Tue Nov 2 02:16:04 1999
Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194])
by hub.org (8.9.3/8.9.3) with SMTP id CAA01085
for <pgsql-hackers@postgreSQL.org>; Tue, 2 Nov 1999 02:15:24 -0500 (EST)
(envelope-from akorud@polynet.lviv.ua)
Received: (qmail 35716 invoked from network); 2 Nov 1999 07:15:16 -0000
Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown)
by unknown with SMTP; 2 Nov 1999 07:15:16 -0000
Received: (qmail 72567 invoked from network); 2 Nov 1999 07:15:15 -0000
Received: (ofmipd unknown); 2 Nov 1999 07:14:53 -0000
Date: 2 Nov 1999 09:15:14 +0200
Message-ID: <Pine.BSF.3.96.991102091217.71755A-100000@NetSurfer.lp.lviv.ua>
From: "Andrij Korud" <akorud@polynet.lviv.ua>
To: "Jan Wieck" <wieck@debis.com>
Cc: pgsql-hackers@postgreSQL.org
X-Sender: akorud@NetSurfer.lp.lviv.ua
Subject: Re: [HACKERS] Get OID of just inserted record
In-Reply-To: <m11iSOS-0003kLC@orion.SAPserv.Hamburg.dsh.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 2 Nov 1999, Jan Wieck wrote:

Hi,
Is there any way to obtain an OID of record just inserted by SPI_execp?

How should that work consistenty? What do you expect as
return if the query executed was an

INSERT INTO t2 SELECT * FROM t1;

The first, a random one or the last of the two million rows
inserted?

My question is:
"CREATE TABLE t1 (word text)"
"INSERT INTO t1 VALUES('xxx')" (using SPI_execp)

So, is there any way to obtain OID of word 'xxx' just after insertion
without doing "SELECT oid FROM t1 WHERE word='xxx'"?

Thanks in advance,
Andriy Korud, Lviv, Ukraine