Another Date question

your may need to make a simple function. see function in doc.

On Thu, 2 Dec 1999, Andy Lewis wrote:

Hello All!

I'd like to create a table with a datetime field that defaults to +60
days.

mydate datetime default 'now() +@60 days',
...

Doesn't seem to work.

What am I missing?

Thanks

Andy

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

From bouncefilter Fri Dec 3 01:29:16 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 BAA04648
for <pgsql-hackers@postgresql.org>; Fri, 3 Dec 1999 01:28:47 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id PAA19098
for <pgsql-hackers@postgresql.org>; Fri, 3 Dec 1999 15:28:45 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id PAA05173
for <pgsql-hackers@postgresql.org>; Fri, 3 Dec 1999 15:28:44 +0900
To: pgsql-hackers@postgresql.org
Subject: postmaster.pid
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991203152844N.t-ishii@sra.co.jp>
Date: Fri, 03 Dec 1999 15:28:44 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 39

Hi,

I have committed changes to postmaster.c. Now it creates a file called
"postmaster.pid" under $PGDATA, which holds postmaster's process
id. If the file has already existed, postmaster won't start. So we
cannot start more than on postmaster with same $PGDATA any more. I
believe it's a good thing. The file will be deleted upon postmaster
shutting down.

Another file "postmaster.opts" is also created under $PGDATA. It
contains the path to postmaster and each option for postmaster per
line. Example contents are shown below:

/usr/local/pgsql/bin/postmaster
-p 5432
-D /usr/local/pgsql/data
-B 64
-b /usr/local/pgsql/bin/postgres
-N 32
-S

Note that even options execpt -S is not explicitly supplied in the
case above (postmaster -S), other opts are shown. This file is not
only convenient to restart postmaster but also is usefull to determin
with what defaults postmaster is running, IMHO.

With these changes now we can stop postmaster:

kill `cat /usr/local/pgsql/data/postmaster.pid`

To restart it with previous options:

eval `cat /usr/local/pgsql/data/postmaster.opts`

I'm going to write pg_ctl script this week end.

BTW, no initdb required, of course.
--
Tatsuo Ishii

I finished the book (version Nov 30). It is a very good one. clear and
straight to the point.
some comments:
A)
here are my 2-cents:
1)I found a type in p55 line 4552: "than" should be "that".
2) when I read it, I feel the data in the example should be given.
i.e., all the inserts should be given (esp. on p58).
B)
here is a big question: why you say that normalization is good for
data retreval (page 43 )? If my memory not wrong, it is ONLY good for data
update/insert/delete.

C) here is the main concern: sql92.
1) page3, after talk oss, the book should mention sql92;
and treat the whole book accordingly (see next).
2) page10, \g should not be used as recommened one. ; should be used.
this is not sql92 (?), but ";" is certainly the most used.
3) page19: single quotation mark should be mentioned as the prefered
one. (sql92 ).
4) page23: /* */ should be mentioned that it is not sql92.
5) page27: != is not sql92.
6) page28: regex is not sql92, so, should be considered ONLY
after tried like ;
7) page31: in "case", should indicate that "end" is not needed in sql92,
and thus very likely later version of pg may also not need end.
8) page61: oid should be used in caution, because, in short, it is not in
sql92.

in short, all non-necessary non-sql92 features should be put into
secondary position. all important feature that is not sql92 should
be pointed out.

we OSS/PG people should differentiate/advertize ourselves as
standard-keeper. so, this book should keep this as the main topic.
It will NOT confuse new user/beginner, if handled consistantly.
Also, it will add the worth-value for old pg user for sql92 info.

hope this book will not like all other vendor-oriented books where
as if sql86/92 never exists! sql86/92 are our friends, even family member!

Kai

From bouncefilter Fri Dec 3 02:34:17 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA16319
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 02:33:09 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
CAA06648;
Fri, 3 Dec 1999 02:30:41 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912030730.CAA06648@candle.pha.pa.us>
Subject: Re: [HACKERS] postmaster.pid
In-Reply-To: <19991203152844N.t-ishii@sra.co.jp> from Tatsuo Ishii at "Dec 3,
1999 03:28:44 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Fri, 3 Dec 1999 02:30:40 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

I have committed changes to postmaster.c. Now it creates a file called
"postmaster.pid" under $PGDATA, which holds postmaster's process
id. If the file has already existed, postmaster won't start. So we
cannot start more than on postmaster with same $PGDATA any more. I
believe it's a good thing. The file will be deleted upon postmaster
shutting down.

I assume you do a kill(0) on the pid if the file exists on startup to
check to see if the pid is still valid?

-- 
  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 Dec 3 02:57:17 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 CAA19881
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 02:56:20 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id QAA23971;
Fri, 3 Dec 1999 16:56:15 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id QAA06052;
Fri, 3 Dec 1999 16:56:15 +0900
To: pgman@candle.pha.pa.us
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster.pid
In-Reply-To: Your message of "Fri, 3 Dec 1999 02:30:40 -0500 (EST)"
<199912030730.CAA06648@candle.pha.pa.us>
References: <199912030730.CAA06648@candle.pha.pa.us>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991203165614N.t-ishii@sra.co.jp>
Date: Fri, 03 Dec 1999 16:56:14 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 20

I have committed changes to postmaster.c. Now it creates a file called
"postmaster.pid" under $PGDATA, which holds postmaster's process
id. If the file has already existed, postmaster won't start. So we
cannot start more than on postmaster with same $PGDATA any more. I
believe it's a good thing. The file will be deleted upon postmaster
shutting down.

I assume you do a kill(0) on the pid if the file exists on startup to
check to see if the pid is still valid?

A little bit different.

1) if the port is already in use, postmaster exits (same as before)

2) if it fails to create pid file, call
ExitPostmaster(1). ExitPostmaster calls proc_exit() and proc_exit
calls exit().
--
Tatsuo Ishii

I finished the book (version Nov 30). It is a very good one. clear and
straight to the point.
some comments:
A)
here are my 2-cents:
1)I found a type in p55 line 4552: "than" should be "that".

Fixed. Thanks.

2) when I read it, I feel the data in the example should be given.
i.e., all the inserts should be given (esp. on p58).

Well, the issue here is that I really have not developed enough data to
show a meaningful output for this, and I don't think it is worth the
major space needed to insert it. That is why I left it out.

B)
here is a big question: why you say that normalization is good for
data retreval (page 43 )? If my memory not wrong, it is ONLY good for data
update/insert/delete.

Changed to 'data lookup' because without normalization, you can't lookup
information about a specific customer very easily.

C) here is the main concern: sql92.
1) page3, after talk oss, the book should mention sql92;
and treat the whole book accordingly (see next).

I disagree. This is an intro/concepts. I emphasize standard SQL ways
as much as possible. Yesterday I changed now() to CURRENT_TIMESTAMP for
this reason, and if you see any other cases where I use non-standard
more, let me know. However, this is just to get them started. They
want results. Worrying about standard SQL at this point is not a good
idea. Get them started first. I emphasize that, but don't want to be
pointing out saying "don't do this, and don't do that" at this point.

2) page10, \g should not be used as recommened one. ; should be used.
this is not sql92 (?), but ";" is certainly the most used.

\g used very rarely, but it should be shown to show consistency with
other psql commands.

3) page19: single quotation mark should be mentioned as the prefered
one. (sql92 ).

single mentioned first.

4) page23: /* */ should be mentioned that it is not sql92.

Mentioned last.

5) page27: != is not sql92.

Many db's support this.

6) page28: regex is not sql92, so, should be considered ONLY
after tried like ;

Again, see above.

7) page31: in "case", should indicate that "end" is not needed in sql92,
and thus very likely later version of pg may also not need end.

No need.

8) page61: oid should be used in caution, because, in short, it is not in
sql92.

in short, all non-necessary non-sql92 features should be put into
secondary position. all important feature that is not sql92 should
be pointed out.

we OSS/PG people should differentiate/advertize ourselves as
standard-keeper. so, this book should keep this as the main topic.
It will NOT confuse new user/beginner, if handled consistantly.
Also, it will add the worth-value for old pg user for sql92 info.

hope this book will not like all other vendor-oriented books where
as if sql86/92 never exists! sql86/92 are our friends, even family member!

That is not the scope of this book.

-- 
  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 Dec 3 03:09:18 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA26040
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 03:08:44 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
DAA07950;
Fri, 3 Dec 1999 03:06:56 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912030806.DAA07950@candle.pha.pa.us>
Subject: Re: [HACKERS] postmaster.pid
In-Reply-To: <19991203165614N.t-ishii@sra.co.jp> from Tatsuo Ishii at "Dec 3,
1999 04:56:14 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Fri, 3 Dec 1999 03:06:56 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have committed changes to postmaster.c. Now it creates a file called
"postmaster.pid" under $PGDATA, which holds postmaster's process
id. If the file has already existed, postmaster won't start. So we
cannot start more than on postmaster with same $PGDATA any more. I
believe it's a good thing. The file will be deleted upon postmaster
shutting down.

I assume you do a kill(0) on the pid if the file exists on startup to
check to see if the pid is still valid?

A little bit different.

1) if the port is already in use, postmaster exits (same as before)

OK

2) if it fails to create pid file, call
ExitPostmaster(1). ExitPostmaster calls proc_exit() and proc_exit
calls exit().

So you don't start if the pid file is there, or do you delete it if the
port is free?

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

From bouncefilter Fri Dec 3 03:17:17 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 DAA27813
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 03:17:04 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id RAA25320;
Fri, 3 Dec 1999 17:17:02 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id RAA06351;
Fri, 3 Dec 1999 17:17:01 +0900
To: pgman@candle.pha.pa.us
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster.pid
In-Reply-To: Your message of "Fri, 3 Dec 1999 03:06:56 -0500 (EST)"
<199912030806.DAA07950@candle.pha.pa.us>
References: <199912030806.DAA07950@candle.pha.pa.us>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991203171701B.t-ishii@sra.co.jp>
Date: Fri, 03 Dec 1999 17:17:01 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 19

2) if it fails to create pid file, call
ExitPostmaster(1). ExitPostmaster calls proc_exit() and proc_exit
calls exit().

So you don't start if the pid file is there,

Right.

or do you delete it if the
port is free?

No. even if the port is free, there might be another postmaster that
uses another one.

Wait, maybe I can check postmaster.opts to see if another postamster
really exists...
--
Tatsuo Ishii

From bouncefilter Fri Dec 3 03:35:17 1999
Received: from sirius.edu.sollentuna.se (sirius.edu.sollentuna.se
[195.67.128.12]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA31550
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 03:34:23 -0500 (EST)
(envelope-from mha@sollentuna.net)
Received: by sirius.edu.sollentuna.se with Internet Mail Service (5.5.2448.0)
id <WJ7XNG1P>; Fri, 3 Dec 1999 09:34:18 +0100
Message-ID:
<215896B6B5E1CF11BC5600805FFEA821026E0C6D@sirius.edu.sollentuna.se>
From: Magnus Hagander <mha@sollentuna.net>
To: "'Lamar Owen'" <lamar.owen@wgcr.org>, Vince Vielhaber <vev@michvhf.com>
Cc: Joe Brenner <doom@kzsu.stanford.edu>, pgsql-hackers@postgreSQL.org,
Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: RE: [HACKERS] perl-DBD-Pg (was Re: BOUNCE pgsql-ports@postgreSQL
.org:Non-member submission from[Joe Brenner <doom@kzsu.stanford.edu>]
(f wd))
Date: Fri, 3 Dec 1999 09:34:17 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"

On Thu, 2 Dec 1999, Lamar Owen wrote:

Where is 'linux.postgres', and how do I subscribe??

UseNet. It's a newsgroup.

That's what I was hoping, but, these days, you never know
what's in what
heirarchy. HOWEVER, my ISP's nntp server doesn't carry it.
Do you know
of a public nntp server that carries this??

news.edu.sollentuna.se. It's read-only when you're from the outside, though.

//Magnus

From bouncefilter Fri Dec 3 03:41:17 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA32725
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 03:40:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
DAA08933;
Fri, 3 Dec 1999 03:38:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912030838.DAA08933@candle.pha.pa.us>
Subject: Re: [HACKERS] postmaster.pid
In-Reply-To: <19991203171701B.t-ishii@sra.co.jp> from Tatsuo Ishii at "Dec 3,
1999 05:17:01 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Fri, 3 Dec 1999 03:38:02 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

2) if it fails to create pid file, call
ExitPostmaster(1). ExitPostmaster calls proc_exit() and proc_exit
calls exit().

So you don't start if the pid file is there,

Right.

or do you delete it if the
port is free?

No. even if the port is free, there might be another postmaster that
uses another one.

Wait, maybe I can check postmaster.opts to see if another postamster
really exists...

You can do kill(0) on the pid to see if it is actually a real pid.
Rather than playing with the port, just check the pid because the
postmaster could be startup up by not on the port yet.

-- 
  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 Dec 3 03:44:17 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 DAA33121
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 03:43:53 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id RAA26794;
Fri, 3 Dec 1999 17:43:51 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id RAA06740;
Fri, 3 Dec 1999 17:43:51 +0900
To: pgman@candle.pha.pa.us
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster.pid
In-Reply-To: Your message of "Fri, 3 Dec 1999 03:38:02 -0500 (EST)"
<199912030838.DAA08933@candle.pha.pa.us>
References: <199912030838.DAA08933@candle.pha.pa.us>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991203174351M.t-ishii@sra.co.jp>
Date: Fri, 03 Dec 1999 17:43:51 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 10

Wait, maybe I can check postmaster.opts to see if another postamster
really exists...

You can do kill(0) on the pid to see if it is actually a real pid.
Rather than playing with the port, just check the pid because the
postmaster could be startup up by not on the port yet.

Oh, I see your point now.
--
Tatsuo Ishii

On Thu, 2 Dec 1999, Andy Lewis wrote:

Hello All!

I'd like to create a table with a datetime field that defaults to +60
days.

mydate datetime default 'now() +@60 days',
...

Where is a problem?

You can use "now() + 60"

See:

test=> create table d (x text, d datetime default now() + 60);
CREATE
test=> insert into d values ('hello');
INSERT 506143 1
test=> select * from d;
x |d
-----+----------------------------
hello|Tue Feb 01 00:00:00 2000 CET
(1 row)

But problem is if you want change other datetime value (min,sec,year..etc),
you can use to_char/from_char datetime routines from CVS tree:

select from_char(
to_char('now'::datetime,'MM ') || --- Month
to_char('now'::datetime,'DD')::int +60 || --- Day + 60
to_char('now'::datetime,' YYYY HH24:MI:SS'), --- Year,hour,min,sec
'FMMM FMDD YYYY HH24:MI:SS'); --- Make datetime

----------------------------
Tue Feb 01 13:30:37 2000 CET --- Output datetime
(1 row)

Yes, it is a lot of complicated, but if you a little change this example,
you can use it for increment a arbitrary datetime number (sec,min..).

I agree with your now() + '60 days' is better and easy, but for this we need
new "datetime + text" oprerator, now is date_pli(dateVal, days) only.

My first idea is "to_char" operator as:
datetime + 'to_char format pictures string' example:

datetime + '05 DD 10 HH12'
(add 5days and 10hours to datetime)

For this is parser in to-from_char module.

Or second idea is make it as easy:
datetime + '10 day' or
datetime + '2 year' ..etc.

But I'm not sure what is better or exists it in other SQL.

.... Any comment Thomas?

Karel

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

Docs: http://docs.linux.cz (big docs archive)
Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
-----------------------------------------------------------------------

From bouncefilter Fri Dec 3 13:17:19 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id NAA44221
for pgsql-hackers@postgresql.org; Fri, 3 Dec 1999 13:16:41 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: Olivier PRENANT <ohp@pyrenet.fr>
X-Newsgroups: comp.databases.postgresql.hackers
Subject: postgresql authentification for popper
Date: Fri, 03 Dec 1999 13:55:56 +0100
Organization: PYRENET
Lines: 19
Message-ID: <3847BDDC.6999B7D9@pyrenet.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: floppy.pyrenet.fr 944225756 28849 194.250.190.1 (3 Dec 1999 12:55:56
GMT)
X-Complaints-To: newsmaster@pyrenet.fr
X-Mailer: Mozilla 4.08 [fr] (X11; I; UnixWare 5 i386)
To: pgsql-hackers@postgresql.org

Hi everyone,

I working on a project that will handle around 50000 mailboxes at least.

I have no problem with the system or sendmail. But I'm afraid that
popper (either pop3 or imap) won't be able to authentificate users the
standard way (/etc/passwd) does anyone knows if a version of imapd or
ipop3d has been modified to allow postgresql authentification.

If not, could you give me some pointers.

Regards to you all
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

From bouncefilter Fri Dec 3 09:33:04 1999
Received: from www.geocrawler.com (sourceforge.net [209.81.8.17])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA33156
for <pgsql-hackers@hub.org>; Fri, 3 Dec 1999 09:32:25 -0500 (EST)
(envelope-from nobody@www.geocrawler.com)
Received: (from nobody@localhost)
by www.geocrawler.com (8.9.3/8.9.3) id GAA19000;
Fri, 3 Dec 1999 06:32:14 -0800
Date: Fri, 3 Dec 1999 06:32:14 -0800
Message-Id: <199912031432.GAA19000@www.geocrawler.com>
To: pgsql-hackers@hub.org
Subject: Brain-Dead Sort Algorithm??
From: "Tim Perdue" <archiver@db.geocrawler.com>
Reply-To: "Tim Perdue" <tim@perdue.net>

This message was sent from Geocrawler.com by "Tim Perdue" <tim@perdue.net>
Be sure to reply to that address.

It uses over 1GB of disk space to do that sort,
and it would have used a lot more if I hadn't

run

out.

Then it won't fail gracefully, instead of just
hangs and leaves temp files completely filling

up

the hard drive.

Because maybe you're doing a really dumb join

before you

sort? SQL is full of such "gotchas".

No, sorry.

select distinct serial into serial_good from
serial_half;

serial_half is a 1-column list of 10-digit
numbers. I'm doing a select distinct because I
believe there may be duplicates in that column.

The misunderstanding on my end came because
serial_half was a 60MB text file, but when it was
inserted into postgres, it became 345MB (6.8
million rows has a lot of bloat apparently).

So the temp-sort space for 345MB could easily
surpass the 1GB I had on my hard disk. Although
how anyone can take a 60MB text file and turn it
into > 1GB is beyond me.

And, of course, you've posed your question

stupidly - "my query's

slow, why is Postgres so horrible?" and you

haven't bothered posting

your query.

None of that was ever stated.

Actually what was stated is that it is retarded to
fill up a hard disk and then hang instead of
bowing out gracefully, forcing the user to
manually delete the temp_sort files and kill -9
postgres.

You can't argue with that portion.

And it happens on v6.4, v6.4.2, and v6.5.2 on RHAT
6.1, and LinuxPPC.

Yes, my post was rather harsh - I posted it when I
was pissed and that was a mistake. I had this
same problem in March when trying to sort a 2.5GB
file with 9GB free.

I use postgres on every project I work on,
including this site, Geocrawler.com, and my
PHPBuilder.com site, because it's a decent and
free database and it will scale beyond 2GB, unlike
MySQL.

Tim

Geocrawler.com - The Knowledge Archive

From bouncefilter Fri Dec 3 10:22:44 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA48599
for <pgsql-hackers@hub.org>; Fri, 3 Dec 1999 10:21:50 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by trends.net (8.8.8/8.8.8) with ESMTP id KAA06510
for <pgsql-hackers@hub.org>; Fri, 3 Dec 1999 10:04:23 -0500 (EST)
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 KAA01453;
Fri, 3 Dec 1999 10:03:19 -0500 (EST)
To: "Tim Perdue" <tim@perdue.net>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] Brain-Dead Sort Algorithm??
In-reply-to: Your message of Fri, 3 Dec 1999 06:32:14 -0800
<199912031432.GAA19000@www.geocrawler.com>
Date: Fri, 03 Dec 1999 10:03:19 -0500
Message-ID: <1451.944233399@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Tim Perdue" <archiver@db.geocrawler.com> writes:

serial_half is a 1-column list of 10-digit
numbers. I'm doing a select distinct because I
believe there may be duplicates in that column.

The misunderstanding on my end came because
serial_half was a 60MB text file, but when it was
inserted into postgres, it became 345MB (6.8
million rows has a lot of bloat apparently).

The overhead per tuple is forty-something bytes, IIRC. So when the only
useful data in a tuple is an int, the expansion factor is unpleasantly
large. Little to be done about it though. All the overhead fields
appear to be necessary if you want proper transaction semantics.

So the temp-sort space for 345MB could easily surpass the 1GB I had on
my hard disk.

Yes, the merge algorithm used up through 6.5.* seems to have typical
space usage of about 4X the actual data volume. I'm trying to reduce
this to just 1X for 7.0, although some folks are complaining that the
result is slower than before :-(.

Actually what was stated is that it is retarded to fill up a hard disk
and then hang instead of bowing out gracefully,

Yup, that was a bug --- failure to check for write errors on the sort
temp files. I believe it's fixed in current sources too.

regards, tom lane

From bouncefilter Fri Dec 3 10:27:13 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 KAA50574
for <hackers@postgreSQL.org>; Fri, 3 Dec 1999 10:26:38 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm219.noc.fukui.nsk.ne.jp [210.161.188.94])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id AAA00408; Sat, 04 Dec 1999 00:24:20 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Vadim Mikheev" <vadim@krs.ru>,
"PostgreSQL Developers List" <hackers@postgreSQL.org>
Subject: RE: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Date: Sat, 4 Dec 1999 00:24:28 +0900
Message-ID: <NABBINCKAKFCDDKMMJHGMEJFDMAA.Inoue@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <001b01bf3c60$0b811880$2801007e@cadzone.tpf.co.jp>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

-----Original Message-----
From: owner-pgsql-hackers@postgresql.org
[mailto:owner-pgsql-hackers@postgresql.org]On Behalf Of Tom Lane

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

I propose here that we stop the release of lock before end of

transaction.

I have been suffering from the early release of lock.

If there's no objection,I would change UnlockRelation() to

not release

the specified lock except AccessShareLock.

After thinking about this some more, I am not convinced that it will buy
anything --- and it might possibly break things that work now. The
reason I'm not convinced about it is that we cannot apply the "don't
release locks till end of transaction" rule perfectly uniformly. You

Why are we allowed to break 2 phase locking for system tables ?
Isn't 2 phase locking a fundamental principle to preserve consistency ?
If there's another principle to rely on,please teach me.

already propose not to treat AccessShareLock that way, and Vadim seems
to think there will be other cases where we need to break the rule.
So we won't have a theoretically-clean situation anyway, and will have
to look at things case by case.

OK case by case. I will be glad to check them one by one.

I'm checking them for AccessExclusiveLock now.

As for RowExclusiveLock,it would be much effective to remove
the release of lock unconditionally.
RowExclusiveLock isn't so intensive a lock. For example it
doesn't conflict relatively. Therefore it would be hard to find
and resolve the bugs which are caused by the early release
of RowExclusiveLock,deadlock etc ...
Holding the lock a little longer won't be so harmful inversely.

Comments ?

As for AccessExclusiveLock I found followings now.

1) commands/user.c(CREATE/DROP/ALTER USER)
I could create same 2 users easily.
The lock should be held till end of trancaction.

2) commands/cluster.c(CLUSTER)
It isn't properly implemented. It seems almost impossible
to implement CLUSTER command properly in current spec.

3) commands/dbcommands.c(DROP DATABASE)
elog(ERROR) follows immediately. The release should
be removed.

4) commands/sequence.c(CREATE SEQUNECE)
The lock is for the being created (sequence) relation.
Holding the lock till end of transaction has no problem.

5) commands/vacuum.c(VACUUM)
The release is caused by new security check. Probably
the check could be done before acquiring AccessExcl-
usiveLock.

6) commands/commands.c(ALTER TABLE)
ALTER TABLE doesn't release AccessExclusiveLock till
end of transaction. I couldn't find any reason to allow
the release for inheritors of a relation class. The release
should be removed.

7) commands/async.c(LISTEN/UNLISTEN)
This case seems dangerous too but unfortunately I couldn't
point out a concrete flaw now.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

I'd like to create a table with a datetime field that defaults to +60
days.
mydate datetime default 'now() +@60 days',
...

Where is a problem?

You have enclosed your default values into a large string, rather than
letting them be evaluated as an expression:

mydate datetime default (now() + '60 days')

where the outer parens are optional.

datetime + '10 day' or
datetime + '2 year' ..etc.
But I'm not sure what is better or exists it in other SQL.

afaik this is the simplest and most direct way to do it. Note that you
can include other timespan fields in the constant:

mydate datetime default (now() + '60 days 10 hours')

HTH

- Thomas

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

On Fri, 3 Dec 1999, Thomas Lockhart wrote:

afaik this is the simplest and most direct way to do it. Note that you
can include other timespan fields in the constant:

mydate datetime default (now() + '60 days 10 hours')

Sorry, sooooorry, I total bad see in source and docs, my previous letter
is good for /dev/null only...

Again sorry
Karel

From bouncefilter Fri Dec 3 11:06:13 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA64173
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 11:05:15 -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 LAA09597;
Fri, 3 Dec 1999 11:05:05 -0500
Message-ID: <3847EA2A.B8E56D95@wgcr.org>
Date: Fri, 03 Dec 1999 11:04:58 -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: Magnus Hagander <mha@sollentuna.net>
CC: Vince Vielhaber <vev@michvhf.com>, Joe Brenner <doom@kzsu.stanford.edu>,
pgsql-hackers@postgreSQL.org, Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] perl-DBD-Pg (was Re: BOUNCE
pgsql-ports@postgreSQL.org:Non-member submission from[Joe Brenner
<doom@kzsu.stanford.edu>] (fwd))
References:
<215896B6B5E1CF11BC5600805FFEA821026E0C6D@sirius.edu.sollentuna.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Magnus Hagander wrote:

Do you know
of a public nntp server that carries this??

news.edu.sollentuna.se. It's read-only when you're from the outside, though.

Thanks. I'll see if I can't get my ISP's newsadmin to carry it, but for
now this will help for reading this low volume group -- I'll have to
swing over to deja to post, though. Oh well.

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

From bouncefilter Fri Dec 3 11:24:13 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA68849
for <pgsql-hackers@hub.org>; Fri, 3 Dec 1999 11:23:13 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA13431;
Fri, 3 Dec 1999 16:25:41 GMT
Sender: lockhart@hub.org
Message-ID: <3847EF05.9A74386@alumni.caltech.edu>
Date: Fri, 03 Dec 1999 16:25:41 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Perdue <tim@perdue.net>
CC: pgsql-hackers@hub.org
Subject: Re: [HACKERS] Brain-Dead Sort Algorithm??
References: <199912031432.GAA19000@www.geocrawler.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

serial_half is a 1-column list of 10-digit
numbers. I'm doing a select distinct because I
believe there may be duplicates in that column.

The misunderstanding on my end came because
serial_half was a 60MB text file, but when it was
inserted into postgres, it became 345MB (6.8
million rows has a lot of bloat apparently).

So the temp-sort space for 345MB could easily
surpass the 1GB I had on my hard disk. Although
how anyone can take a 60MB text file and turn it
into > 1GB is beyond me.

Sigh. Y'all like the sweeping statement, which got you in a bit of
trouble the first time too :)

Without knowing your schema, I can't say why you have *exactly* the
storage requirement you see. But, you have chosen the absolute worst
case for *any* relational database: a schema with only a single, very
small column.

For Postgres (and other DBs, but the details will vary) there is a 36
byte overhead per row to manage the tuple and the transaction
behavior. So if you stored your data as int8 (int4 is too small for 10
digits, right?) I see an average usage of slightly over 44 bytes per
row (36+8). So, for 6.8 million rows, you will require 300MB. I'm
guessing that you are using char(10) fields, which gives 50 bytes/row
or a total of 340MB, which matches your number to two digits.

Note that the tuple header size will stay the same (with possibly some
modest occasional bumps) for rows with more columns, so the overhead
decreases as you increase the number of columns in your tables.

By the way, I was going to say to RTFM, but I see a big blank spot on
this topic (I could have sworn that some of the info posted to the
mailing lists on this topic had made it into the manual, but maybe
not).

Does anyone see where this is in the docs, or have an interest in
writing a bit? The place is doc/src/sgml/storage.sgml and page.sgml
...

Good luck.

- Thomas

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

From bouncefilter Fri Dec 3 11:29:13 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA70333
for <hackers@postgresql.org>; Fri, 3 Dec 1999 11:28:50 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA13440;
Fri, 3 Dec 1999 16:30:58 GMT
Sender: lockhart@hub.org
Message-ID: <3847F042.5ABEB7A@alumni.caltech.edu>
Date: Fri, 03 Dec 1999 16:30:58 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Lamar Owen <lamar.owen@wgcr.org>, Vince Vielhaber <vev@michvhf.com>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [Fwd: postgresql-6.5.3. RPMs (Well Done!)]
References: <3846E209.533B8AD4@wgcr.org>
<3847DB40.4BD58DD6@alumni.caltech.edu>
<3847DDA0.75D4EAFE@wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oh, and the 6.5.3-2 RPMs are ready whenever you want to upload them to
ftp.postgresql.org. They're in the usual place on ramifordistat.net.

Ah, I should have mentioned: I found a missing file in the 6.5.3-1
RPMs I was repackaging (and using!) for Mandrake. libpq++.H isn't
copied to /usr/include/pgsql/ due to the bizarre cap H in the file
name.

Vince, is there any real reason to keep this "cap H" convention? It is
the only file in the whole distro which has this, and it causes
problems for packagers and perhaps for Makefiles and emacs-like
editors.

- Thomas

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

From bouncefilter Fri Dec 3 11:32:14 1999
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA72080
for <pgsql-hackers@postgresql.org>; Fri, 3 Dec 1999 11:31:20 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.28.74.220]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Fri, 3 Dec 1999 10:23:13 -0600
Sender: ed
Message-ID: <3847F068.6B8EC770@austin.rr.com>
Date: Fri, 03 Dec 1999 10:31:36 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] postmaster.pid
References: <19991203152844N.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tatsuo Ishii wrote:

Another file "postmaster.opts" is also created under $PGDATA. It
contains the path to postmaster and each option for postmaster per
line. Example contents are shown below:

/usr/local/pgsql/bin/postmaster
-p 5432
-D /usr/local/pgsql/data
-B 64
-b /usr/local/pgsql/bin/postgres
-N 32
-S

Note that even options execpt -S is not explicitly supplied in the
case above (postmaster -S), other opts are shown. This file is not
only convenient to restart postmaster but also is usefull to determin
with what defaults postmaster is running, IMHO.

It's not quite clear to me: Do command line options override
postmaster.opts options? (I would expect them to.)

Cheers.
Ed

From bouncefilter Fri Dec 3 11:40:14 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 LAA74447
for <hackers@postgresql.org>; Fri, 3 Dec 1999 11:39:51 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 21628 invoked by uid 1001); 3 Dec 1999 16:39:53 -0000
Date: Fri, 3 Dec 1999 11:39:53 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Lamar Owen <lamar.owen@wgcr.org>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [Fwd: postgresql-6.5.3. RPMs (Well Done!)]
In-Reply-To: <3847F042.5ABEB7A@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.05.9912031137460.21316-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 3 Dec 1999, Thomas Lockhart wrote:

Oh, and the 6.5.3-2 RPMs are ready whenever you want to upload them to
ftp.postgresql.org. They're in the usual place on ramifordistat.net.

Ah, I should have mentioned: I found a missing file in the 6.5.3-1
RPMs I was repackaging (and using!) for Mandrake. libpq++.H isn't
copied to /usr/include/pgsql/ due to the bizarre cap H in the file
name.

Vince, is there any real reason to keep this "cap H" convention? It is
the only file in the whole distro which has this, and it causes
problems for packagers and perhaps for Makefiles and emacs-like
editors.

It's only there 'cuze it was when I started. Actually it wasn't
even up to date at the time. Personally I don't care for the cap H
and have no objection to it getting renamed to libpq++.h

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

From bouncefilter Fri Dec 3 11:45:14 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 LAA78264
for <hackers@postgresql.org>; Fri, 3 Dec 1999 11:44:29 -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 LAA09733;
Fri, 3 Dec 1999 11:43:57 -0500
Message-ID: <3847F349.7301524E@wgcr.org>
Date: Fri, 03 Dec 1999 11:43: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: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Vince Vielhaber <vev@michvhf.com>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [Fwd: postgresql-6.5.3. RPMs (Well Done!)]
References: <3846E209.533B8AD4@wgcr.org>
<3847DB40.4BD58DD6@alumni.caltech.edu>
<3847DDA0.75D4EAFE@wgcr.org> <3847F042.5ABEB7A@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

Oh, and the 6.5.3-2 RPMs are ready whenever you want to upload them to
ftp.postgresql.org. They're in the usual place on ramifordistat.net.

Ah, I should have mentioned: I found a missing file in the 6.5.3-1
RPMs I was repackaging (and using!) for Mandrake. libpq++.H isn't
copied to /usr/include/pgsql/ due to the bizarre cap H in the file
name.

Ewww.. I'll rebuild this weekend. Time for a -3. Is there anything
else I might have missed??

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

From bouncefilter Fri Dec 3 11:53:14 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 LAA80312
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 11:52:15 -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 LAA09752;
Fri, 3 Dec 1999 11:52:03 -0500
Message-ID: <3847F52F.51258299@wgcr.org>
Date: Fri, 03 Dec 1999 11:51:59 -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: Ed Loehr <ELOEHR@austin.rr.com>
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster.pid
References: <19991203152844N.t-ishii@sra.co.jp>
<3847F068.6B8EC770@austin.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed Loehr wrote:

Tatsuo Ishii wrote:

Another file "postmaster.opts" is also created under $PGDATA. It
contains the path to postmaster and each option for postmaster per
line. Example contents are shown below:

[snip]

Note that even options execpt -S is not explicitly supplied in the
case above (postmaster -S), other opts are shown. This file is not
only convenient to restart postmaster but also is usefull to determin
with what defaults postmaster is running, IMHO.

It's not quite clear to me: Do command line options override
postmaster.opts options? (I would expect them to.)

From what I gather from Tatsuo's message, the 'postmaster.opts' file

only shows the status of the currently running postmaster -- IOW, it's
not a configuration file, but a status indicator.

And I like the idea of this status information being available in this
way.

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

From bouncefilter Fri Dec 3 11:52:14 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA80208
for <hackers@postgresql.org>; Fri, 3 Dec 1999 11:51:54 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA13508;
Fri, 3 Dec 1999 16:54:21 GMT
Sender: lockhart@hub.org
Message-ID: <3847F5BD.EF522D7E@alumni.caltech.edu>
Date: Fri, 03 Dec 1999 16:54:21 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>,
Postgres Hackers List <hackers@postgresql.org>
Subject: emacs question
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sorry for the (slightly) off-topic question, but it *does* relate to
being able to use emacs for editing Postgres source files:

I'm trying to use emacs for more editing than I have previously (which
was restricted to Makefiles, lisp, and sgml). And I've got at least
two projects which have differing formatting requirements which also
differ from the emacs defaults.

I'm running into trouble trying to get the tab vs space stuff right.
For Postgres, I want to set the tabbing to 4 columns, and to preserve
tabs in the input and output. I think I can do that, with

(setq tab-width 4)
(setq standard-indent 4)

though I'm not sure that standard-indent needs to be adjusted at all.

For my other project, I need 2-column indents always space filled, so
no tabs allowed. It happens to be C++, so I can differentiate between
the C code for Postgres.

Anyway, the first complication was working through the fact that emacs
(20.4, if it matters) claims to have loaded "cc-mode" on startup, when
in fact the major mode is actually called "c++-mode" internally. So I
had a devil of a time setting the hooks.

But I'm also having trouble getting things to space-fill when
indenting. I've tried

(setq c++-mode-hook 'rtc-cc-mode)

(defun rtc-cc-mode ()
(setq tab-width 2)
(setq standard-indent 2)
(setq indent-tab-mode nil))

which gave me two-column tabs, but I had hoped that nil-ing
indent-tab-mode would space fill. untabify gets rid of the tabs in a
selected region, but the tabs come back if I hit the tab key. I've
tried nil-ing the other values and setting them to zero, but that
seems to revert the behavior to 8 column tabs.

My emacs book got me this far, but the behavior seems to be a bit at
odds with their description and they don't give a specific example
covering this. Any hints would be *greatly* appreciated.

TIA

- Thomas

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

From bouncefilter Fri Dec 3 11:54:14 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA80692
for <hackers@postgresql.org>; Fri, 3 Dec 1999 11:54:00 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA13522;
Fri, 3 Dec 1999 16:56:19 GMT
Sender: lockhart@hub.org
Message-ID: <3847F633.B981900B@alumni.caltech.edu>
Date: Fri, 03 Dec 1999 16:56:19 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Vince Vielhaber <vev@michvhf.com>
CC: Lamar Owen <lamar.owen@wgcr.org>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [Fwd: postgresql-6.5.3. RPMs (Well Done!)]
References: <Pine.BSF.4.05.9912031137460.21316-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It's only there 'cuze it was when I started. Actually it wasn't
even up to date at the time. Personally I don't care for the cap H
and have no objection to it getting renamed to libpq++.h

OK, I'll kill it for 7.0.

- Thomas

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

From bouncefilter Fri Dec 3 12:05:17 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA84764
for <hackers@postgresql.org>; Fri, 3 Dec 1999 12:05:07 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id RAA13585;
Fri, 3 Dec 1999 17:07:21 GMT
Sender: lockhart@hub.org
Message-ID: <3847F8C9.4AA71206@alumni.caltech.edu>
Date: Fri, 03 Dec 1999 17:07:21 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Lamar Owen <lamar.owen@wgcr.org>
CC: Vince Vielhaber <vev@michvhf.com>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [Fwd: postgresql-6.5.3. RPMs (Well Done!)]
References: <3846E209.533B8AD4@wgcr.org>
<3847DB40.4BD58DD6@alumni.caltech.edu>
<3847DDA0.75D4EAFE@wgcr.org> <3847F042.5ABEB7A@alumni.caltech.edu>
<3847F349.7301524E@wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ewww.. I'll rebuild this weekend. Time for a -3. Is there anything
else I might have missed??

No, I just added "*.H" to the "for f in *.h access ..." line. I may
not have actually tested to see if that works :/

Also, I switched from mkdir -p to using

install -d -m 0700 $RPM_BUILD_ROOT/var/lib/pgsql

and

%attr(700,postgres,postgres) %dir /var/lib/pgsql

Nothing else changed (I'm looking at 6.5.3-1 spec files).

- Thomas

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

From bouncefilter Fri Dec 3 12:17:17 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 MAA02247
for <hackers@postgresql.org>; Fri, 3 Dec 1999 12:16:19 -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 MAA09822;
Fri, 3 Dec 1999 12:16:12 -0500
Message-ID: <3847FAD6.F6805559@wgcr.org>
Date: Fri, 03 Dec 1999 12:16: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: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Vince Vielhaber <vev@michvhf.com>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [Fwd: postgresql-6.5.3. RPMs (Well Done!)]
References: <3846E209.533B8AD4@wgcr.org>
<3847DB40.4BD58DD6@alumni.caltech.edu>
<3847DDA0.75D4EAFE@wgcr.org> <3847F042.5ABEB7A@alumni.caltech.edu>
<3847F349.7301524E@wgcr.org> <3847F8C9.4AA71206@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

Ewww.. I'll rebuild this weekend. Time for a -3. Is there anything
else I might have missed??

No, I just added "*.H" to the "for f in *.h access ..." line. I may
not have actually tested to see if that works :/

Also, I switched from mkdir -p to using

install -d -m 0700 $RPM_BUILD_ROOT/var/lib/pgsql

and

%attr(700,postgres,postgres) %dir /var/lib/pgsql

Ok, those last two changes are already in 6.5.3-2. The first one will
go in 6.5.3-3, along with anything else I find.

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

From bouncefilter Fri Dec 3 12:34:18 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA06762
for <pgsql-hackers@hub.org>; Fri, 3 Dec 1999 12:33:46 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA04230;
Fri, 3 Dec 1999 12:32:40 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912031732.MAA04230@candle.pha.pa.us>
Subject: Re: [HACKERS] Brain-Dead Sort Algorithm??
In-Reply-To: <3847EF05.9A74386@alumni.caltech.edu> from Thomas Lockhart at
"Dec
3, 1999 04:25:41 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Fri, 3 Dec 1999 12:32:40 -0500 (EST)
CC: Tim Perdue <tim@perdue.net>, pgsql-hackers@hub.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Sigh. Y'all like the sweeping statement, which got you in a bit of
trouble the first time too :)

Without knowing your schema, I can't say why you have *exactly* the
storage requirement you see. But, you have chosen the absolute worst
case for *any* relational database: a schema with only a single, very
small column.

For Postgres (and other DBs, but the details will vary) there is a 36
byte overhead per row to manage the tuple and the transaction
behavior. So if you stored your data as int8 (int4 is too small for 10
digits, right?) I see an average usage of slightly over 44 bytes per
row (36+8). So, for 6.8 million rows, you will require 300MB. I'm
guessing that you are using char(10) fields, which gives 50 bytes/row
or a total of 340MB, which matches your number to two digits.

Note that the tuple header size will stay the same (with possibly some
modest occasional bumps) for rows with more columns, so the overhead
decreases as you increase the number of columns in your tables.

By the way, I was going to say to RTFM, but I see a big blank spot on
this topic (I could have sworn that some of the info posted to the
mailing lists on this topic had made it into the manual, but maybe
not).

This is an FAQ item.

-- 
  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 Dec 3 12:36:31 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA07398
for <hackers@postgresql.org>; Fri, 3 Dec 1999 12:35:52 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA04415;
Fri, 3 Dec 1999 12:35:28 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912031735.MAA04415@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [Fwd: postgresql-6.5.3. RPMs (Well Done!)]
In-Reply-To: <Pine.BSF.4.05.9912031137460.21316-100000@paprika.michvhf.com>
from Vince Vielhaber at "Dec 3, 1999 11:39:53 am"
To: Vince Vielhaber <vev@michvhf.com>
Date: Fri, 3 Dec 1999 12:35:28 -0500 (EST)
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Lamar Owen <lamar.owen@wgcr.org>,
Postgres Hackers List <hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 3 Dec 1999, Thomas Lockhart wrote:

Oh, and the 6.5.3-2 RPMs are ready whenever you want to upload them to
ftp.postgresql.org. They're in the usual place on ramifordistat.net.

Ah, I should have mentioned: I found a missing file in the 6.5.3-1
RPMs I was repackaging (and using!) for Mandrake. libpq++.H isn't
copied to /usr/include/pgsql/ due to the bizarre cap H in the file
name.

Vince, is there any real reason to keep this "cap H" convention? It is
the only file in the whole distro which has this, and it causes
problems for packagers and perhaps for Makefiles and emacs-like
editors.

It's only there 'cuze it was when I started. Actually it wasn't
even up to date at the time. Personally I don't care for the cap H
and have no objection to it getting renamed to libpq++.h

Your wish is my command. Done.

-- 
  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 Dec 3 12:47:23 1999
Received: from www2.hapenney.com ([207.22.245.171])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA10522
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 12:46:21 -0500 (EST)
(envelope-from evan@4-am.com)
Received: from 4-am.com (isdn02-26.texasinternet.com [216.178.132.153])
by www2.hapenney.com (8.9.3/8.8.7) with ESMTP id LAA30885;
Fri, 3 Dec 1999 11:46:01 -0600
Sender: evan@www2.hapenney.com
Message-ID: <384801D3.8FB691E6@4-am.com>
Date: Fri, 03 Dec 1999 11:45:55 -0600
From: Evan Simpson <evan@4-am.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster.pid
References: <19991203152844N.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tatsuo Ishii wrote:

I have committed changes to postmaster.c. Now it creates a file called
"postmaster.pid" under $PGDATA, which holds postmaster's process
id. If the file has already existed, postmaster won't start.

Do you just test to see if the file exists? If so, I would suggest
actually reading the pid and checking to see if the process is still
running. That way we don't have to 'rm postmaster.pid' if the postmaster
dies abnormally (Netscape for Linux has this problem).

Cheers,

Evan @ 4-am

From bouncefilter Fri Dec 3 12:52:18 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 MAA12648
for <hackers@postgresql.org>; Fri, 3 Dec 1999 12:51:54 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 21832 invoked by uid 1001); 3 Dec 1999 17:51:56 -0000
Date: Fri, 3 Dec 1999 12:51:56 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Lamar Owen <lamar.owen@wgcr.org>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [Fwd: postgresql-6.5.3. RPMs (Well Done!)]
In-Reply-To: <199912031735.MAA04415@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.05.9912031251320.21316-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 3 Dec 1999, Bruce Momjian wrote:

On Fri, 3 Dec 1999, Thomas Lockhart wrote:

Oh, and the 6.5.3-2 RPMs are ready whenever you want to upload them to
ftp.postgresql.org. They're in the usual place on ramifordistat.net.

Ah, I should have mentioned: I found a missing file in the 6.5.3-1
RPMs I was repackaging (and using!) for Mandrake. libpq++.H isn't
copied to /usr/include/pgsql/ due to the bizarre cap H in the file
name.

Vince, is there any real reason to keep this "cap H" convention? It is
the only file in the whole distro which has this, and it causes
problems for packagers and perhaps for Makefiles and emacs-like
editors.

It's only there 'cuze it was when I started. Actually it wasn't
even up to date at the time. Personally I don't care for the cap H
and have no objection to it getting renamed to libpq++.h

Your wish is my command. Done.

Thankyou!

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

From bouncefilter Fri Dec 3 13:05:26 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA16191
for <hackers@postgresql.org>; Fri, 3 Dec 1999 13:05:08 -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 NAA02132;
Fri, 3 Dec 1999 13:04:03 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: emacs question
In-reply-to: Your message of Fri, 03 Dec 1999 16:54:21 +0000
<3847F5BD.EF522D7E@alumni.caltech.edu>
Date: Fri, 03 Dec 1999 13:04:03 -0500
Message-ID: <2130.944244243@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

I'm running into trouble trying to get the tab vs space stuff right.
For Postgres, I want to set the tabbing to 4 columns, and to preserve
tabs in the input and output. I think I can do that, with
(setq tab-width 4)
(setq standard-indent 4)
though I'm not sure that standard-indent needs to be adjusted at all.

For my other project, I need 2-column indents always space filled, so
no tabs allowed. It happens to be C++, so I can differentiate between
the C code for Postgres.

I am not sure whether you have the correct mental model for this, so
here it is: there are two different things going on here, the "physical"
width of tab stops and the "logical" notion of syntax-driven
indentation. A TAB character stored in a file is displayed as "indent
to the next tab stop", where tab stops are every tab-width columns, 8 by
default. (I think you can also choose to set up a user-defined list of
tab stop locations, but I've never done that.) The tab stops have
*nothing* to do with logical indentation of source code --- that's
driven by separate logic that says "indent this many columns relative to
the previous line when you see this kind of syntactic context". After
the logical-indent code has decided what column it thinks the line
should start at, it then constructs a whitespace prefix of the right
length, which normally will use the right number of tabs and spaces
based on the current "physical" tab stop settings. When you press TAB
in c++-mode, that doesn't mean "insert one tab character", it means
"reindent the current line by recomputing the appropriate leading
whitespace". It could insert or delete any combination of tabs and
spaces. (If you really want to insert one tab character, you use the
usual escape for inserting control codes: control-Q TAB.)

(If you already had your head screwed on straight, sorry for the
digression.)

But I'm also having trouble getting things to space-fill when
indenting. I've tried

(setq c++-mode-hook 'rtc-cc-mode)

(defun rtc-cc-mode ()
(setq tab-width 2)
(setq standard-indent 2)
(setq indent-tab-mode nil))

I doubt that you want to be messing with the default tab-stop-distance
setting here. And you shouldn't need to mess with standard-indent
either; I have no idea what that controls, but it's not the basis for
indenting in C or C++ mode AFAIK. The logical indent per syntactic
level in these modes is set by c-basic-offset, which may already be 2
depending on which c-style value you are using. Finally, as far as
suppressing use of tabs to do logical indentation, you've almost got it
right, but the variable is named "indent-tabs-mode".

Also, if you want to have different conventions for different projects,
setting a c++-mode-hook is probably not the way to go; that will get run
*any* time you visit a c++ file. I'd suggest a trick that someone
(Peter E. I think) recently pointed out to me: you can pattern-match on
the location of a source file in an auto-mode-alist pattern. So I've
now got this in my .emacs:

; Cmd to set tab stops &etc for working with PostgreSQL code
(defun pgsql-c-mode ()
"Set PostgreSQL C indenting conventions in current buffer."
(interactive)
(c-mode) ; select major mode to customize
(setq tab-width 4) ; some people have weird ideas about tabs
(c-set-style "bsd") ; sets c-basic-offset to 4, plus other stuff
(c-set-offset 'case-label '+) ; tweak case indent to match PG custom
)

; Invoke pgsql-c-mode automatically when loading appropriate files
(setq auto-mode-alist
(cons '("\\`/users/postgres/.*\\.[ch]\\'" . pgsql-c-mode)
(cons '("\\`/users/tgl/pgsql/.*\\.[ch]\\'" . pgsql-c-mode)
auto-mode-alist)))

which means that I get Postgres-customized C mode whenever I visit a
.c or .h file under /users/postgres/ or /users/tgl/pgsql/ (customize
paths to taste of course).

You can use the above defun as-is for Postgres code, and for your other
project you probably want a mode-set command like

(defun foobar-cc-mode ()
"Set so-and-so's C++ indenting conventions in current buffer."
(interactive)
(c++-mode) ; select major mode to customize
(setq c-basic-offset 2)
(setq indent-tabs-mode nil))

(You might also want to call c-set-style if the other project doesn't
use GNU-flavor brace layout and so forth --- and you can get really down
and dirty if you need to, by tweaking offsets for individual syntax
elements. But that's a last resort if you have to adhere to an
unconventional set of layout guidelines. c-set-style can get you pretty
close to all the popular formats I've heard of.)

This is already OK to invoke by hand, and then you can add some
auto-mode-alist entries to invoke it automatically when you visit
files with the right path prefix and suffix.

My emacs book got me this far, but the behavior seems to be a bit at
odds with their description and they don't give a specific example
covering this. Any hints would be *greatly* appreciated.

The online manual (see control-H I) is generally more up-to-date about
how your particular version works than any book is likely to be. I'm
using version 19, so I might be a little off about how version 20 works,
but I hadn't heard that they reworked the indent logic in any major way.

It'd be well worth your while to read the manual's section about
"Indentation for Programs"... but in my copy, the last part about
customizing indent tells you about "styles" last, where it probably
should tell you that first instead of presenting the low-level
adjustments first...

Good luck!

regards, tom lane

From bouncefilter Fri Dec 3 13:32:19 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 NAA58970
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 13:31:38 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 21926 invoked by uid 1001); 3 Dec 1999 18:31:41 -0000
Date: Fri, 3 Dec 1999 13:31:41 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Olivier PRENANT <ohp@pyrenet.fr>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postgresql authentification for popper
In-Reply-To: <3847BDDC.6999B7D9@pyrenet.fr>
Message-ID: <Pine.BSF.4.05.9912031328400.21316-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 3 Dec 1999, Olivier PRENANT wrote:

Hi everyone,

I working on a project that will handle around 50000 mailboxes at least.

I have no problem with the system or sendmail. But I'm afraid that
popper (either pop3 or imap) won't be able to authentificate users the
standard way (/etc/passwd) does anyone knows if a version of imapd or
ipop3d has been modified to allow postgresql authentification.

If not, could you give me some pointers.

Earlier in the week I submitted patches to the qpopper folks for a very
similar purpose - although I didn't add any database stuff to it. It
reads a flat file of username:passwd:UID:GID:$HOME:shell and the UID/GID
can be the same. Since the routine that reads the alternate password
file (BTW, it reads /etc/passwd first then the alt file) is a standalone
it'd be trivial to modify to read from a PostgreSQL table.

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

From bouncefilter Fri Dec 3 13:38:19 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA59930
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 13:37:47 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id OAA21296;
Fri, 3 Dec 1999 14:37:36 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 3 Dec 1999 14:37:35 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Olivier PRENANT <ohp@pyrenet.fr>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postgresql authentification for popper
In-Reply-To: <3847BDDC.6999B7D9@pyrenet.fr>
Message-ID: <Pine.BSF.4.21.9912031434360.18029-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

If you use Cyrus IMAPd (I use it on all my servers), you can use a PAM
module for authenticating...one server I'm just getting ready to put
online does /etc/passwd first, falls over to radiusd second and then
NT/smb third (need to cover alot of bases)...

Cyrus is also designed so that you don't need to have any users in your
/etc/passwd file...it was basically designed to be an ultra-secure, yet
feature-rich, mail server...

The newest version implements Sieve, for mail filter, which one of the
guyson the mailing list did up a great filter front-end too, so that you
can setup vacation/filters, again, without ever needing to have a user in
your /etc/passwd file ...

On Fri, 3 Dec 1999, Olivier PRENANT wrote:

Hi everyone,

I working on a project that will handle around 50000 mailboxes at least.

I have no problem with the system or sendmail. But I'm afraid that
popper (either pop3 or imap) won't be able to authentificate users the
standard way (/etc/passwd) does anyone knows if a version of imapd or
ipop3d has been modified to allow postgresql authentification.

If not, could you give me some pointers.

Regards to you all
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

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

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

why

create table mymy (mydate datetime default (now() + '60 days'::timespan ));

does not work?

On Fri, 3 Dec 1999, Thomas Lockhart wrote:

Show quoted text

I'd like to create a table with a datetime field that defaults to +60
days.
mydate datetime default 'now() +@60 days',
...

Where is a problem?

You have enclosed your default values into a large string, rather than
letting them be evaluated as an expression:

mydate datetime default (now() + '60 days')

where the outer parens are optional.

datetime + '10 day' or
datetime + '2 year' ..etc.
But I'm not sure what is better or exists it in other SQL.

afaik this is the simplest and most direct way to do it. Note that you
can include other timespan fields in the constant:

mydate datetime default (now() + '60 days 10 hours')

HTH

- Thomas

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

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

Remove the ::timespan and it will.

Andy

On Fri, 3 Dec 1999 kaiq@realtyideas.com wrote:

why

create table mymy (mydate datetime default (now() + '60 days'::timespan ));

does not work?

On Fri, 3 Dec 1999, Thomas Lockhart wrote:

I'd like to create a table with a datetime field that defaults to +60
days.
mydate datetime default 'now() +@60 days',
...

Where is a problem?

You have enclosed your default values into a large string, rather than
letting them be evaluated as an expression:

mydate datetime default (now() + '60 days')

where the outer parens are optional.

datetime + '10 day' or
datetime + '2 year' ..etc.
But I'm not sure what is better or exists it in other SQL.

afaik this is the simplest and most direct way to do it. Note that you
can include other timespan fields in the constant:

mydate datetime default (now() + '60 days 10 hours')

HTH

- Thomas

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

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

From bouncefilter Fri Dec 3 16:02:20 1999
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA96885
for <hackers@postgresql.org>; Fri, 3 Dec 1999 16:01:27 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id TAA13872;
Fri, 3 Dec 1999 19:57:15 GMT
Sender: lockhart@hub.org
Message-ID: <3848209B.A543B73A@alumni.caltech.edu>
Date: Fri, 03 Dec 1999 19:57:15 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Aldridge <RALDRIDG@gulf-states.com>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: Geometric Data Type in PostgreSQL
References: <s847aabb.068@gulf-states.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm a geographic information systems (GIS) professional and a (home)
Linux user. After reading the documentation for the Geometric data
types in PostgreSQL, I'm excited about the possibilities. Are you
aware of any projects where the geometric data types in PostgreSQL are
being used as the basis of a GIS or mapping package?

Not specifically, though I do know that folks have used it to do
GIS-like things (e.g. given a location on the earth surface, identify
satellite tracks which are visible).

The best place to ask is on the Postgres mailing list(s); I'm cc'ing
the hackers list and you may want to inquire on one or two of the
other lists too.

I'd like to know
if anyone's doing this and, if not, what development language would
you recommend for developing a mapping package using PostgreSQL.

Hmm. That's a hard one to answer without knowing more. If you need
compiled code, then C or C++ might be the best choice. But you might
find something like java or itcl lets you build a GUI app faster and
easier.

An interesting possibility if you are developing in C or C++ is to
consider developing as a "gnome-enabled" app, which presumably gives
you a bunch of high level widgets to work with. It would also allow
you to Corba-ize your app to decouple the backend from the GUI.

Also, how difficult would it be to add a Z value to the X and Y
values to the data types' basic structure? This would allow the
storage of height data along with the coordinates.

It would be easy; you just need to figure out how you will be able to
use it. Things like comparison operators have a less intuitive meaning
once you go to 3D.

Look at src/backend/utils/adt/geo.c for hints on how to deal with a
geometric data type. Also, look at contrib/ to see how to add a
datatype.

I use GRASS on my Linux system at home. GRASS is a (GPL'd) raster GIS
package. Open source vector GIS packages for Linux are, as far as I
know, nonexistent. Several commercial packages are available,
including ESRI's Arc/Info and ArcView (which I use at work). I'd like
to see an open source vector GIS package developed, perhaps based on
PostgreSQL's geometric data types.

You might also consider using something like ApplixWare, which has
hooks into Postgres (via ODBC) and might have enough features and
power to allow developing a package. The per-seat cost of ApplixWare
is pretty low. It may be ODBC gets in the way of exposing the extended
features of Postgres though.

Good luck.

- Thomas

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

why
create table mymy (mydate datetime
default (now() + '60 days'::timespan ));
does not work?

Uh, I think it does, right?

- Thomas

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

I feel pain about it :-) because that was what I tried, and then,
since it did not work, I assumed "default" did not accept expressions.

No pain here:

postgres=> create table mymy (mydate datetime
postgres-> default (now() + '60 days'::timespan ));
CREATE

What version are you running??

- Thomas

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

From bouncefilter Fri Dec 3 16:02:20 1999
Received: from localhost (IDENT:root@hectic-1.jpl.nasa.gov [128.149.68.203])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA96881
for <hackers@postgresql.org>; Fri, 3 Dec 1999 16:01:21 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id UAA13945;
Fri, 3 Dec 1999 20:15:11 GMT
Sender: lockhart@hub.org
Message-ID: <384824CE.BDF931F2@alumni.caltech.edu>
Date: Fri, 03 Dec 1999 20:15:10 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: emacs question
References: <2130.944244243@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

<snip helpful intro which I'd like to think I already knew, at least
mostly ;) >

(setq indent-tab-mode nil))

... Finally, as far as
suppressing use of tabs to do logical indentation, you've almost got
it right, but the variable is named "indent-tabs-mode".

sheesh, that's it! I was going around in lots of tiny little
circles... :(

Also, if you want to have different conventions for different
projects, setting a c++-mode-hook is probably not the way to go; that
will get run *any* time you visit a c++ file. I'd suggest a trick
that someone (Peter E. I think) recently pointed out to me: you can
pattern-match on the location of a source file in an auto-mode-alist
pattern. So I've now got this in my .emacs:

Great. I had just been thinking about this, and now I don't have to
figure it out :))

Thanks.

- Thomas

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

I know, thanks to you, but why? It supposes to work. seems things within
default's parenthesis are different for no reason.

I mean,
insert into mymy values( now() + '60 days'::timespan );
works fine. usually the more strict one (diligitantly casted one)
always works.

I feel pain about it :-) because that was what I tried, and then, since it
did not work, I assumed "default" did not accept expressions.

On Fri, 3 Dec 1999, Andy Lewis wrote:

Show quoted text

Remove the ::timespan and it will.

Andy

On Fri, 3 Dec 1999 kaiq@realtyideas.com wrote:

why

create table mymy (mydate datetime default (now() + '60 days'::timespan ));

does not work?

On Fri, 3 Dec 1999, Thomas Lockhart wrote:

I'd like to create a table with a datetime field that defaults to +60
days.
mydate datetime default 'now() +@60 days',
...

Where is a problem?

You have enclosed your default values into a large string, rather than
letting them be evaluated as an expression:

mydate datetime default (now() + '60 days')

where the outer parens are optional.

datetime + '10 day' or
datetime + '2 year' ..etc.
But I'm not sure what is better or exists it in other SQL.

afaik this is the simplest and most direct way to do it. Note that you
can include other timespan fields in the constant:

mydate datetime default (now() + '60 days 10 hours')

HTH

- Thomas

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

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

6.5.1. time to upgrade ;-) thanks.

On Fri, 3 Dec 1999, Thomas Lockhart wrote:

I feel pain about it :-) because that was what I tried, and then,
since it did not work, I assumed "default" did not accept expressions.

No pain here:

postgres=> create table mymy (mydate datetime
postgres-> default (now() + '60 days'::timespan ));
CREATE

What version are you running??

- Thomas

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

From bouncefilter Fri Dec 3 16:59:20 1999
Received: from propertykey.com (IDENT:root@propertykey.com [206.196.37.193])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA05297
for <hackers@postgreSQL.org>; Fri, 3 Dec 1999 16:58:57 -0500 (EST)
(envelope-from jeff@propertykey.com)
Received: from propertykey.com (gotojail.propertykey.com [206.196.37.197])
by propertykey.com (8.9.3/8.9.3) with ESMTP id PAA00540;
Fri, 3 Dec 1999 15:57:39 -0600
Message-ID: <38483CD3.384263E5@propertykey.com>
Date: Fri, 03 Dec 1999 15:57:39 -0600
From: Jeff Hoffmann <jeff@propertykey.com>
Organization: PropertyKey.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: Robert Aldridge <RALDRIDG@gulf-states.com>,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Geometric Data Type in PostgreSQL
References: <s847aabb.068@gulf-states.com>
<3848209B.A543B73A@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

I'm a geographic information systems (GIS) professional and a (home)
Linux user. After reading the documentation for the Geometric data
types in PostgreSQL, I'm excited about the possibilities. Are you
aware of any projects where the geometric data types in PostgreSQL are
being used as the basis of a GIS or mapping package?

I use it in applications for geographic purposes, not really as a basis
of standalone, general purpose GIS systems. Mostly what I use it for
is finding objects in a specific bounding box.

I'd like to know
if anyone's doing this and, if not, what development language would
you recommend for developing a mapping package using PostgreSQL.

Hmm. That's a hard one to answer without knowing more. If you need
compiled code, then C or C++ might be the best choice. But you might
find something like java or itcl lets you build a GUI app faster and
easier.

Java would be a no go. For most purposes, it's fine, but iterating
through hundreds/thousands of records that can be required on a map make
it painfully slow at best. I wrote a prototype for a web based
map/database system using java with the JDBC driver at the time & I
ended up rewriting the map part in C and calling that from java. (I
also did a similar thing as a PHP extension - a C library called from
PHP scripts, which is how its running now.)

I use GRASS on my Linux system at home. GRASS is a (GPL'd) raster GIS
package. Open source vector GIS packages for Linux are, as far as I
know, nonexistent. Several commercial packages are available,
including ESRI's Arc/Info and ArcView (which I use at work). I'd like
to see an open source vector GIS package developed, perhaps based on
PostgreSQL's geometric data types.

Have you looked at what people are doing with Postgres & GRASS? I've
seen something on the GRASS web site about the project, but I don't know
how serious people were about working on it or what they expected to do
with it. If you haven't seen it around, poke around a little deeper -
it wasn't hidden that far.

<kaiq@realtyideas.com> writes:

why
create table mymy (mydate datetime default (now() + '60 days'::timespan ));
does not work?

I believe :: casts are broken in default expressions in 6.5.*. They are
fixed in current sources (which is what Thomas probably tried) --- but
in the meantime, that expression will work fine without the cast...

regards, tom lane

From bouncefilter Fri Dec 3 18:36:21 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 SAA18060
for <hackers@postgreSQL.org>; Fri, 3 Dec 1999 18:35: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 SAA03356;
Fri, 3 Dec 1999 18:33:04 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Vadim Mikheev" <vadim@krs.ru>,
"PostgreSQL Developers List" <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
In-reply-to: Your message of Sat, 4 Dec 1999 00:24:28 +0900
<NABBINCKAKFCDDKMMJHGMEJFDMAA.Inoue@tpf.co.jp>
Date: Fri, 03 Dec 1999 18:33:04 -0500
Message-ID: <3354.944263984@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

OK case by case. I will be glad to check them one by one.

I'm checking them for AccessExclusiveLock now.

As for RowExclusiveLock,it would be much effective to remove
the release of lock unconditionally.
RowExclusiveLock isn't so intensive a lock. For example it
doesn't conflict relatively. Therefore it would be hard to find
and resolve the bugs which are caused by the early release
of RowExclusiveLock,deadlock etc ...
Holding the lock a little longer won't be so harmful inversely.

We could try it and see, certainly. You are probably right that it
would not be harmful to hold it.

As for AccessExclusiveLock I found followings now.

3) commands/dbcommands.c(DROP DATABASE)
elog(ERROR) follows immediately. The release should
be removed.

5) commands/vacuum.c(VACUUM)
The release is caused by new security check. Probably
the check could be done before acquiring AccessExcl-
usiveLock.

In both of these cases, we are closing the system table unmodified,
and AFAICT the point is just to release the lock a tad sooner than
we otherwise would. (I coded the VACUUM code just like code I'd seen
elsewhere.) It's probably harmless either way.

6) commands/commands.c(ALTER TABLE)
ALTER TABLE doesn't release AccessExclusiveLock till
end of transaction. I couldn't find any reason to allow
the release for inheritors of a relation class. The release
should be removed.

Yes, the recursive subroutine will grab the same lock and not release
it. I'm not sure why it's coded the way it is, but certainly there's
no benefit to releasing the lock earlier at the outer level.

7) commands/async.c(LISTEN/UNLISTEN)
This case seems dangerous too but unfortunately I couldn't
point out a concrete flaw now.

Holding the lock on pg_listener longer than absolutely necessary strikes
me as very risky, since any other backend might need to grab the lock
before it can complete its own transaction (in order to send or receive
notifies). Deadlock could ensue depending on what other locks are held.

I think the locking logic for pg_listener was last revised for 6.4 (by me).
It seems to work fine as-is, but it doesn't know anything about MVCC.
It is possible that we could downgrade the locks to RowExclusiveLock and
rely on MVCC semantics instead of a hard lock. This would require
careful study however, in particular to be sure that cross-backend
notifies couldn't be missed because of not-yet-committed tuples.
I haven't had time to think about it...

regards, tom lane

From bouncefilter Fri Dec 3 20:49:23 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA34183
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 20:48:32 -0500 (EST)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id UAA13906;
Fri, 3 Dec 1999 20:48:23 -0500 (EST)
Message-ID: <38487294.9782E711@southeast.net>
Date: Fri, 03 Dec 1999 20:47:00 -0500
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster.pid
References: <19991203152844N.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I hope you don't mind being superseded. I hope (FINALLY!) to be able to post
the patches for the log subsystem in the next week or three. The log system
has a fairly sophisticated set of options which required a config file of
its own. Rather than have two options file, I absorbed pg_options and made
a general options file: "postgres.conf".

Could you accept this:

/* postgres.conf */
environment {
port 5432;
pidfile "/usr/local/pgsql/data";
/* etc. */
}

debugging {
/* pg_options info */
}

logging {
/* logging info */
}

For more info, see http://216.199.14.27/

regards,

Tim Holloway

The logger supports reporting the run environment, BTW. I find
that way I don't pick up the wrong config file and only "think" I
know what options are in effect (it also reports where it GOT
the config file).

Tatsuo Ishii wrote:

Hi,

I have committed changes to postmaster.c. Now it creates a file called
"postmaster.pid" under $PGDATA, which holds postmaster's process
id. If the file has already existed, postmaster won't start. So we
cannot start more than on postmaster with same $PGDATA any more. I
believe it's a good thing. The file will be deleted upon postmaster
shutting down.

Another file "postmaster.opts" is also created under $PGDATA. It
contains the path to postmaster and each option for postmaster per
line. Example contents are shown below:

/usr/local/pgsql/bin/postmaster
-p 5432
-D /usr/local/pgsql/data
-B 64
-b /usr/local/pgsql/bin/postgres
-N 32
-S

Note that even options execpt -S is not explicitly supplied in the
case above (postmaster -S), other opts are shown. This file is not
only convenient to restart postmaster but also is usefull to determin
with what defaults postmaster is running, IMHO.

With these changes now we can stop postmaster:

kill `cat /usr/local/pgsql/data/postmaster.pid`

To restart it with previous options:

eval `cat /usr/local/pgsql/data/postmaster.opts`

I'm going to write pg_ctl script this week end.

BTW, no initdb required, of course.
--
Tatsuo Ishii

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

From bouncefilter Fri Dec 3 21:38:23 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 VAA40091
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 21:37:29 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id LAA04922;
Sat, 4 Dec 1999 11:37:28 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id LAA12791;
Sat, 4 Dec 1999 11:37:27 +0900
To: mtsinc@southeast.net
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster.pid
In-Reply-To: Your message of "Fri, 03 Dec 1999 20:47:00 -0500"
<38487294.9782E711@southeast.net>
References: <38487294.9782E711@southeast.net>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991204113727X.t-ishii@sra.co.jp>
Date: Sat, 04 Dec 1999 11:37:27 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 12

I hope you don't mind being superseded. I hope (FINALLY!) to be able to post
the patches for the log subsystem in the next week or three. The log system
has a fairly sophisticated set of options which required a config file of
its own. Rather than have two options file, I absorbed pg_options and made
a general options file: "postgres.conf".

I'm not sure about your postgres.conf, but I think pg_options was made
for postgres - the backend - not for postmaster. This is the reason
why I invented yet another conf file. Anyway, could you post the
patches so that we could evaluate them?
--
Tatsuo Ishii

From bouncefilter Fri Dec 3 21:42:23 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 VAA40689
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 21:41:33 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id LAA04973;
Sat, 4 Dec 1999 11:41:32 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id LAA12799;
Sat, 4 Dec 1999 11:41:31 +0900
To: evan@4-am.com
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster.pid
In-Reply-To: Your message of "Fri, 03 Dec 1999 11:45:55 -0600"
<384801D3.8FB691E6@4-am.com>
References: <384801D3.8FB691E6@4-am.com>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991204114131G.t-ishii@sra.co.jp>
Date: Sat, 04 Dec 1999 11:41:31 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 11

Do you just test to see if the file exists? If so, I would suggest
actually reading the pid and checking to see if the process is still
running. That way we don't have to 'rm postmaster.pid' if the postmaster
dies abnormally (Netscape for Linux has this problem).

Thanks for the suggestion. I have already modified postmaster.c so
that it could remove postmaster.pid if the file is bogus. Will commit
soon.
--
Tatsuo Ishii

From bouncefilter Fri Dec 3 21:42:23 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 VAA40708
for <pgsql-hackers@postgreSQL.org>; Fri, 3 Dec 1999 21:41:49 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id LAA04981;
Sat, 4 Dec 1999 11:41:48 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-9 [133.137.84.9])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id LAA12807;
Sat, 4 Dec 1999 11:41:45 +0900
To: lamar.owen@wgcr.org
Cc: ELOEHR@austin.rr.com, t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster.pid
In-Reply-To: <3847F52F.51258299@wgcr.org>
References: <19991203152844N.t-ishii@sra.co.jp>
<3847F068.6B8EC770@austin.rr.com> <3847F52F.51258299@wgcr.org>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991204120234U.t-ishii@sra.co.jp>
Date: Sat, 04 Dec 1999 12:02:34 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 12

From what I gather from Tatsuo's message, the 'postmaster.opts' file
only shows the status of the currently running postmaster -- IOW, it's
not a configuration file, but a status indicator.

Right. Thanks for the cleaner explation!

And I like the idea of this status information being available in this
way.

Me too.
--
Tatsuo Ishii

From bouncefilter Fri Dec 3 21:42:26 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 VAA40722
for <pgsql-hackers@postgresql.org>; Fri, 3 Dec 1999 21:41:58 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id LAA04986;
Sat, 4 Dec 1999 11:41:58 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-9 [133.137.84.9])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id LAA12816;
Sat, 4 Dec 1999 11:41:55 +0900
To: ELOEHR@austin.rr.com
Cc: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postmaster.pid
In-Reply-To: <3847F068.6B8EC770@austin.rr.com>
References: <19991203152844N.t-ishii@sra.co.jp>
<3847F068.6B8EC770@austin.rr.com>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991204120244P.t-ishii@sra.co.jp>
Date: Sat, 04 Dec 1999 12:02:44 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 15

Note that even options execpt -S is not explicitly supplied in the
case above (postmaster -S), other opts are shown. This file is not
only convenient to restart postmaster but also is usefull to determin
with what defaults postmaster is running, IMHO.

It's not quite clear to me: Do command line options override
postmaster.opts options? (I would expect them to.)

No, postmaster.opts is just showing what options have been passed to
postmatser. Using it to determine what options should be given next
time is the job of pg_ctl which I'm writing now, not
postmaster's. Speaking about pg_ctl, probably I will give it the
ability to override postmaster.opts options.
--
Tatsuo Ishii

From bouncefilter Sat Dec 4 09:10:32 1999
Received: from tux.w3.org (IDENT:veillard@tux.w3.org [18.29.0.27])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA16376
for <pgsql-hackers@postgreSQL.org>; Sat, 4 Dec 1999 09:09:58 -0500 (EST)
(envelope-from veillard@tux.w3.org)
Received: (from veillard@localhost) by tux.w3.org (8.9.3/8.9.3) id JAA03469;
Sat, 4 Dec 1999 09:09:54 -0500
Date: Sat, 4 Dec 1999 09:09:54 -0500
From: Daniel Veillard <Daniel.Veillard@w3.org>
To: Lamar Owen <lamar.owen@wgcr.org>
Cc: Joe Brenner <doom@kzsu.stanford.edu>, pgsql-hackers@postgreSQL.org,
Ian Macdonald <ian@caliban.org>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Vince Vielhaber <vev@michvhf.com>, ianmacd@xs4all.nl,
Daniel.Veillard@w3.org
Subject: Re: [HACKERS] perl-DBD-Pg (was Re: BOUNCE pgsql-ports@postgreSQL.org:
Non-member submission from[Joe Brenner
<doom@kzsu.stanford.edu>] (fwd))
Message-ID: <19991204090954.C32494@w3.org>
Reply-To: Daniel.Veillard@w3.org
References: <199912021141.DAA28586@kzsu.stanford.edu>
<38469062.F85D1726@wgcr.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.7i
In-Reply-To: <38469062.F85D1726@wgcr.org>
Organization: World Wide Web Consortium (W3C http://www.w3.org/)

On Thu, Dec 02, 1999 at 10:29:38AM -0500, Lamar Owen wrote:

Joe Brenner wrote:

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

Thank you Ian for the clarification. HOWEVER, this does not show up on
the rpmfind.net web toold under powertools -- yet is there under the
rufus.w3.org mirror (they're the same machine, of course).

Yes, from one point of view, I guess that's the root of the
problem I was having. All the ways I could think of
searching for an RPM (rpmfind, google, etc.) turned up
nothing later that the 0.91-1 version.

This is something that the rpmfind.net maintainer needs to know about.
So, I've cc:'d him (Daniel Veillard). Daniel, the problem is that the
CPAN archive under the redhat powertools is not indexed or searched
under rpmfind.net's RPM database. This has caused some confusion
relating to the perl-DBD-Pg RPM package, which is in the CPAN part of
powertools.

Ok, I will try to get this fixed by tomorrow,

Daniel

--
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks :
Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux XML libxml WWW
Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind
http://www.w3.org/People/all#veillard%40w3.org | RPM badminton Kaffe

From bouncefilter Sat Dec 4 11:06:33 1999
Received: from meryl.csd.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA27761
for <hackers@postgresql.org>; Sat, 4 Dec 1999 11:05:33 -0500 (EST)
(envelope-from e99re41@csd.uu.se)
Received: from torell.csd.uu.se (e99re41@torell.csd.uu.se [130.238.15.68])
by meryl.csd.uu.se (8.8.5/8.8.5) with SMTP id RAA01742
for <hackers@postgresql.org>; Sat, 4 Dec 1999 17:05:06 +0100 (MET)
Date: Sat, 4 Dec 1999 17:05:06 +0100 (MET)
From: Peter Eisentraut <e99re41@csd.uu.se>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: Availability of SQL standards
Message-ID: <Pine.GSO.3.96.991204165814.6079A-100000@torell.csd.uu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

As I get more involved with this project, and just in general, I was
thinking that it might be a good idea to have the SQL standards around.
I understand that the standards organizations are selling those, but a
quick search showed way too many documents at way too high prices in a way
too far away locality.

Are there any commercially available books that cover these as well to a
reasonable extent? I guess I can live without the technical grammar specs
if it shrinks volume and price. Of course an overview of actual
implementations (a.k.a. "how does Oracle do it") might be nice, too. I'm
not talking about any "Intro to SQL" books here, but the full deal. What
do you use?

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

From bouncefilter Sat Dec 4 14:02:35 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA71698
for <hackers@postgreSQL.org>; Sat, 4 Dec 1999 14:01:50 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA16289;
Sat, 4 Dec 1999 14:01:39 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912041901.OAA16289@candle.pha.pa.us>
Subject: Re: [HACKERS] Availability of SQL standards
In-Reply-To: <Pine.GSO.3.96.991204165814.6079A-100000@torell.csd.uu.se> from
Peter Eisentraut at "Dec 4, 1999 05:05:06 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sat, 4 Dec 1999 14:01:39 -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

As I get more involved with this project, and just in general, I was
thinking that it might be a good idea to have the SQL standards around.
I understand that the standards organizations are selling those, but a
quick search showed way too many documents at way too high prices in a way
too far away locality.

Are there any commercially available books that cover these as well to a
reasonable extent? I guess I can live without the technical grammar specs
if it shrinks volume and price. Of course an overview of actual
implementations (a.k.a. "how does Oracle do it") might be nice, too. I'm
not talking about any "Intro to SQL" books here, but the full deal. What
do you use?

I have <I>A Guide to the SQL Standard,</I> by C.J. Date, et. al,
Addison, Wesley

-- 
  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 Dec 4 14:35:35 1999
Received: from www.actarg.com (root@[209.180.91.25])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA75146
for <pgsql-hackers@postgresql.org>; Sat, 4 Dec 1999 14:34:48 -0500 (EST)
(envelope-from kyle@actarg.com)
Received: from actarg.com (root@tao.actarg.com [192.168.1.1])
by www.actarg.com (8.8.7/8.8.7) with ESMTP id MAA23140
for <pgsql-hackers@postgresql.org>; Sat, 4 Dec 1999 12:39:26 -0700
Received: from actarg.com (kyle@chi.actarg.com [192.168.2.16])
by actarg.com (8.8.7/8.8.7) with ESMTP id MAA12227
for <pgsql-hackers@postgresql.org>; Sat, 4 Dec 1999 12:33:34 -0700
Sender: kyle@actarg.com
Message-ID: <38496D18.96890910@actarg.com>
Date: Sat, 04 Dec 1999 12:35:52 -0700
From: Kyle Bateman <kyle@actarg.com>
Organization: Action Target Inc
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Raising funds for PostgreSQL
Content-Type: multipart/mixed; boundary="------------AC066BC6003F288FED70AEF2"

This is a multi-part message in MIME format.
--------------AC066BC6003F288FED70AEF2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I talked to Marc several months ago about the possibility of setting up
a system for raising money from commercial users of PostgreSQL kind of
like the "Street Performer Protocol" explained at:

http://www.counterpane.com/street_performer.html

It would basically allow people to view the todo list and to offer a bid
on various features and enhancements. At the same time, developers (you
guys) could bid on doing the actual work. When the bid pool on a
certain enhancement got large enough to fund a work bid, the enhancement
could be done and the developer could actually get paid for his work.

As a commercial user of PostgreSQL, I would be interested in throwing a
certain number of $$ at various problems/features of the software. If
others feel the same way, maybe we could accelerate the development
process and make it more fun for the people doing the actual work.

Is anyone interested in this kind of thing? Or are financial interests
not really the objective for most of the developers?

--------------AC066BC6003F288FED70AEF2
Content-Type: text/x-vcard; charset=us-ascii;
name="kyle.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Kyle Bateman
Content-Disposition: attachment;
filename="kyle.vcf"

begin:vcard
n:Bateman;Kyle
tel;fax:801-377-8096
tel;work:801-377-8033x101
x-mozilla-html:FALSE
url:www.actiontarget.com
org:Action Target Inc
adr:;;PO Box 636;Provo;UT;84603;US
version:2.1
email;internet:kyle@actiontarget.com
title:President
x-mozilla-cpt:;-15520
fn:Kyle Bateman
end:vcard

--------------AC066BC6003F288FED70AEF2--

From bouncefilter Sat Dec 4 15:32:36 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 PAA81579
for <pgsql-hackers@postgreSQL.org>; Sat, 4 Dec 1999 15:31:43 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA17915;
Sat, 4 Dec 1999 15:08:59 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912042008.PAA17915@candle.pha.pa.us>
Subject: Re: [HACKERS] Raising funds for PostgreSQL
In-Reply-To: <38496D18.96890910@actarg.com> from Kyle Bateman at "Dec 4, 1999
12:35:52 pm"
To: Kyle Bateman <kyle@actarg.com>
Date: Sat, 4 Dec 1999 15:08:59 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

As a commercial user of PostgreSQL, I would be interested in throwing a
certain number of $$ at various problems/features of the software. If
others feel the same way, maybe we could accelerate the development
process and make it more fun for the people doing the actual work.

Is anyone interested in this kind of thing? Or are financial interests
not really the objective for most of the developers?

Interesting idea.

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

From bouncefilter Sat Dec 4 15:10:36 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 PAA79346
for <hackers@postgreSQL.org>; Sat, 4 Dec 1999 15:10:34 -0500 (EST)
(envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max04-069.enterprise.net
[194.72.196.189])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id UAA06805;
Sat, 4 Dec 1999 20:10:31 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id UAA07317;
Sat, 4 Dec 1999 20:10:23 GMT
Message-Id: <199912042010.UAA07317@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To: Peter Eisentraut <peter_e@gmx.net>
cc: hackers@postgreSQL.org, olly@linda.lfix.co.uk
Subject: Re: [HACKERS] Availability of SQL standards
In-Reply-To: Message from Peter Eisentraut <e99re41@csd.uu.se> of "Sat,
04 Dec 1999 17:05:06 +0100."
<Pine.GSO.3.96.991204165814.6079A-100000@torell.csd.uu.se>
References: <Pine.GSO.3.96.991204165814.6079A-100000@torell.csd.uu.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 04 Dec 1999 20:10:23 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>

Peter Eisentraut wrote:

As I get more involved with this project, and just in general, I was
thinking that it might be a good idea to have the SQL standards around.
I understand that the standards organizations are selling those, but a
quick search showed way too many documents at way too high prices in a way
too far away locality.

Are there any commercially available books that cover these as well to a
reasonable extent? I guess I can live without the technical grammar specs
if it shrinks volume and price. Of course an overview of actual
implementations (a.k.a. "how does Oracle do it") might be nice, too. I'm
not talking about any "Intro to SQL" books here, but the full deal. What
do you use?

I have "SQL - The Standard Handbook" by SJ Cannan and GAM Otten, published
by McGraw-Hill 1993. ISBN: 0-07-707664-8. It cost me 35 pounds, 5 years
ago. It covers SQL-92 and it contains an appendix with the syntax in
BNF notation.

--
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
========================================
"Behold, happy is the man whom God correcteth.
Therefore despise thou not the chastening of the
Almighty." Job 5:17

From bouncefilter Sat Dec 4 15:52:38 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA84035
for <pgsql-hackers@postgresql.org>; Sat, 4 Dec 1999 15:52:05 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.3.127]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sat, 4 Dec 1999 14:47:53 -0600
Sender: ed
Message-ID: <38497E0B.992EB057@austin.rr.com>
Date: Sat, 04 Dec 1999 14:48:11 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Kyle Bateman <kyle@actarg.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
References: <38496D18.96890910@actarg.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

While I have no doubt such an idea for $$ for open source code development
would fly, my initial reaction would be opposed to it because I think the
overall effect would be to pollute the long-term purity of the open source
pgsql development effort by incenting short-sighted development to earn
cash. Quality controls can never keep up. Here's a bit more on my
perspective...

[long-winded self-important soapboxing hilosphical flame suit on]

I am a software developer who has benefitted tremendously from open source
software. Linux, Apache, Perl, SSL, PostgreSQL, GIMP...hundreds if not
thousands of pieces of open-source software. I have come to realize this
at a very gut level. We're talking about many, many years (hundreds?
thousands?) of labor via open source. Though not in cash, I have been
"paid" in value many times over via open source software. As a result of a
clear understanding that I along with everyone else will ultimately
benefit, I have a very personal and growing commitment to give back to the
open source movement. I do that by spending some of my personal time
helping others use these tools via forums, newsgroups, etc., by providing
feedback to developers, by providing bug fixes/patches/enhancements to open
source software where I can, and by generating open source software for
others.

What strikes me about open source development is that it is some of the
cleanest, purest development around. By that, I mean only that there is
far less of the sense of "doing the absolute minimum to get the money" that
is so prevalent in private for-profit corporations who will live or die by
next quarter's results and the short-term assessment of value-add by
shareholders. If you hang around these open source development forums for
very long and know much about how software design decisions often get made
in the corporate software world, you will notice a powerful design slant
toward longer-term vision as opposed to the tyranny of the urgent that
usually presides in the corporate environment. While I love the free
market and see a lot of validity to the free market theory behind the
market-driven corporate software development, I also think it is quite rare
that software developed under such circumstances has such benefit to the
world at large while also having the exponential opportunities to grow and
spread by the worldwide efforts of others. MS Excel is, IMO, probably the
most productive piece of software in existence. But it will always be
constrained by the fortunes of Microsoft or the holder of the intellectual
property rights. Open source, on the other hand, has the potential to
propagate indefinitely to benefit people everywhere indefinitely, because
it is free to grow. Both approaches seem valdi/important, and I think
there is a needed balance between proprietary nature of the private sector,
and the open source movement. It is a fine balance, and it is none too
clear on how to best draw it. It is a very complex issue with many sides.
Personally, I think it's quite related to many of the great debates of all
time, such as capitalism vs socialism vs communism, even the inherent
nature of human kind. But I digress. :)

But what is clear to me is that there is a lot of open source decision
making going on which is in the public's best interest. I don't have much
confidence that this would remain so if the proposal below played out.

[flame suit off]

Cheers.
Ed

Kyle Bateman wrote:

I talked to Marc several months ago about the possibility of setting up
a system for raising money from commercial users of PostgreSQL kind of
like the "Street Performer Protocol" explained at:

http://www.counterpane.com/street_performer.html

It would basically allow people to view the todo list and to offer a bid
on various features and enhancements. At the same time, developers (you
guys) could bid on doing the actual work. When the bid pool on a
certain enhancement got large enough to fund a work bid, the enhancement
could be done and the developer could actually get paid for his work.

As a commercial user of PostgreSQL, I would be interested in throwing a
certain number of $$ at various problems/features of the software. If
others feel the same way, maybe we could accelerate the development
process and make it more fun for the people doing the actual work.

Is anyone interested in this kind of thing? Or are financial interests
not really the objective for most of the developers?

From bouncefilter Sat Dec 4 16:16:36 1999
Received: from 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 QAA87029
for <pgsql-hackers@postgreSQL.org>; Sat, 4 Dec 1999 16:16:13 -0500 (EST)
(envelope-from aaron@genisys.ca)
Received: from stilborne (24.67.89.147.ab.wave.home.com [24.67.89.147])
by gtv.ca (8.9.3/8.8.7) with SMTP id PAA02128
for <pgsql-hackers@postgreSQL.org>; Sat, 4 Dec 1999 15:26:03 -0700
From: "Aaron J. Seigo" <aaron@gtv.ca>
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
Date: Sat, 4 Dec 1999 14:08:38 -0700
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <38496D18.96890910@actarg.com> <38497E0B.992EB057@austin.rr.com>
In-Reply-To: <38497E0B.992EB057@austin.rr.com>
MIME-Version: 1.0
Message-Id: <99120414150309.23724@stilborne>
Content-Transfer-Encoding: 8bit

hi..

While I have no doubt such an idea for $$ for open source code development
would fly, my initial reaction would be opposed to it because I think the
overall effect would be to pollute the long-term purity of the open source
pgsql development effort by incenting short-sighted development to earn
cash. Quality controls can never keep up. Here's a bit more on my
perspective...

<SNIP>

But what is clear to me is that there is a lot of open source decision
making going on which is in the public's best interest. I don't have much
confidence that this would remain so if the proposal below played out.

the solution to this "problem" is probably rediculously obvious, but here goes
anyways:

only items that are put on the to-do list by the developers can be bid on.

in other words, its stuff we'd get around to anyways... the $ incentive would
merely motivate us to get to it sooner...

hell, you could even put time/quality conditions on it... e.g. feature Y cannot
be commenced until feature X is completed (and if feature X is boring and dull,
perhaps it will sit for a long time undone, unless there are other incentives
(read: $) and therefore prelong the absence of much desired and sexy feature Y).

of course, before anyone gets paid, it has to be accepted into the mainstream
package.

how's that?

the only issue i'd see is that the current licensing scheme provides little
protection to the financial donors' investment (e.g. they could be financing
someone else's commercial development). but that's their problem...

--
Aaron J. Seigo
Sys Admin

From bouncefilter Sat Dec 4 16:14:55 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 QAA86666
for <pgsql-hackers@postgreSQL.org>; Sat, 4 Dec 1999 16:14:31 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA18979;
Sat, 4 Dec 1999 16:09:09 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912042109.QAA18979@candle.pha.pa.us>
Subject: Re: [HACKERS] Raising funds for PostgreSQL
In-Reply-To: <38497E0B.992EB057@austin.rr.com> from Ed Loehr at "Dec 4, 1999
02:48:11 pm"
To: Ed Loehr <ELOEHR@austin.rr.com>
Date: Sat, 4 Dec 1999 16:09:09 -0500 (EST)
CC: Kyle Bateman <kyle@actarg.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

While I have no doubt such an idea for $$ for open source code development
would fly, my initial reaction would be opposed to it because I think the
overall effect would be to pollute the long-term purity of the open source
pgsql development effort by incenting short-sighted development to earn
cash. Quality controls can never keep up. Here's a bit more on my
perspective...

My assumption is that the bids are open only to proven PostgreSQL
developers, and that the quality of the work must meet the same
standards we use for all our patches. All our patches are
peer-reviewed.

-- 
  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 Dec 4 18:48:38 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 SAA02609
for <hackers@postgreSQL.org>; Sat, 4 Dec 1999 18:47:49 -0500 (EST)
(envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm110.noc.fukui.nsk.ne.jp [210.161.188.29])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id IAA00700; Sun, 05 Dec 1999 08:45:19 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Vadim Mikheev" <vadim@krs.ru>,
"PostgreSQL Developers List" <hackers@postgreSQL.org>
Subject: RE: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Date: Sun, 5 Dec 1999 08:45:30 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFAEFICBAA.Inoue@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3354.944263984@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane

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

OK case by case. I will be glad to check them one by one.

I'm checking them for AccessExclusiveLock now.

7) commands/async.c(LISTEN/UNLISTEN)
This case seems dangerous too but unfortunately I couldn't
point out a concrete flaw now.

Holding the lock on pg_listener longer than absolutely necessary strikes
me as very risky, since any other backend might need to grab the lock
before it can complete its own transaction (in order to send or receive
notifies). Deadlock could ensue depending on what other locks are held.

It's difficult for me to find a flaw for this case.
There aren't so many conflicts. For example,LISTEN/UNLISTEN never
conflict relatively because they could be issued only for its own backend.
And as you say,it's very bad to hold the lock till end of transaction in
LISTEN/UNLISTEN.

Row level locking in MVCC may allow another(RowExclusiveLock?)
lock instead of AccessExclusiveLock.
I'm not sure now.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sun Dec 5 01:09:43 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA42982
for <pgsql-hackers@postgresql.org>; Sun, 5 Dec 1999 01:08:50 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id BAA03426
for <pgsql-hackers@postgresql.org>; Sun, 5 Dec 1999 01:05:10 -0500
Sender: mascarm@mascari.com
Message-ID: <3849BAD2.BD7620CB@mascari.com>
Date: Sat, 04 Dec 1999 20:07:31 -0500
From: Mike Mascari <mascarm@mascari.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: When is 7.0 going Beta?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

I was just wondering if there were any dates the major
developers had in mind as to when current will be released
as a beta release? For my trivial part, I still have to send
in a patch to allow pg_dump to dump COMMENT ON commands for
any descriptions the user might have created and was
wondering if any time frame had been established.

Just curious,

Mike

From bouncefilter Sun Dec 5 08:59:48 1999
Received: from netrinsics.com (robinson@[202.106.219.148])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA98818
for <pgsql-hackers@hub.org>; Sun, 5 Dec 1999 08:59:42 -0500 (EST)
(envelope-from robinson@netrinsics.com)
Received: (from robinson@localhost) by netrinsics.com (8.9.3/8.8.7) id
WAA01713
for pgsql-hackers@hub.org; Sun, 5 Dec 1999 22:00:11 +0800 (CST)
(envelope-from robinson)
Date: Sun, 5 Dec 1999 22:00:11 +0800 (CST)
From: Michael Robinson <robinson@netrinsics.com>
Message-Id: <199912051400.WAA01713@netrinsics.com>
To: pgsql-hackers@hub.org
Subject: The Accountant is not Amused

Is this fixed in later versions? If not, should I send in a patch?

-Michael Robinson

-----------------------------
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.1 on i386-unknown-freebsd3.3, compiled by gcc 2.7.2.3]

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

template1=> select 9.99::money * 0.1;
?column?
--------
$0.99
(1 row)

template1=> select 9.99::money / 10;
?column?
--------
$0.99
(1 row)

template1=> select 9.99::money / 10.0;
?column?
--------
$1.00
(1 row)

template1=>

From bouncefilter Sun Dec 5 11:17:50 1999
Received: from 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 LAA27753
for <pgsql-hackers@hub.org>; Sun, 5 Dec 1999 11:17:23 -0500 (EST)
(envelope-from aaron@genisys.ca)
Received: from stilborne (24.67.90.252.ab.wave.home.com [24.67.90.252])
by gtv.ca (8.9.3/8.8.7) with SMTP id KAA03967;
Sun, 5 Dec 1999 10:27:04 -0700
From: "Aaron J. Seigo" <aaron@gtv.ca>
To: Michael Robinson <robinson@netrinsics.com>, pgsql-hackers@hub.org
Subject: Re: [HACKERS] The Accountant is not Amused
Date: Sun, 5 Dec 1999 09:13:26 -0700
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <199912051400.WAA01713@netrinsics.com>
In-Reply-To: <199912051400.WAA01713@netrinsics.com>
MIME-Version: 1.0
Message-Id: <99120509164000.29522@stilborne>
Content-Transfer-Encoding: 8bit

hi.

Is this fixed in later versions? If not, should I send in a patch?

-Michael Robinson

<SNIPPED OUT LOTS OF MONEY DATA TYPE STUFF>

apparently, the money time is deprecated and will be going the way of the
dinosaurs someday soon (so threaten the developers)

we used the money data type extensively in an installation i run... with the
news of money going out of style however =) we switched to numeric(9,2) which
works quite well...

still some quirks with numeric: no money->numeric (surprise), int2 doesn't play
well with numeric (but converts easily to int4 which does)...

it took me 2 days to rid our system of money and update all our code... and now
it works much nicer, too!

--
Aaron J. Seigo
Sys Admin

From bouncefilter Sun Dec 5 12:19:50 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA34363
for <pgsql-hackers@hub.org>; Sun, 5 Dec 1999 12:18:57 -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 MAA06990;
Sun, 5 Dec 1999 12:17:54 -0500 (EST)
To: Michael Robinson <robinson@netrinsics.com>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] The Accountant is not Amused
In-reply-to: Your message of Sun, 5 Dec 1999 22:00:11 +0800 (CST)
<199912051400.WAA01713@netrinsics.com>
Date: Sun, 05 Dec 1999 12:17:54 -0500
Message-ID: <6988.944414274@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Michael Robinson <robinson@netrinsics.com> writes:

Is this fixed in later versions? If not, should I send in a patch?

What would you consider a patch? cash_div_flt8 rounds its result,
cash_div_int4 truncates. Which is right, and how many existing
apps might you break by changing the other one? How many of the
other money operators need to be tweaked too?

As Aaron points out, the money data type is looking awfully
dinosaur-like; nothing based on an int4 underlying representation
can possibly be really satisfactory for this purpose. The general
consensus on the hackers list has been that the money type should
be deprecated and eventually phased out. In the meantime, subtle
alterations of its behavior are of dubious value.

It seems to me, though, that the money type does offer a couple of
useful things that you don't get in raw NUMERIC; specifically,
input and output functions that are customized for currency display.
What really would be a useful project would be to reimplement money
as a thin overlay on NUMERIC, basically just input/output functions.
The interesting part of the job would be to do better in non-US
locales than we currently do; I don't think the money code is very
flexible about commas versus decimal points, for example.

regards, tom lane

From bouncefilter Sun Dec 5 12:53:51 1999
Received: from netrinsics.com (robinson@[202.106.219.148])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA37851
for <pgsql-hackers@hub.org>; Sun, 5 Dec 1999 12:53:05 -0500 (EST)
(envelope-from robinson@netrinsics.com)
Received: (from robinson@localhost) by netrinsics.com (8.9.3/8.8.7) id
BAA02628
for pgsql-hackers@hub.org; Mon, 6 Dec 1999 01:53:29 +0800 (CST)
(envelope-from robinson)
Date: Mon, 6 Dec 1999 01:53:29 +0800 (CST)
From: Michael Robinson <robinson@netrinsics.com>
Message-Id: <199912051753.BAA02628@netrinsics.com>
To: pgsql-hackers@hub.org
Subject: Re: [HACKERS] The Accountant is not Amused
In-Reply-To: <99120509164000.29522@stilborne>

"Aaron J. Seigo" <aaron@gtv.ca> writes:

still some quirks with numeric: no money->numeric (surprise), int2 doesn't play
well with numeric (but converts easily to int4 which does)...

Do you pay taxes?

================
template1=> select 9.99::numeric(9,2) * 0.1;
ERROR: Unable to identify an operator '*' for types 'numeric' and 'float8'
You will have to retype this query using an explicit cast
template1=> select 9.99::numeric(9,2) * 0.1::float4;
ERROR: Unable to identify an operator '*' for types 'numeric' and 'float4'
You will have to retype this query using an explicit cast
================

I need a type that exhibits correct financial rounding behavior in tax
computations and currency conversions. My understanding is that in the
U.S., you are supposed to compute to the mil, and then round. In China
(my jurisdiction of concern), you just round to the nearest fen.

-Michael Robinson

From bouncefilter Sun Dec 5 17:28:54 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA83272
for <hackers@postgresql.org>; Sun, 5 Dec 1999 17:28:31 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA41546;
Sun, 5 Dec 1999 18:28:34 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 5 Dec 1999 18:28:33 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Robert Aldridge <RALDRIDG@gulf-states.com>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Geometric Data Type in PostgreSQL
In-Reply-To: <3848209B.A543B73A@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.21.9912051828060.823-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 3 Dec 1999, Thomas Lockhart wrote:

I'm a geographic information systems (GIS) professional and a (home)
Linux user. After reading the documentation for the Geometric data
types in PostgreSQL, I'm excited about the possibilities. Are you
aware of any projects where the geometric data types in PostgreSQL are
being used as the basis of a GIS or mapping package?

Not specifically, though I do know that folks have used it to do
GIS-like things (e.g. given a location on the earth surface, identify
satellite tracks which are visible).

Isn't Peter Mount using PostgreSQL & JDBC for a GIS project?

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

From bouncefilter Sun Dec 5 17:34:00 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA83964
for <pgsql-hackers@postgresql.org>; Sun, 5 Dec 1999 17:33:15 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA41581;
Sun, 5 Dec 1999 18:33:22 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 5 Dec 1999 18:33:21 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Kyle Bateman <kyle@actarg.com>
cc: jeff@pgsql.com, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
In-Reply-To: <38496D18.96890910@actarg.com>
Message-ID: <Pine.BSF.4.21.9912051829510.823-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 4 Dec 1999, Kyle Bateman wrote:

I talked to Marc several months ago about the possibility of setting up
a system for raising money from commercial users of PostgreSQL kind of
like the "Street Performer Protocol" explained at:

http://www.counterpane.com/street_performer.html

It would basically allow people to view the todo list and to offer a bid
on various features and enhancements. At the same time, developers (you
guys) could bid on doing the actual work. When the bid pool on a
certain enhancement got large enough to fund a work bid, the enhancement
could be done and the developer could actually get paid for his work.

As a commercial user of PostgreSQL, I would be interested in throwing a
certain number of $$ at various problems/features of the software. If
others feel the same way, maybe we could accelerate the development
process and make it more fun for the people doing the actual work.

Is anyone interested in this kind of thing? Or are financial interests
not really the objective for most of the developers?

Ummm...read point 2 at: http://www.pgsql.com/mission.html

We should probably create a seperate, more visible link, but see the
Contribute item at:

http://www.pgsql.com/products.html

And, we even "advertise" the contributors:

http://www.pgsql.com/contributors.html

And note...this has all be here for months...

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

From bouncefilter Sun Dec 5 17:35:54 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA84286
for <pgsql-hackers@postgresql.org>; Sun, 5 Dec 1999 17:35:12 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA41588;
Sun, 5 Dec 1999 18:35:11 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 5 Dec 1999 18:35:10 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Mike Mascari <mascarm@mascari.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <3849BAD2.BD7620CB@mascari.com>
Message-ID: <Pine.BSF.4.21.9912051834500.823-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Non set in stone at this time...mid-Feb, I believe, was the last that was
thrown around...

On Sat, 4 Dec 1999, Mike Mascari wrote:

Hello,

I was just wondering if there were any dates the major
developers had in mind as to when current will be released
as a beta release? For my trivial part, I still have to send
in a patch to allow pg_dump to dump COMMENT ON commands for
any descriptions the user might have created and was
wondering if any time frame had been established.

Just curious,

Mike

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

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

From bouncefilter Sun Dec 5 17:47:54 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA86132
for <pgsql-hackers@postgreSQL.org>; Sun, 5 Dec 1999 17:46:56 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA41639;
Sun, 5 Dec 1999 18:46:43 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 5 Dec 1999 18:46:42 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Ed Loehr <ELOEHR@austin.rr.com>, Kyle Bateman <kyle@actarg.com>,
jeff@pgsql.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
In-Reply-To: <199912042109.QAA18979@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.9912051836420.823-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 4 Dec 1999, Bruce Momjian wrote:

While I have no doubt such an idea for $$ for open source code development
would fly, my initial reaction would be opposed to it because I think the
overall effect would be to pollute the long-term purity of the open source
pgsql development effort by incenting short-sighted development to earn
cash. Quality controls can never keep up. Here's a bit more on my
perspective...

My assumption is that the bids are open only to proven PostgreSQL
developers, and that the quality of the work must meet the same
standards we use for all our patches. All our patches are
peer-reviewed.

Actually, this is what PostgreSQL, Inc was formed for many months
back...there was, at one time, a URL on our page, and an email message
sent out by myself, explaining this whole "contribute toward
features" aspect of things, but, going through www.pgsql.com, it appears
to have been trim'd out at some point :(

Will go through my old mailboxes and see if I can find this again, but the
gist of the concept was that we have a contributions section on our web
page, which is currently a part of the products page...if you click on it,
the order for you get presented includes a list of those features where
you can contribute towards having that feature added...

The features that are listed right now are short, but if something isn't
listed, email us and we'll add it to the list...

The features listed has to be something on the TODO list...if not, it has
to be proposed to the -hackers list and added to the TODO list.

I'm searching through my old email rigth now to try and find the original
message on this, but this has both been discussed already *and*
implemented...

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

From bouncefilter Sun Dec 5 17:51:54 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 RAA86608
for <pgsql-hackers@postgreSQL.org>; Sun, 5 Dec 1999 17:50:58 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 11856 invoked by uid 1001); 5 Dec 1999 22:51:02 -0000
Message-ID: <XFMail.991205175102.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.BSF.4.21.9912051829510.823-100000@thelab.hub.org>
Date: Sun, 05 Dec 1999 17:51:02 -0500 (EST)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [HACKERS] Raising funds for PostgreSQL
Cc: jeff@pgsql.com, pgsql-hackers@postgreSQL.org,
Kyle Bateman <kyle@actarg.com>

On 05-Dec-99 The Hermit Hacker wrote:

Ummm...read point 2 at: http://www.pgsql.com/mission.html

We should probably create a seperate, more visible link, but see the
Contribute item at:

http://www.pgsql.com/products.html

And, we even "advertise" the contributors:

http://www.pgsql.com/contributors.html

And note...this has all be here for months...

Perhaps I should add something under the "Helping Us" link on the
developer's website?

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 Sun Dec 5 17:51:56 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA86639
for <hackers@postgresql.org>; Sun, 5 Dec 1999 17:51:26 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64209 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sGila159761>; Sun, 5 Dec 1999 23:51:18 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11ukZp-0002s8-00
for hackers@postgresql.org; Sun, 05 Dec 1999 23:56:21 +0100
Date: Sun, 5 Dec 1999 23:56:21 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgreSQL.org
Subject: postconfig/PGLIB/initdb
Message-ID: <Pine.LNX.4.20.9912051732410.10882-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

As I already hinted a while ago, I am trying to resolve some of the
various shell scripts' obscure dependencies on various environment
variables and paths. My question is whether the use of the program
postconfig to determine the PGLIB value (or anything else, since there are
no checks done) is still encouraged/desired/done. To be clear: Contrary
to what some of you might start to believe, I do not want to remove every
little feature in PostgreSQL that I don't like/understand/use ;) I'm just
wondering.

My survey showed that the only two places where PGLIB is used is
createlang and initdb, so in a normal environment there is no good reason
to have PGLIB set all the time, anyway. In a developer's environment,
where these commands are executed many times, PGLIB is going to mess you
up if you want to install several versions, which is exactly the reason
why I am looking at this.

I found a pretty fool-proof (and with Tom's help portable) way to
determine the location of the needed files (the bki's and the PL handlers)
from the actual location of the shell script, and if that fails (which it
shouldn't) you can always use the --pglib/-L option. This will, unless you
intentionally use a particularly evil installation layout, ensure that any
initdb or createlang (or whatever else might use this) call is always
going to use the correct files and backend version without you having to
do any setting of anything (including PATH).

So, to summarize:
* PGLIB, keep it or lose it?
* postconfig, keep it or lose it?

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

From bouncefilter Sun Dec 5 17:52:54 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 RAA86700
for <pgsql-hackers@hub.org>; Sun, 5 Dec 1999 17:51:56 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64651 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sGilt10272>; Sun, 5 Dec 1999 23:51:37 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11uka2-0002sC-00; Sun, 05 Dec 1999 23:56:34 +0100
Date: Sun, 5 Dec 1999 23:56:34 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Michael Robinson <robinson@netrinsics.com>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] The Accountant is not Amused
In-Reply-To: <199912051400.WAA01713@netrinsics.com>
Message-ID: <Pine.LNX.4.20.9912051650420.349-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 1999-12-05, Michael Robinson mentioned:

template1=> select 9.99::money / 10.0;
?column?
--------
$1.00
(1 row)

You should be using the numeric type. Money is deprecated. What you
pointed out is probably only one of its problems. However, the numeric
type seems to have some ideas of its own as well:

=> select 9.99::numeric(9,2) / 10.0::numeric(9,2);
?column?
------------
0.9990000000
(1 row)

What are the rules governing this situation?

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

From bouncefilter Sun Dec 5 18:18:54 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA90636
for <pgsql-hackers@postgreSQL.org>; Sun, 5 Dec 1999 18:18:07 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id TAA41919;
Sun, 5 Dec 1999 19:18:11 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 5 Dec 1999 19:18:10 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Vince Vielhaber <vev@michvhf.com>
cc: jeff@pgsql.com, pgsql-hackers@postgreSQL.org,
Kyle Bateman <kyle@actarg.com>
Subject: Re: [HACKERS] Raising funds for PostgreSQL
In-Reply-To: <XFMail.991205175102.vev@michvhf.com>
Message-ID: <Pine.BSF.4.21.9912051917100.823-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 5 Dec 1999, Vince Vielhaber wrote:

On 05-Dec-99 The Hermit Hacker wrote:

Ummm...read point 2 at: http://www.pgsql.com/mission.html

We should probably create a seperate, more visible link, but see the
Contribute item at:

http://www.pgsql.com/products.html

And, we even "advertise" the contributors:

http://www.pgsql.com/contributors.html

And note...this has all be here for months...

Perhaps I should add something under the "Helping Us" link on the
developer's website?

that sounds good...Jeff and I are going to re-work the contribute stuff,
since its pretty hidden right now :( will announce something this week on
it...

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

From bouncefilter Sun Dec 5 19:12:55 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 TAA97001
for <hackers@postgreSQL.org>; Sun, 5 Dec 1999 19:12:01 -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 TAA07790;
Sun, 5 Dec 1999 19:11:21 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] postconfig/PGLIB/initdb
In-reply-to: Your message of Sun, 5 Dec 1999 23:56:21 +0100 (CET)
<Pine.LNX.4.20.9912051732410.10882-100000@localhost.localdomain>
Date: Sun, 05 Dec 1999 19:11:21 -0500
Message-ID: <7788.944439081@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

So, to summarize:
* PGLIB, keep it or lose it?

I had assumed that PGLIB was used for dynamic loading of extension
modules, but I now see that it isn't. It's primarily used by initdb
to find the data files needed for initialization of template1. AFAICT
it's not used by a running postmaster or backend at all.

If you can reliably find the location of the executing script, I
think it'd be a fine idea to lose PGLIB and instead get the data
files from "BINDIR/../lib/". One less setting to get wrong.

(I'm not convinced yet about that "if", though. Do you have a
substitute for "which" that you think is portable? How can we
test it?)

* postconfig, keep it or lose it?

Since postconfig is invoked as just "postconfig", trying to use it
introduces a very strong dependency on PATH. I've never used it
so maybe I'm not seeing what it's good for --- but my guess is that
in the situation where you've got multiple versions installed, trying
to use postconfig would just result in confusion and havoc. And in
the case where you have only one installation, it's not necessary.

I'm not really seeing what postconfig brings to the party. If you
want the config to depend on your path, you can put the appropriate
BINDIR in your path, no?

regards, tom lane

From bouncefilter Sun Dec 5 19:56:55 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA02170;
Sun, 5 Dec 1999 19:56:34 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id UAA42634;
Sun, 5 Dec 1999 20:56:48 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 5 Dec 1999 20:56:47 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-general@postgresql.org
cc: jeff@pgsql.com, pgsql-hackers@postgresql.org
Subject: Oft Ask: How to contribute to PostgreSQL?
Message-ID: <Pine.BSF.4.21.9912052011040.823-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Due to a recent thread started on pgsql-hackers, I'm posting this to the
lists. Vince is planning on putting in appropriate links for some of
this, and, Bruce, can we maybe put it into the FAQ?

I'm not an English major, so this is more techinese then anything
else...or, a rambling of an un-ordered mind, however you want to classify
it :)

============

There are several ways that people can contribute to the PostgreSQL
project, and, below, I'm going to try and list them...

1. Code. We have a TODO list available at
http://www.postgresql.org/docs/todo.html, which lists enhancements that
have been picked out as needed. Some of them take time to learn the
intricacies of the code, some require no more then time. Contributing
code, altho not the only way to contribute, is always one of the more
valuable ways of improving any Open Source Project.

2. Web Site. http://www.postgresql.org is mirrored on many sites around
the world, as is ftp://ftp.postgresql.org. By increasing the number of
mirrors available around the world, you help reduce the load on any one
site, as well as improve the accessibility to the code. If you have
the resources to provide a mirror, both hardware and bandwidth, this is
another means of contributing to the project. All our mirrors are
required to use rsync, in order to be listed, with details on this
found at http://www.postgresql.org/howtomirror.html

3. Mailing Lists. We use software that allows us to use remote sites for
'mail relaying'. Basically, instead of our central server having to
service *all* remote addresses, it offloads email onto remote servers
to do the distribution. For intance, by dumping all email destined for
a subscribers in France to a server residing in France, the central
server has to send one email mesage "Across the pond", and let the
server in France handle the other servers. If you are interested in
providing a relay point, email scrappy@hub.org (me) for details on how
to get setup for this.

4. Financial. In June of 1999, PostgreSQL, Inc was formed as the
"Commercial Arm" of the PostgreSQL Project. Although it was originally
formed to provide Commercial Support for PostgreSQL, it has expanded to
include Consulting services, PostgreSQL Merchandise (ElephantWear) and,
most recently, Database Hosting services.

As our mission statement (http://www.pgsql.com/mission.html) states,
our purpose (among several) is to provide funding for various project,
whether they be Advertising or Programming. Although not currently
available, but will be when the new site is up, there will be a set of
pages off of http://www.pgsql.com that will provide a cleaner means of
contribute financially towards having features implemented, as well as
showing funds available for various projects. For instance, 25% of the
revenue from Support Contracts will be ear-marked for stuff like
Advertising and a General Pool that we can use to fund projects that we
feel is important from a "commercial deployment" standpoint.

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

From bouncefilter Sun Dec 5 20:51:56 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA08332
for <hackers@postgreSQL.org>; Sun, 5 Dec 1999 20:50:58 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id BAA17471;
Mon, 6 Dec 1999 01:53:28 GMT
Sender: lockhart@hub.org
Message-ID: <384B1718.A712223@alumni.caltech.edu>
Date: Mon, 06 Dec 1999 01:53:28 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] Availability of SQL standards
References: <Pine.GSO.3.96.991204165814.6079A-100000@torell.csd.uu.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

What do you use?

As does Bruce, I use the Date book. One nice feature of the newest
editions is that there is mention of SQL3 in an appendix.

Also, we have a 1992 draft version of the SQL92 standard which seems
to match up pretty well with the final release. I can send copies if
you would like...

- Thomas

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

From bouncefilter Sun Dec 5 20:56:56 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA13020
for <pgsql-hackers@postgreSQL.org>; Sun, 5 Dec 1999 20:56:04 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id BAA17478;
Mon, 6 Dec 1999 01:58:50 GMT
Sender: lockhart@hub.org
Message-ID: <384B185A.80F4E97B@alumni.caltech.edu>
Date: Mon, 06 Dec 1999 01:58:50 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Mascari <mascarm@mascari.com>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
References: <3849BAD2.BD7620CB@mascari.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I was just wondering if there were any dates the major
developers had in mind as to when current will be released
as a beta release? For my trivial part, I still have to send
in a patch to allow pg_dump to dump COMMENT ON commands for
any descriptions the user might have created and was
wondering if any time frame had been established.

My recollection was that February has been discussed. But since it is
a major rev bump we would rather get the features which (perhaps) have
been waiting for a major rev, and these big changes may influence the
beta date...

- Thomas

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

From bouncefilter Sun Dec 5 20:57:56 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA13157
for <pgsql-hackers@hub.org>; Sun, 5 Dec 1999 20:57:41 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id CAA17485;
Mon, 6 Dec 1999 02:00:30 GMT
Sender: lockhart@hub.org
Message-ID: <384B18BE.3EC35EEF@alumni.caltech.edu>
Date: Mon, 06 Dec 1999 02:00:30 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Robinson <robinson@netrinsics.com>
CC: pgsql-hackers@hub.org
Subject: Re: [HACKERS] The Accountant is not Amused
References: <199912051400.WAA01713@netrinsics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Is this fixed in later versions? If not, should I send in a patch?

Send patches. But there is a chance that the money type will be ripped
out for v7.0 (since afaik the numeric/decimal types supercede the
older hacked type).

- Thomas

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

From bouncefilter Sun Dec 5 21:00:56 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA13855
for <hackers@postgresql.org>; Sun, 5 Dec 1999 21:00:15 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id CAA17540;
Mon, 6 Dec 1999 02:03:03 GMT
Sender: lockhart@hub.org
Message-ID: <384B1957.18A20233@alumni.caltech.edu>
Date: Mon, 06 Dec 1999 02:03:03 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: Robert Aldridge <RALDRIDG@gulf-states.com>,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Re: Geometric Data Type in PostgreSQL
References: <Pine.BSF.4.21.9912051828060.823-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Isn't Peter Mount using PostgreSQL & JDBC for a GIS project?

Astronomical project afaik...

- Thomas

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

From bouncefilter Sun Dec 5 22:18:57 1999
Received: from ocis.ocis.net (IDENT:root@ocis.ocis.net [209.52.173.1])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA31194
for <pgsql-general@hub.org>; Sun, 5 Dec 1999 22:18:40 -0500 (EST)
(envelope-from jcl@mail.ocis.net)
Received: from mail.ocis.net (jcl@dial-265.ocis.net [209.52.174.99])
by ocis.ocis.net (8.9.3/8.9.3) with ESMTP id TAA31420
for <pgsql-general@hub.org>; Sun, 5 Dec 1999 19:18:38 -0800
Sender: jcl@ocis.ocis.net
Message-ID: <384B2A57.B779C4B9@mail.ocis.net>
Date: Sun, 05 Dec 1999 19:15:35 -0800
From: "Jason C. Leach" <jcl@mail.ocis.net>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.13 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-list <pgsql-general@hub.org>
Subject: Re: [GENERAL] Oft Ask: How to contribute to PostgreSQL?
References: <Pine.BSF.4.21.9912052011040.823-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

hi,

Is PG done in C or C++?

--
.............
......... Jason C. Leach
...... University College of the Cariboo
... jcl@mail.ocis.net.
.. http://www.ocis.net/~jcl
.

Debian!Linux!

From bouncefilter Sun Dec 5 22:34: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 WAA33220
for <pgsql-hackers@postgreSQL.org>; Sun, 5 Dec 1999 22:34:17 -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 KAA20034;
Mon, 6 Dec 1999 10:33:46 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <384B2E98.E9369A9B@krs.ru>
Date: Mon, 06 Dec 1999 10:33:44 +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: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Mike Mascari <mascarm@mascari.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
References: <3849BAD2.BD7620CB@mascari.com>
<384B185A.80F4E97B@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

I was just wondering if there were any dates the major
developers had in mind as to when current will be released
as a beta release? For my trivial part, I still have to send
in a patch to allow pg_dump to dump COMMENT ON commands for
any descriptions the user might have created and was
wondering if any time frame had been established.

My recollection was that February has been discussed. But since it is
a major rev bump we would rather get the features which (perhaps) have
been waiting for a major rev, and these big changes may influence the
beta date...

Seems that I'll be able to return to WAL development in Feb
only. So, good beta date for me is Apr/May...
Sorry, but... life is life.

Vadim

From bouncefilter Sun Dec 5 22:38:57 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA33795
for <pgsql-general@hub.org>; Sun, 5 Dec 1999 22:38:40 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA43627;
Sun, 5 Dec 1999 23:38:31 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 5 Dec 1999 23:38:30 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: "Jason C. Leach" <jcl@mail.ocis.net>
cc: pgsql-list <pgsql-general@hub.org>
Subject: Re: [GENERAL] Oft Ask: How to contribute to PostgreSQL?
In-Reply-To: <384B2A57.B779C4B9@mail.ocis.net>
Message-ID: <Pine.BSF.4.21.9912052338200.823-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 5 Dec 1999, Jason C. Leach wrote:

hi,

Is PG done in C or C++?

C

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

From bouncefilter Sun Dec 5 23:03: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 XAA37666
for <pgsql-hackers@postgreSQL.org>; Sun, 5 Dec 1999 23:02:57 -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 XAA14916
for <pgsql-hackers@postgreSQL.org>; Sun, 5 Dec 1999 23:02:27 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-reply-to: Your message of Mon, 06 Dec 1999 10:33:44 +0700
<384B2E98.E9369A9B@krs.ru>
Date: Sun, 05 Dec 1999 23:02:26 -0500
Message-ID: <14914.944452946@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Vadim Mikheev <vadim@krs.ru> writes:

Seems that I'll be able to return to WAL development in Feb
only. So, good beta date for me is Apr/May...
Sorry, but... life is life.

I'm not anywhere near "ready" either, at least if "ready" means all the
stuff I'd hoped to get done for 7.0.

If we want to do a schedule-driven release around Feb, fine, but let's
call it 6.6. 7.0 ought to be driven by features not calendar.

regards, tom lane

From bouncefilter Sun Dec 5 23:30:58 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA47654
for <pgsql-hackers@postgresql.org>; Sun, 5 Dec 1999 23:30:07 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id AAA44257;
Mon, 6 Dec 1999 00:30:03 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 6 Dec 1999 00:30:02 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <14914.944452946@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.9912060028160.823-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 5 Dec 1999, Tom Lane wrote:

Vadim Mikheev <vadim@krs.ru> writes:

Seems that I'll be able to return to WAL development in Feb
only. So, good beta date for me is Apr/May...
Sorry, but... life is life.

I'm not anywhere near "ready" either, at least if "ready" means all the
stuff I'd hoped to get done for 7.0.

If we want to do a schedule-driven release around Feb, fine, but let's
call it 6.6. 7.0 ought to be driven by features not calendar.

I believe that we've already agreed that there are features going into the
source tree currently that are prompting a 7.0 release...I have no qualms
at all about holding off the next release until Apr/May, as long as we
continue with what we've started, and that is back-patching appropriate
changes to the -STABLE source tree and putting out a minor release
periodically...

I'd like to stick with the next "full release" being 7.0 ...

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

From bouncefilter Mon Dec 6 03:51: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 DAA83016
for <pgsql-hackers@postgresql.org>; Mon, 6 Dec 1999 03:50:33 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id RAA04418
for <pgsql-hackers@postgresql.org>; Mon, 6 Dec 1999 17:50:32 +0900 (JST)
Received: from localhost (IDENT:t-ishii@srapc968-yotsuya [133.137.36.133])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id RAA28939
for <pgsql-hackers@postgresql.org>; Mon, 6 Dec 1999 17:50:32 +0900
To: pgsql-hackers@postgresql.org
Subject: pg_ctl
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991206181144M.t-ishii@sra.co.jp>
Date: Mon, 06 Dec 1999 18:11:44 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 106

As I promised, I have written a small program called "pg_ctl" to
start/stop/restart postmaster. I have committed into src/bin/pg_ctl.
Please remember to pull the latest postmaster.c.

o How to use

pg_ctl has three modes:

1. startup mode

pg_ctl [-w][-D database_dir][-p path_to_postmaster][-o "postmaster_opts"] start

start postmaster. If -w is specified, pg_ctl will block until database
is in the production mode. -D sets path to the database directory,
which overrides the environment variable $PGDATA. pg_ctl finds
postmaster.pid and other files under the directory. -p specifies the
path to postmaster. If -p is not given, default path (generated as
$(BINDIR)/postmaster while making pg_ctl from pg_ctl.sh) will be used.
If -o option is not given, pg_ctl will take options for postmaster
from $PGDATA/postamster.opts.default. Note that this file is not
currently installed by "make install." So you have to make it by hand
or could copy from postmaster.opts that is made once pg_ctl starts
postmaster. Sample postmaster.opts.default looks like:

postmaster
-S

or you could write it in one line:

postmaster -S

2. stop mode

pg_ctl [-w][-D database_dir][-m s[mart]|f[ast]|i[mmediate]] stop

stop postmaster. -m specifies database shutdown method. The default
is "-m smart".

3. restart mode

pg_ctl [-w][-D database_dir][-m s[mart]|f[ast]|i[mmediate]][-o "postmaster_opts"] restart

stop postmaster, then start it again. Options to start postmaster is
taken from $PGDATA/postmaster.opts unless -o is given.

4. status reporting mode

pg_ctl [-D database_dir] status

reports status of postmaster. Currently reported information is
relatively limited. Hopefully we could add the functionarity to report
more valuable info such as number of backend running.

o sample session

Here is an example session using pg_ctl:

$ pg_ctl stop # stop postmaster
postmaster successfully shut down.
$ pg_ctl stop # cannot stop postmaster if it is not running
pg_ctl: Can't find /usr/local/src/pgsql/current/data/postmaster.pid.
Is postmaster running?
$ pg_ctl start # start postmaster
postmaster successfully started up.
$ pg_ctl status # status report
$ pg_ctl status
pg_ctl: postmaster is running (pid: 736)
options are:
/usr/local/src/pgsql/current/bin/postmaster
-p 5432
-D /usr/local/src/pgsql/current/data
-B 64
-b /usr/local/src/pgsql/current/bin/postgres
-N 32
-S
$ pg_ctl restart # stop postmaster then start it again
Waiting for postmaster shutting down...done.
postmaster successfully shut down.
postmaster successfully started up.
$ pg_ctl status # see how the pid is different from before
pg_ctl: postmaster is running (pid: 761)
options are:
/usr/local/src/pgsql/current/bin/postmaster
-p 5432
-D /usr/local/src/pgsql/current/data
-B 64
-b /usr/local/src/pgsql/current/bin/postgres
-N 32
-S
$ pg_ctl -o "-S -B 1024 -N 128 -o -F" restart # restart with different options
Waiting for postmaster shutting down...done.
postmaster successfully shut down.
postmaster successfully started up.
$ pg_ctl status
pg_ctl: postmaster is running (pid: 961)
options are:
/usr/local/src/pgsql/current/bin/postmaster
-p 5432
-D /usr/local/src/pgsql/current/data
-B 1024
-b /usr/local/src/pgsql/current/bin/postgres
-N 128
-S
-o '-F'
--
Tatsuo Ishii

From bouncefilter Mon Dec 6 05:13:16 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 FAA96344
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 05:12:26 -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 KAA17669
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 10:59:23 +0100
Date: Mon, 6 Dec 1999 10:59:23 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: RAW I/O device
Message-ID: <Pine.LNX.3.96.991206104444.14133A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Linux now exist project for raw I/O device
(http://oss.sgi.com/projects/rawio/). Exist any plan (for far future)
with raw device for PgSQL? (TODO be quiet for this.)

Karel

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

Docs: http://docs.linux.cz (big docs archive)
Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
-----------------------------------------------------------------------

From bouncefilter Mon Dec 6 07:40:21 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 HAA14676
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 07:39:25 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11uwV2-0003kGC; Mon, 6 Dec 99 12:40 MET
Message-Id: <m11uwV2-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] RAW I/O device
To: zakkr@zf.jcu.cz (Karel Zak - Zakkr)
Date: Mon, 6 Dec 1999 12:40:12 +0100 (MET)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <Pine.LNX.3.96.991206104444.14133A-100000@ara.zf.jcu.cz> from
"Karel Zak - Zakkr" at Dec 6, 99 10:59:23 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

On Linux now exist project for raw I/O device
(http://oss.sgi.com/projects/rawio/). Exist any plan (for far future)
with raw device for PgSQL? (TODO be quiet for this.)

Up to now we kept the storage manager overhead in the system.
Actually there is no way to tell which storage manager to use
for a particular table/index, so anything goes to the default
which is the magnetic disk one that uses single files for
each relation.

There was a discussion about simplifying it, but the
consensus was to let it as is because it is the base for a
tablespace and/or raw device manager.

AFAIK, noone is working on it, so it must be really FAR
future. But the plan is still alive.

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 Dec 6 06:57:20 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 GAA10414
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 06:56:35 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Panter.DoCS.UU.SE (e99re41@Panter.DoCS.UU.SE [130.238.9.114])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id MAA13385;
Mon, 6 Dec 1999 12:56:33 +0100
Received: from localhost (e99re41@localhost) by Panter.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA01849; Mon, 6 Dec 1999 12:56:31 +0100
X-Authentication-Warning: Panter.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 6 Dec 1999 12:56:31 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_ctl
In-Reply-To: <19991206181144M.t-ishii@sra.co.jp>
Message-ID: <Pine.GSO.4.02A.9912061251380.1828-100000@Panter.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 6 Dec 1999, Tatsuo Ishii wrote:

pg_ctl [-w][-D database_dir][-p path_to_postmaster][-o "postmaster_opts"] start

postmaster.pid and other files under the directory. -p specifies the
path to postmaster. If -p is not given, default path (generated as
$(BINDIR)/postmaster while making pg_ctl from pg_ctl.sh) will be used.

May I issue a complaint? The use of the configure time generated BINDIR
for finding binaries at run time is not only an explicitly discouraged
abuse of the whole autoconf concept, it might potentially lead to big
problems when packages are built in temporary trees. I'm currently working
on a portable "which" alternative. When I get it done, I'll suggest that
one to you.

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

From bouncefilter Mon Dec 6 08:01:21 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 IAA17552
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 08:00:35 -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 NAA28758;
Mon, 6 Dec 1999 13:47:18 +0100
Date: Mon, 6 Dec 1999 13:47:18 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Jan Wieck <wieck@debis.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RAW I/O device
In-Reply-To: <m11uwV2-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.LNX.3.96.991206133158.26995A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 6 Dec 1999, Jan Wieck wrote:

On Linux now exist project for raw I/O device
(http://oss.sgi.com/projects/rawio/). Exist any plan (for far future)
with raw device for PgSQL? (TODO be quiet for this.)

Up to now we kept the storage manager overhead in the system.
Actually there is no way to tell which storage manager to use
for a particular table/index, so anything goes to the default
which is the magnetic disk one that uses single files for
each relation.

There was a discussion about simplifying it, but the
consensus was to let it as is because it is the base for a
tablespace and/or raw device manager.

AFAIK, noone is working on it, so it must be really FAR
future. But the plan is still alive.

I raise the question, because the linux kernel opening with raw-device
new way for a faster and better database engine. I know (and agree)
that it not is priority for next year(s?). But it is interesting, and
is prabably good remember it during development, and not write (in future)
features which close this good way.

Karel

From bouncefilter Mon Dec 6 08:00:22 1999
Received: from gate.plzen-city.cz (gate.plzen-city.cz [194.212.191.10])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA17175
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 07:59:47 -0500 (EST)
(envelope-from horak@sit.plzen-city.cz)
Received: (from mail@localhost) by gate.plzen-city.cz (8.9.3/8.9.1) id
NAA05617
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 13:59:45 +0100
Received: from EXCHANGE.mmp.plzen-city.cz(s5srvr2.mmp.plzen-city.cz
192.168.4.22) by gate.plzen-city.cz via smap (v1.3-ps12tp)
id sma005607; Mon Dec 6 13:59:40 1999
Received: by exchange.mmp.plzen-city.cz with Internet Mail Service
(5.5.2650.21) id <X6CQ74QQ>; Mon, 6 Dec 1999 13:59:38 +0100
Message-ID:
<F4A9A276019AD311B08C00A024B251700587F7@exchange.mmp.plzen-city.cz>
From: Horak Daniel <horak@sit.plzen-city.cz>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] RAW I/O device
Date: Mon, 6 Dec 1999 13:59:36 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"

On Linux now exist project for raw I/O device
(http://oss.sgi.com/projects/rawio/). Exist any plan (for

far future)

with raw device for PgSQL? (TODO be quiet for this.)

Up to now we kept the storage manager overhead in the system.
Actually there is no way to tell which storage manager to use
for a particular table/index, so anything goes to the default
which is the magnetic disk one that uses single files for
each relation.

There was a discussion about simplifying it, but the
consensus was to let it as is because it is the base for a
tablespace and/or raw device manager.

AFAIK, noone is working on it, so it must be really FAR
future. But the plan is still alive.

I have done some work in this area - mostly to recognize new keywords
(CREATE TABLESPACE ...) and I have also created a new storage manager, but I
have stopped it due the lack of free time ;-). I can send a patch for 6.5.1.

In my opinion, the main problem is with accessing shared system tables (like
pg_database) and to include a storage manager type into the tuples in
pg_database. But I think it is possible to solve this problems.

Dan

From bouncefilter Mon Dec 6 08:04:21 1999
Received: from dione.scl.cwru.edu (dione.SCL.CWRU.Edu [129.22.32.18])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA17831
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 08:03:49 -0500 (EST)
(envelope-from merlin@scl.cwru.edu)
From: merlin@scl.cwru.edu
Received: from tigris (tigris [129.22.32.24])
by dione.scl.cwru.edu (8.9.3/8.9.3) with ESMTP id IAA22076;
Mon, 6 Dec 1999 08:03:26 -0500 (EST)
Date: Mon, 6 Dec 1999 08:03:25 -0500 (EST)
X-Sender: merlin@tigris
To: Jan Wieck <wieck@debis.com>
cc: Karel Zak - Zakkr <zakkr@zf.jcu.cz>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RAW I/O device
In-Reply-To: <m11uwV2-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.GSO.4.10.9912060801200.8858-100000@tigris>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I may be out of place on this one, but remember that postgres runs on
other systems besides linux. Making the DB work w/ one FS (and write the
storage code for it) seems pointless if we are still stuck on normal FSs
on other machines.

- merlin

On Linux now exist project for raw I/O device
(http://oss.sgi.com/projects/rawio/). Exist any plan (for far future)
with raw device for PgSQL? (TODO be quiet for this.)

Up to now we kept the storage manager overhead in the system.
Actually there is no way to tell which storage manager to use
for a particular table/index, so anything goes to the default
which is the magnetic disk one that uses single files for
each relation.

There was a discussion about simplifying it, but the
consensus was to let it as is because it is the base for a
tablespace and/or raw device manager.

AFAIK, noone is working on it, so it must be really FAR
future. But the plan is still alive.

------++++======++++------
Smith Computer Lab Administrator, Case Western Reserve University
bap@scl.cwru.edu | 216.368.5066 | http://home.cwru.edu/~bap
------++++======++++------

From bouncefilter Mon Dec 6 08:26:22 1999
Received: from gate.plzen-city.cz (gate.plzen-city.cz [194.212.191.10])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA21504
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 08:25:57 -0500 (EST)
(envelope-from horak@sit.plzen-city.cz)
Received: (from mail@localhost) by gate.plzen-city.cz (8.9.3/8.9.1) id
OAA06498
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 14:25:52 +0100
Received: from EXCHANGE.mmp.plzen-city.cz(s5srvr2.mmp.plzen-city.cz
192.168.4.22) by gate.plzen-city.cz via smap (v1.3-ps12tp)
id sma006490; Mon Dec 6 14:25:27 1999
Received: by exchange.mmp.plzen-city.cz with Internet Mail Service
(5.5.2650.21) id <X6CQ74T6>; Mon, 6 Dec 1999 14:25:27 +0100
Message-ID:
<F4A9A276019AD311B08C00A024B25170058800@exchange.mmp.plzen-city.cz>
From: Horak Daniel <horak@sit.plzen-city.cz>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] RAW I/O device
Date: Mon, 6 Dec 1999 14:25:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"

On Linux now exist project for raw I/O device
(http://oss.sgi.com/projects/rawio/). Exist any plan (for

far future)

with raw device for PgSQL? (TODO be quiet for this.)

Up to now we kept the storage manager overhead in the system.
Actually there is no way to tell which storage manager to use
for a particular table/index, so anything goes to the default
which is the magnetic disk one that uses single files for
each relation.

There was a discussion about simplifying it, but the
consensus was to let it as is because it is the base for a
tablespace and/or raw device manager.

AFAIK, noone is working on it, so it must be really FAR
future. But the plan is still alive.

I have done some work in this area - mostly to recognize new keywords
(CREATE TABLESPACE ...) and I have also created a new storage manager, but I
have stopped it due the lack of free time ;-). I can send a patch for 6.5.1.

In my opinion, the main problem is with accessing shared system tables (like
pg_database) and to include a storage manager type into the tuples in
pg_database. But I think it is possible to solve this problems.

Dan

From bouncefilter Mon Dec 6 08:26:22 1999
Received: from inet.faster.cz ([195.144.108.235])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA21519
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 08:26:09 -0500 (EST)
(envelope-from pajasoft@fonet.cz)
Received: from pajasoft.fonet.cz ([195.144.108.236])
by inet.faster.cz (8.8.7/8.8.7) with ESMTP id OAA20601;
Mon, 6 Dec 1999 14:26:07 +0100
Received: from fonet.cz (localhost [127.0.0.1])
by pajasoft.fonet.cz (8.9.3/8.9.3) with ESMTP id OAA26160;
Mon, 6 Dec 1999 14:26:07 +0100
Sender: pajasoft@pajasoft.fonet.cz
Message-ID: <384BB96F.AB25511A@fonet.cz>
Date: Mon, 06 Dec 1999 14:26:07 +0100
From: "Ing. Pavel PaJaSoft Janousek" <pajasoft@fonet.cz>
Organization: FoNet, spol. s r.o.
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: cs, en
MIME-Version: 1.0
To: merlin@scl.cwru.edu
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] RAW I/O device
References: <Pine.GSO.4.10.9912060801200.8858-100000@tigris>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit

other systems besides linux. Making the DB work w/ one FS (and write the
storage code for it) seems pointless if we are still stuck on normal FSs
on other machines.

Yes, of course, but storing databases directly to RAW device - not
through the filesystem - is one feature of modern DB engines...

--------------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft) FoNet, spol. s r. o.
Vyvoj software, sprava siti, Unix, Web, Y2K Anenska 11, 602 00 Brno
E-mail: mailto:Janousek@FoNet.Cz Tel.: +420 5 4324 4749
SMS: mailto:P.Janousek@SMS.Paegas.Cz Fax.: +420 5 4324 4751
WWW: http://WWW.FoNet.Cz/ E-mail:
mailto:Info@FoNet.Cz
--------------------------------------------------------------------------

From bouncefilter Mon Dec 6 08:38:22 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA23485
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 08:38:12 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
IAA18633;
Mon, 6 Dec 1999 08:35:27 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912061335.IAA18633@candle.pha.pa.us>
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <14914.944452946@sss.pgh.pa.us> from Tom Lane at "Dec 5,
1999 11:02:26 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 6 Dec 1999 08:35:27 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Vadim Mikheev <vadim@krs.ru> writes:

Seems that I'll be able to return to WAL development in Feb
only. So, good beta date for me is Apr/May...
Sorry, but... life is life.

I'm not anywhere near "ready" either, at least if "ready" means all the
stuff I'd hoped to get done for 7.0.

If we want to do a schedule-driven release around Feb, fine, but let's
call it 6.6. 7.0 ought to be driven by features not calendar.

I am concerned about a May release. That puts us at almost a year from
the last major release in mid-June. That is too long. Seems like we
should have some release around February.

-- 
  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 Dec 6 09:45:43 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA33368
for <pgsql-hackers@postgresql.org>; Mon, 6 Dec 1999 09:44:51 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id KAA48552;
Mon, 6 Dec 1999 10:44:59 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 6 Dec 1999 10:44:55 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: "Ing. Pavel PaJaSoft Janousek" <pajasoft@fonet.cz>
cc: merlin@scl.cwru.edu, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] RAW I/O device
In-Reply-To: <384BB96F.AB25511A@fonet.cz>
Message-ID: <Pine.BSF.4.21.9912061041290.18029-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 6 Dec 1999, Ing. Pavel PaJaSoft Janousek wrote:

other systems besides linux. Making the DB work w/ one FS (and write the
storage code for it) seems pointless if we are still stuck on normal FSs
on other machines.

Yes, of course, but storing databases directly to RAW device - not
through the filesystem - is one feature of modern DB engines...

Actually, Oracle has been moving *away* from this...more recent versions
of Oracle recommend using the Operating System file systems, since, in
most cases, the Operating System does a better job, and its too difficult
to have Oracle itself optimize internal for all the different variants
that it supports....

At work, we use Oracle extensively, and I sat down one day last year with
our Oracle DBA to discuss exactly this...and, if I recall correctly, it
was prompted by a similar thread here...

If Linux is providing an Interface into the RAW file system, then this may
change things for Oracle, since it wouldn't have to "learn" all the
different OSs, as long as the API is the same across them all...and, my
experience with Linux is that the API for Linux will most likely be
different then everyone else *roll eyes*

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

From bouncefilter Mon Dec 6 11:48: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 LAA52907
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 11:47:57 -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 LAA18863
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 11:47:22 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Binary-compatible type follies
Date: Mon, 06 Dec 1999 11:47:21 -0500
Message-ID: <18860.944498841@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

This example forwarded from pgsql-sql:

create table x (a char(20));
CREATE
create table y (b varchar(20));
CREATE
select * from x a, y b where a.a = b.b;
ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar'
You will have to retype this query using an explicit cast

OK so far, but:

select * from x a, y b where text(a.a) = text(b.b);
ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar'
You will have to retype this query using an explicit cast
select * from x a, y b where a.a::text = b.b::text;
ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar'
You will have to retype this query using an explicit cast

6.5.3 and current sources behave the same.

I believe this is an artifact of a misbehavior that I've noticed before:
when the parser decides that an explicit typecast or type conversion
function is a no-op (because of binary compatibility of the types
involved), it simply throws away the conversion in toto. Seems to me
that it should relabel the subexpression as having the result type of
the requested conversion. Otherwise, subsequent processing will use
operators appropriate to the original type not the converted type,
which presumably is exactly what the user didn't want.

Thomas, any comments on this?

regards, tom lane

From bouncefilter Mon Dec 6 11:59:59 1999
Received: from dcave.digsys.bg (root@dcave.digsys.bg [192.92.129.5])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA54514
for <pgsql-hackers@hub.org>; Mon, 6 Dec 1999 11:59:47 -0500 (EST)
(envelope-from daniel@dcave.digsys.bg)
Received: from dcave.digsys.bg (daniel@localhost.digsys.bg [127.0.0.1])
by dcave.digsys.bg (8.9.0/8.9.0) with ESMTP id SAA00547
for <pgsql-hackers@hub.org>; Mon, 6 Dec 1999 18:59:41 +0200 (EET)
Message-Id: <199912061659.SAA00547@dcave.digsys.bg>
X-Mailer: exmh version 2.0.2 2/24/98
From: Daniel Kalchev <daniel@digsys.bg>
To: pgsql-hackers@hub.org
Subject: memory problem again
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 06 Dec 1999 18:59:41 +0200
Sender: daniel@digsys.bg

Hello,

I have this problem with PostgreSQL 6.5.2:

table timelog199911 has

logs=> select count(*) from timelog199911;
count
------
208749
(1 row)

logs=> select distinct confid
logs-> from timelog199910
logs-> where
logs-> confid IS NOT NULL;
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.

The logged message in stderr (of postmaster) is

FATAL 1: Memory exhausted in AllocSetAlloc()

The process size grows to 76 MB (this is somehow a limit of Postgres on
BSD/OS, but this is not my question now).

Why would it require so much memory? The same query without distinct is
processed fast, but I don't need that much data back in the application.
The format is:

Table    = timelog
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| loginname                        | text                             |   var |
| site                             | varchar()                        |    16 |
| start_time                       | datetime                         |     8 |
| elapsed                          | timespan                         |    12 |
| port                             | text                             |   var |
| valid                            | bool default 't'                 |     1 |
| ipaddress                        | inet                             |   var |
| confid                           | int4                             |     4 |
| session_id                       | text                             |   var |
+----------------------------------+----------------------------------+-------+
Indices:  timelog_loginname_idx
          timelog_start_time_idx

(indexes are btree on the indicate fields).

Weird, isn't it?

Daniel

From bouncefilter Mon Dec 6 12:25:59 1999
Received: from oxmail.ox.ac.uk (oxmail1.ox.ac.uk [129.67.1.1])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA58138
for <pgsql-hackers@postgresql.org>; Mon, 6 Dec 1999 12:25:33 -0500 (EST)
(envelope-from mbeattie@sable.ox.ac.uk)
Received: from sable.ox.ac.uk ([163.1.2.4])
by oxmail.ox.ac.uk with esmtp (Exim 2.10 #1)
id 11v1tC-0003bu-00; Mon, 6 Dec 1999 17:25:30 +0000
Received: from mbeattie by sable.ox.ac.uk with local (Exim 2.12 #1)
id 11v1tB-00056M-00; Mon, 6 Dec 1999 17:25:29 +0000
Subject: Re: [HACKERS] RAW I/O device
In-Reply-To: <Pine.BSF.4.21.9912061041290.18029-100000@thelab.hub.org> from
The Hermit Hacker at "Dec 6, 1999 10:44:55 am"
To: scrappy@hub.org (The Hermit Hacker)
Date: Mon, 6 Dec 1999 17:25:29 +0000 (GMT)
From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Cc: pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <E11v1tB-00056M-00@sable.ox.ac.uk>

The Hermit Hacker writes:

If Linux is providing an Interface into the RAW file system, then this may
change things for Oracle, since it wouldn't have to "learn" all the
different OSs, as long as the API is the same across them all...and, my
experience with Linux is that the API for Linux will most likely be
different then everyone else *roll eyes*

The system admin side is slightly different from others: raw devices
have their own major number and devices, /dev/rawN and you "bind" a
raw device to any existing block device /dev/blockdev by doing
# raw /dev/rawN /dev/blockdev

However, the DBA side (or software) side isn't any different: provided
you access /dev/rawN *only* in sector chunks (i.e. multiples of 512
bytes that are 512-byte aligned) then the software doesn't care
whether it's /dev/rawN or an ordinary block device. If PostgreSQL can
guarantee (or be tweaked/enhanced to guarantee) that it only ever
reads/writes in multiples of 512 byte chunks and never does anything
"weird" (truncates, file-specific, ioctls, mmap, needing O_CREAT to
start with etc.) then it should be perfectly happy when presented with
a /dev/rawN instead of an ordinary file.

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

From bouncefilter Mon Dec 6 13:29: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 NAA69467
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 13:28:00 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11v2k6-0003kGC; Mon, 6 Dec 99 19:20 MET
Message-Id: <m11v2k6-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: FOREIGN KEY and shift/reduce
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Mon, 6 Dec 1999 19:20:10 +0100 (MET)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Hi,

I just committed a patch that turns on FOREIGN KEY. Thus,
REFERENCES used in CREATE TABLE now automatically creates the
appropriate constraint triggers. The implementation also
supports omitting the PK column definition, if the
corresponding columns should be the PRIMARY KEY of the
referenced table.

Also I completed some more of the generic trigger procs. For
MATCH FULL, the key existence check in PK table and these
actions are completed:

ON DELETE RESTRICT
ON DELETE CASCADE
ON UPDATE RESTRICT
ON UPDATE CASCADE

Still missing are the SET NULL and SET DEFAULT actions. The
former is easy and will follow soon, the latter looks tricky
if the implementation should support ALTER TABLE/DEFAULT
(what it IMHO must even if that ALTER TABLE isn't implemented
yet).

Anyway, I ran into some shift/reduce problem in the main
parser. The syntax according to SQL3 says

<constraint attributes> ::=
<constraint check time> [ [ NOT ] DEFERRABLE ]
| [ NOT ] DEFERRABLE [ <constraint check time> ]

<constraint check time> defines INITIALLY DEFERRED/IMMEDIATE
and defaults to IMMEDIATE.

If I allow the <constraint attributes> in column constraints,
I get 2 shift/reduce conflicts. Seems the syntax interferes
with NOT NULL. Actually I commented that part out, so the
complete syntax is available only for table constraints, not
on the column level.

Could some yacc-guru please take a look at it?

Another interesting question is about inheritance. If a
REFERENCES constraint exists for a table, must another table,
inheriting this one, also get all the FK checks applied?

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 Dec 6 14:27: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 OAA77451
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 14:26:46 -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 LAA23064
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 11:26:38 -0800 (PST)
Message-Id: <3.0.1.32.19991206112443.0100d9e0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 06 Dec 1999 11:24:43 -0800
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
From: Don Baccus <dhogaza@pacifier.com>
Subject: A view just stopped working out of the blue...
In-Reply-To: <m11v2k6-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

I have the following table and view:

create table users (
user_id integer not null primary key,
first_names varchar(50) not null,
last_name varchar(50) not null,
password varchar(30) not null,
email varchar(50) not null unique,

census_rights_p boolean default 'f',
locale_rights_p boolean default 'f',
admin_rights_p boolean default 'f',

-- to suppress email alerts
on_vacation_until date,

-- set when user reappears at site
last_visit datetime,
-- this is what most pages query against (since the above column
-- will only be a few minutes old for most pages in a session)
second_to_last_visit datetime,

registration_date date,
registration_ip varchar(50),
user_state varchar(100) check(user_state is null or
user_state in ('need_email_verification_and_admin_approv', 'n
eed_admin_approv', 'need_email_verification', 'rejected', 'authorized',
'banned', 'deleted')
),
deleted_p boolean default 'f',
banned_p boolean default 'f',
-- who and why this person was banned
banning_user integer,
banning_note varchar(4000),
portrait_loaded boolean default 'f',
portrait_type varchar(10) default ''
);

-- Create an "alert table" view of just those users who should
-- be sent e-mail alerts.

create view users_alertable
as
select *
from users
where (on_vacation_until is null or
on_vacation_until < 'now'::date)
and (deleted_p = 'f');

This has been working for months, just fine. I've been porting over a bunch
more stuff from Oracle to this Postgres-based system, and bam! Now any
select from the view dies with:

unknown node tag 600 in apply_RIR_view

I've tried dropping and rebuilding the table and view in a test database
and the problem remains. I recall running into problems with other
operations many moons ago, where a particular node type wasn't being
handled by a particular operator (the ones I'd seen previously were
fixed by the excellent 6.5.* versions).

Is this a similar case? I may do a little digging myself tonight, but
thought I'd ask to see if this rings a bell with anyone. It's a bit
strange because this view's been working great on this table for so
long. I added a couple of extra columns to the table recently but
the view worked immediately afterwards. The stuff I've been porting
creates views willy-nilly and it's almost like there's an interaction
taking place, but that doesn't seem right.

It fails in the same manner if I simply declare the view as:

create view users_alertable as select * from users;

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

From bouncefilter Mon Dec 6 14:43:01 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 OAA79511
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 14:42:42 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11v3tv-0003kGC; Mon, 6 Dec 99 20:34 MET
Message-Id: <m11v3tv-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] A view just stopped working out of the blue...
To: dhogaza@pacifier.com (Don Baccus)
Date: Mon, 6 Dec 1999 20:34:23 +0100 (MET)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <3.0.1.32.19991206112443.0100d9e0@mail.pacifier.com> from "Don
Baccus" at Dec 6, 99 11:24:43 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Don Baccus wrote:

This has been working for months, just fine. I've been porting over a bunch
more stuff from Oracle to this Postgres-based system, and bam! Now any
select from the view dies with:

unknown node tag 600 in apply_RIR_view

Node tag 600 is T_Query.

I've tried dropping and rebuilding the table and view in a test database
and the problem remains. I recall running into problems with other
operations many moons ago, where a particular node type wasn't being
handled by a particular operator (the ones I'd seen previously were
fixed by the excellent 6.5.* versions).

Is this a similar case? I may do a little digging myself tonight, but
thought I'd ask to see if this rings a bell with anyone. It's a bit
strange because this view's been working great on this table for so
long. I added a couple of extra columns to the table recently but
the view worked immediately afterwards. The stuff I've been porting
creates views willy-nilly and it's almost like there's an interaction
taking place, but that doesn't seem right.

It fails in the same manner if I simply declare the view as:

create view users_alertable as select * from users;

I assume the column with the IN constraint is either new or
changed recently. Seems the system generates some subselect
for that and the rewriter is unable to handle this case.

I don't have the time to tackle that, just some hint to push
you into the right direction.

Be careful if hacking inside the rewriter, it's a very
sensitive area!

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 Dec 6 14:52:01 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 OAA80806
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 14:51:48 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11v43D-0003kGC; Mon, 6 Dec 99 20:43 MET
Message-Id: <m11v43D-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: FOREIGN KEY again
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Mon, 6 Dec 1999 20:43:58 +0100 (MET)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Well,

ON DELETE/UPDATE SET NULL is also in place.

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 Dec 6 15:22:09 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 PAA86383
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 15:22:02 -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 MAA13200
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 12:21:54 -0800 (PST)
Message-Id: <3.0.1.32.19991206115210.0100cd00@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 06 Dec 1999 11:52:10 -0800
To: pgsql-hackers@postgreSQL.org
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: view dying out of the blue...
In-Reply-To: <Pine.BSF.4.21.9912061041290.18029-100000@thelab.hub.org>
References: <384BB96F.AB25511A@fonet.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Sorry for the previous note...I'd tried stopping and restarting
postmaster and that didn't help, so I posted - this web site
gets low but steady use and was suddenly acting weird on me.

Anyway, a quick look at the source made it clear that Postgres
wasn't at fault, as the node's a T_Query and apply_RIR_view
clearly handles it.

So, I rebooted linux and it works fine now.

Sorry to bother folks...

- 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 Dec 6 15:13:09 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA84876
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 15:12:18 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <XTGA09Q2>; Mon, 6 Dec 1999 22:10:06 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C319@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'pgsql-hackers@postgreSQL.org '" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] RAW I/O device
Date: Mon, 6 Dec 1999 22:05:54 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"

Besides, there is a good reason why Oracle introduced this into their
product, and I don't think it was for server-based dbs. I think that Oracle
introduced it for embedded systems. This is the only reason that I can
think of for moving away from the file system. As we don't really cater for
embedded systems, I don't see any reason to do this. There is a lot of
stuff that the file system does for us that a raw device doesn't, which we
would then have to write :-(

MikeA

-----Original Message-----
From: The Hermit Hacker
To: Ing. Pavel PaJaSoft Janousek
Cc: merlin@scl.cwru.edu; pgsql-hackers@postgreSQL.org
Sent: 99/12/06 04:44
Subject: Re: [HACKERS] RAW I/O device

On Mon, 6 Dec 1999, Ing. Pavel PaJaSoft Janousek wrote:

other systems besides linux. Making the DB work w/ one FS (and

write the

storage code for it) seems pointless if we are still stuck on normal

FSs

on other machines.

Yes, of course, but storing databases directly to RAW device -

not

through the filesystem - is one feature of modern DB engines...

Actually, Oracle has been moving *away* from this...more recent versions
of Oracle recommend using the Operating System file systems, since, in
most cases, the Operating System does a better job, and its too
difficult
to have Oracle itself optimize internal for all the different variants
that it supports....

At work, we use Oracle extensively, and I sat down one day last year
with
our Oracle DBA to discuss exactly this...and, if I recall correctly, it
was prompted by a similar thread here...

If Linux is providing an Interface into the RAW file system, then this
may
change things for Oracle, since it wouldn't have to "learn" all the
different OSs, as long as the API is the same across them all...and, my
experience with Linux is that the API for Linux will most likely be
different then everyone else *roll eyes*

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

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

From bouncefilter Mon Dec 6 16:14:10 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 QAA93830
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 16:13:14 -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 VAA18779;
Mon, 6 Dec 1999 21:59:54 +0100
Date: Mon, 6 Dec 1999 21:59:54 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Jan Wieck <wieck@debis.com>
cc: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FOREIGN KEY and shift/reduce
In-Reply-To: <m11v2k6-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.LNX.3.96.991206214515.18632A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 6 Dec 1999, Jan Wieck wrote:

Hi,

Another interesting question is about inheritance. If a
REFERENCES constraint exists for a table, must another table,
inheriting this one, also get all the FK checks applied?

Hi,

This inspire me for next question: What is in PosgreSQL inherited?

IMHO is problem make inheriting FOREIGN KEY if not is support for UNIQUE
or PRIMARY KEYs inheriting. (Or is it in CVS tree?).

PostgreSQL 6.5.3:

test=> create table aaa (x int4 UNIQUE);
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'aaa_x_key' for
table 'aaa'
CREATE
test=> create table y () inherits (aaa);
CREATE
test=> insert into y values (1);
INSERT 590807 1
test=> insert into y values (1);
INSERT 590808 1

Karel

PS. I very look forward to a FOREIGN KEY, with this feature will
life easier and the PgSQL will more tread on the heels of non-GNU
engines.

From bouncefilter Mon Dec 6 16:35:10 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 QAA97098
for <hackers@postgresql.org>; Mon, 6 Dec 1999 16:35:08 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61834 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sH0k047153>; Mon, 6 Dec 1999 22:34:58 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11v5rX-0002LB-00
for hackers@postgresql.org; Mon, 06 Dec 1999 22:40:03 +0100
Date: Mon, 6 Dec 1999 22:40:03 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: Multibyte in autoconf
Message-ID: <Pine.LNX.4.20.9912061730530.8886-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

This belongs to the chapter "initdb weirdnesses", if you will. I have long
been confused about this, but now I think I have the answer. Could someone
from the multibyte camp please confirm this.

When I configure --with-mb=FOO, the only place FOO is actually used is in
initdb as the default encoding of the database system you are creating
(can be overriden with --pgencoding). The rest of the source code only
does occasional #ifdef MULTIBYTE checks. This sort of arrangement is
questionable for a number of reasons:

1) It's not very clear to the casual observer (=end user). I was lead to
believe that the database system you are compiling will only support the
FOO encoding and I used several --with-mb's if I wanted more.

2) It is very well possible that one initdb instance can be used to
install databases in several locations with varying encodings.

3) I might sound like a broken record, but autoconf is not for controlling
runtime behavior.

While the notion of having a default encoding is perhaps not so bad (but
how often do you do initdb?) it could be introduced via other mechanisms,
such as environment variables. (I am contradicting earlier emails now, but
I'm not sure of a good way myself, yet.) The current approach causes all
kinds of structural hazards in the overall view of things. I propose that
--with-mb be replaced by --enable-mb (how about --enable-multibyte?). This
is nothing urgent, but I would like to know what you think.

-Peter

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

From bouncefilter Mon Dec 6 16:57:10 1999
Received: from www.actarg.com (root@[209.180.91.25])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA00298
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 16:56:28 -0500 (EST)
(envelope-from kyle@actarg.com)
Received: from actarg.com (root@tao.actarg.com [192.168.1.1])
by www.actarg.com (8.8.7/8.8.7) with ESMTP id PAA27911;
Mon, 6 Dec 1999 15:01:08 -0700
Received: from actarg.com (kyle@chi.actarg.com [192.168.2.16])
by actarg.com (8.8.7/8.8.7) with ESMTP id OAA29282;
Mon, 6 Dec 1999 14:54:55 -0700
Sender: kyle@actarg.com
Message-ID: <384C314D.2CA442CE@actarg.com>
Date: Mon, 06 Dec 1999 14:57:33 -0700
From: Kyle Bateman <kyle@actarg.com>
Organization: Action Target Inc
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
References: <Pine.BSF.4.21.9912061454380.18029-100000@thelab.hub.org>
Content-Type: multipart/mixed; boundary="------------F5C7A192FD7413F9994FAAD3"

This is a multi-part message in MIME format.
--------------F5C7A192FD7413F9994FAAD3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The Hermit Hacker wrote:

Hi Kyle...

Jeff is currently in the process of redoing the web site, and
we're going to be working this 'bidding' system into the new site, but its
going to take a litlte bit of time, since he would like to get it right
and not have to do it again :)

Keep an eye on the sight and expect *a variant* on what you
proposed to be in place around the first of the new year...but it will be
implemented...

Sounds good. I hope my input will prove helpful.

BTW, you don't have to wait for the web site to be working right to get me involved
(although I think that might help others to get more involved).

If you're interested in getting some money to help out with development now, this is
the list of things I have been hoping for. I'm sure my modest contribution alone is
not enough to justify the work they will take, but its probably better than a kick in
the butt.

- Allow a view of a union
- Get rid of size restrictions on tuples (8K?)
- Get rid of size restrictions on queries (16K)
- Make sequences roll back on abort (at least optionally)
- Resident functions that can execute with super-privileges
This would mean that a PL function could execute as the user who created
it (or perhaps some other user the database creater might specify). This
would allow certain information to come from a table that the calling user
might not normally have access to (without having access to the whole table).
- Support for outer (and other kinds of) joins
- Column based permissions (I don't know if there are SQL standards for this)
- Support for passwords in the TCL interface (is it there now?)
- Could a subquery be included in the target list of a query
select a,(select b from c) from d where e = f;
(Not sure if this one is even standard SQL.)
- Support for "alter table drop column"

Maybe some of the things have been done already. Some have not. The items are
roughly prioritized for our needs here at ATI.

If I knew that certain of these could be accomplished and for how much, that would
really help me move forward.

--------------F5C7A192FD7413F9994FAAD3
Content-Type: text/x-vcard; charset=us-ascii;
name="kyle.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Kyle Bateman
Content-Disposition: attachment;
filename="kyle.vcf"

begin:vcard
n:Bateman;Kyle
tel;fax:801-377-8096
tel;work:801-377-8033x101
x-mozilla-html:FALSE
url:www.actiontarget.com
org:Action Target Inc
adr:;;PO Box 636;Provo;UT;84603;US
version:2.1
email;internet:kyle@actiontarget.com
title:President
x-mozilla-cpt:;-15520
fn:Kyle Bateman
end:vcard

--------------F5C7A192FD7413F9994FAAD3--

From bouncefilter Mon Dec 6 17:30:11 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 RAA04265
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 17:29:58 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id OAA26419;
Mon, 6 Dec 1999 14:29:47 -0800 (PST)
Message-Id: <3.0.1.32.19991206142750.00fff3f0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 06 Dec 1999 14:27:50 -0800
To: Kyle Bateman <kyle@actarg.com>, The Hermit Hacker <scrappy@hub.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] Raising funds for PostgreSQL
Cc: pgsql-hackers@postgreSQL.org
In-Reply-To: <384C314D.2CA442CE@actarg.com>
References: <Pine.BSF.4.21.9912061454380.18029-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:57 PM 12/6/99 -0700, Kyle Bateman wrote:

*> - Allow a view of a union
*> - Get rid of size restrictions on tuples (8K?)
*> - Get rid of size restrictions on queries (16K)

- Resident functions that can execute with super-privileges
This would mean that a PL function could execute as the user who created
it (or perhaps some other user the database creater might specify).

This

would allow certain information to come from a table that the calling

user

might not normally have access to (without having access to the whole

table).
*> - Support for outer (and other kinds of) joins

- Column based permissions (I don't know if there are SQL standards for

this)

- Support for passwords in the TCL interface (is it there now?)

*> - Could a subquery be included in the target list of a query

select a,(select b from c) from d where e = f;
(Not sure if this one is even standard SQL.)

*> - Support for "alter table drop column"

While I don't have any money to offer, I just thought I'd point out
that each of the starred items are things that I've run into while
porting an application from Oracle in just the past three days.

The system builds and allows the editing of tables via a web
interface, and not being able to drop columns is a drag. I'm
emulating it by renaming such columns to something invisible
(the user doesn't see the actual table, just what the application
thinks is in the table, so I just make it lie to the user after
the renaming), which for this particular application will be
acceptable for now.

Outer joins can be worked around, but at times it's painful,
though I'm finding that for this application at least at times
I can rewrite the query and make it more readable and efficient
without the outer join. Apparently, outer joins are a temptation
for misuse. But there are times when they're really helpful.

Allowing a view of a union can always be worked around in some
sort of brute-force manner but can require studying the
queries on it closely in order to properly rewrite them without
the view.

Tuple size restrictions coupled with the fact that LOBs aren't
dumped are also painful. If 7.0 contains a "real" backup, will
it be able to backup LOBs? That would help me in the port of
this application.

As the word gets out that Postgres has greatly improved in the
recent past, more and more folks will be looking to move stuff
over from commercial databases. This is partly driven by the
web (entirely, in my case) where databases are extremely
useful creatures, serving as the site's foundation in many
cases. Oracle's pricing for web use is scandalous ($22K-ish
for a fully-paid up unsupported license on a PIII 500!) and
besides is overkill for all but the largest and busiest sites.
Postgres can fill a very important niche in this environment.
One that some folks think MySQL fills but, hey, I ain't trusting
any money transactions to a non-transactional database!

The focus on things like reliability and performance is
extremely important, of course - MVCC in 6.5.*, a very
noticable decline in memory leaks ("drastic" is not too
strong a word), removing the uneccessary write to pg_log
after read-only selects were crucial for my own web-based
application. WAL and a good backup facility are really
nice to think about for those of us who worry about our
hardware's reliability, and referential integrity constraints
for those of us who worry about our ability to write
bug-free code (I can't wait to play with Jan's new updates),
all very good things.

But Postgres is maturing to the point where users can point
to the reliability and performance aspects of the tool and
find little to complain about. Now folks are going to start
concentrating on SQL language features more exclusively :)

- 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 Dec 6 18:01:11 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 SAA08112
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 18:00:40 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id RAA05675
for pgsql-hackers@postgreSQL.org; Mon, 6 Dec 1999 17:58:35 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912062258.RAA05675@candle.pha.pa.us>
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <199912061335.IAA18633@candle.pha.pa.us> from Bruce Momjian at
"Dec 6, 1999 08:35:27 am"
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 6 Dec 1999 17:58:35 -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 am concerned about a May release. That puts us at almost a year from
the last major release in mid-June. That is too long. Seems like we
should have some release around February.

Let's list the 7.0 items:

Foreign Keys - Jan
WAL - Vadim
Function args - Tom
System indexes - Bruce
Date/Time types - Thomas
Optimizer - Tom

Outer Joins - Thomas?
Long Tuples - ?

None of these are done, except for the system indexes, and that is a
small item. It seems everyone wants a grand 7.0, but that is months
away.

I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We
certainly have enough for a 6.6 release.

I recommend this so the 6.5.* enhancements are accessible to users now,
rather than waiting another severel months while we add the above fancy
features.

Also, I have never been a big fan of huge, fancy releases because they
take too long to become stable. Better for us to release what we have
now and work out those kinks.

-- 
  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 Dec 6 18:27:11 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA10938
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 18:26:52 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id TAA53584;
Mon, 6 Dec 1999 19:21:13 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 6 Dec 1999 19:21:12 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <199912062258.RAA05675@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.9912061920260.18029-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

What do we have now for a v6.6? I'm not against, just wondering if we
have enough to warrant a v6.6, that's all...

On Mon, 6 Dec 1999, Bruce Momjian wrote:

I am concerned about a May release. That puts us at almost a year from
the last major release in mid-June. That is too long. Seems like we
should have some release around February.

Let's list the 7.0 items:

Foreign Keys - Jan
WAL - Vadim
Function args - Tom
System indexes - Bruce
Date/Time types - Thomas
Optimizer - Tom

Outer Joins - Thomas?
Long Tuples - ?

None of these are done, except for the system indexes, and that is a
small item. It seems everyone wants a grand 7.0, but that is months
away.

I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We
certainly have enough for a 6.6 release.

I recommend this so the 6.5.* enhancements are accessible to users now,
rather than waiting another severel months while we add the above fancy
features.

Also, I have never been a big fan of huge, fancy releases because they
take too long to become stable. Better for us to release what we have
now and work out those kinks.

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

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

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

From bouncefilter Mon Dec 6 18:56:12 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id SAA14220
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 18:55:15 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11v7qW-0003kGC; Tue, 7 Dec 99 00:47 MET
Message-Id: <m11v7qW-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] When is 7.0 going Beta?
To: pgman@candle.pha.pa.us (Bruce Momjian)
Date: Tue, 7 Dec 1999 00:47:08 +0100 (MET)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199912062258.RAA05675@candle.pha.pa.us> from "Bruce Momjian" at
Dec 6, 99 05:58:35 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

I am concerned about a May release. That puts us at almost a year from
the last major release in mid-June. That is too long. Seems like we
should have some release around February.

Let's list the 7.0 items:
[...]
None of these are done, except for the system indexes, and that is a
small item. It seems everyone wants a grand 7.0, but that is months
away.

I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We
certainly have enough for a 6.6 release.

#define READ_BETWEEN_LINES true

THAT'S MY CHANCE :-)

Let's not call it 6.6, instead it should read 6.6.6 - the
BEASTS release. That number could probably make serious
database users/admins look somewhat more careful at the
release notes.

Also, I have never been a big fan of huge, fancy releases because they
take too long to become stable. Better for us to release what we have
now and work out those kinks.

#define READ_BETWEEN_LINES false

With all the PARTIALLY developed and COMMITTED fancy 7.0
features inside, do you really think that release would be
easy to get stable? I fear the partial features we already
have inside lead to a substantial increase in mailing list
traffic.

As far as I've read the responses, the users community called
6.5 one of the best releases ever made. Many nice, new
features and an outstanding quality WRT reliability and
performance. Never underestimate the users community hearsay
in open source - don't play with our reputation!

If we really go for a 6.6 release, we need to branch off from
the 6.5 tree and backpatch things we want to have in 6.6 into
there. Releasing some snapshot of the current 7.0 tree as 6.6
IMHO is a risk we cannot estimate.

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 Dec 6 20:12:14 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA22489
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 20:11:56 -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 UAA20432;
Mon, 6 Dec 1999 20:10:09 -0500 (EST)
To: wieck@debis.com (Jan Wieck)
cc: pgman@candle.pha.pa.us (Bruce Momjian), pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-reply-to: Your message of Tue, 7 Dec 1999 00:47:08 +0100 (MET)
<m11v7qW-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Date: Mon, 06 Dec 1999 20:10:09 -0500
Message-ID: <20430.944529009@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

If we really go for a 6.6 release, we need to branch off from
the 6.5 tree and backpatch things we want to have in 6.6 into
there. Releasing some snapshot of the current 7.0 tree as 6.6
IMHO is a risk we cannot estimate.

I agree with Jan that we can't just fire something out the door based
on current sources. There are enough poorly-tested or half-done
changes in there that we'd need a long beta cycle to have much
confidence in it. I think this would drain an unreasonable amount of
developer time that would be better spent on finishing the half-done
stuff ... and *then* starting a long beta cycle ;-).

We are at a midflight point now. We don't have enough stuff done to
put out a 7.0, but neither are we close enough to the last release
to put out something that would fairly be called 6.6. I think users
would expect a "6.6" to offer small improvements featurewise and
continue in the trend of improving stability/performance. I'm not
sure I could promise that a 6.6 would be more stable than 6.5. At
least not without that long beta cycle.

We can continue to make 6.5.* releases if any critical problems come up,
but that again is a drain on developer time, so I'm not enthused about
making 6.5.* releases unless necessary.

In short, I'd rather continue on the present course and not be overly
concerned about how long it takes to get it right. Schedule-driven
decisions are usually wrong decisions, in my experience.

regards, tom lane

From bouncefilter Mon Dec 6 20:13:12 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 UAA22525
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 20:12:20 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA20486;
Tue, 7 Dec 1999 10:12:18 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA08266;
Tue, 7 Dec 1999 10:12:17 +0900
To: peter_e@gmx.net, e99re41@DoCS.UU.SE
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_ctl
In-Reply-To: Your message of "Mon, 6 Dec 1999 12:56:31 +0100 (MET)"
<Pine.GSO.4.02A.9912061251380.1828-100000@Panter.DoCS.UU.SE>
References: <Pine.GSO.4.02A.9912061251380.1828-100000@Panter.DoCS.UU.SE>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991207101217Y.t-ishii@sra.co.jp>
Date: Tue, 07 Dec 1999 10:12:17 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 10

May I issue a complaint? The use of the configure time generated BINDIR
for finding binaries at run time is not only an explicitly discouraged
abuse of the whole autoconf concept, it might potentially lead to big
problems when packages are built in temporary trees. I'm currently working
on a portable "which" alternative. When I get it done, I'll suggest that
one to you.

Ok. let me know if you finish the work.
--
Tatsuo Ishii

From bouncefilter Mon Dec 6 20:19:12 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA23430
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 20:18:25 -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 UAA20486;
Mon, 6 Dec 1999 20:17:15 -0500 (EST)
To: Kyle Bateman <kyle@actarg.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
In-reply-to: Your message of Mon, 06 Dec 1999 14:57:33 -0700
<384C314D.2CA442CE@actarg.com>
Date: Mon, 06 Dec 1999 20:17:15 -0500
Message-ID: <20484.944529435@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Kyle Bateman <kyle@actarg.com> writes:

[ wish list ]
- Get rid of size restrictions on queries (16K)
- Could a subquery be included in the target list of a query
select a,(select b from c) from d where e = f;
(Not sure if this one is even standard SQL.)

FWIW, the above two things are already done in current sources.

regards, tom lane

From bouncefilter Mon Dec 6 20:09:12 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 UAA22067
for <hackers@postgreSQL.org>; Mon, 6 Dec 1999 20:08:33 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA20184;
Tue, 7 Dec 1999 10:08:27 +0900 (JST)
Received: from localhost (IDENT:t-ishii@srapc968-yotsuya [133.137.36.133])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA08125;
Tue, 7 Dec 1999 10:08:26 +0900
To: peter_e@gmx.net
Cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Multibyte in autoconf
In-Reply-To: <Pine.LNX.4.20.9912061730530.8886-100000@localhost.localdomain>
References: <Pine.LNX.4.20.9912061730530.8886-100000@localhost.localdomain>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991207102941N.t-ishii@sra.co.jp>
Date: Tue, 07 Dec 1999 10:29:41 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 44

This belongs to the chapter "initdb weirdnesses", if you will. I have long
been confused about this, but now I think I have the answer. Could someone
from the multibyte camp please confirm this.

When I configure --with-mb=FOO, the only place FOO is actually used is in
initdb as the default encoding of the database system you are creating
(can be overriden with --pgencoding). The rest of the source code only
does occasional #ifdef MULTIBYTE checks. This sort of arrangement is
questionable for a number of reasons:

1) It's not very clear to the casual observer (=end user). I was lead to
believe that the database system you are compiling will only support the
FOO encoding and I used several --with-mb's if I wanted more.

Have you ever read doc/README.mb?

2) It is very well possible that one initdb instance can be used to
install databases in several locations with varying encodings.

You can initialize database with specified default encoding by initdb -
e or -pgencoding. What's the problem with this?

3) I might sound like a broken record, but autoconf is not for controlling
runtime behavior.

While the notion of having a default encoding is perhaps not so bad (but
how often do you do initdb?) it could be introduced via other mechanisms,
such as environment variables. (I am contradicting earlier emails now, but
I'm not sure of a good way myself, yet.) The current approach causes all
kinds of structural hazards in the overall view of things. I propose that
--with-mb be replaced by --enable-mb (how about --enable-multibyte?). This
is nothing urgent, but I would like to know what you think.

I don't understabd why you do not complain about --with-pgport or --
with-maxbackends. Sounds they have same problems as mb:-)

Anyway, I don't like the idea to have an yet another environment
variable to give a default encoding to initdb when -e or -pgencoding
is not specified. We already have enough. Changing --with-mb to --
enable-multibyte seems good but I don't know how to give the default
encoding to initdb in this case. Or just changing --with-mb=FOO to --
enable-multibyte=FOO is what you want?
--
Tatsuo Ishii

From bouncefilter Mon Dec 6 20:55:13 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA30363
for <pgsql-hackers@hub.org>; Mon, 6 Dec 1999 20:54: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 UAA20749;
Mon, 6 Dec 1999 20:53:26 -0500 (EST)
To: Daniel Kalchev <daniel@digsys.bg>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] memory problem again
In-reply-to: Your message of Mon, 06 Dec 1999 18:59:41 +0200
<199912061659.SAA00547@dcave.digsys.bg>
Date: Mon, 06 Dec 1999 20:53:26 -0500
Message-ID: <20747.944531606@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Daniel Kalchev <daniel@digsys.bg> writes:

I have this problem with PostgreSQL 6.5.2:

logs=> select distinct confid
logs-> from timelog199910
logs-> where
logs-> confid IS NOT NULL;
pqReadData() -- backend closed the channel unexpectedly.

The logged message in stderr (of postmaster) is
FATAL 1: Memory exhausted in AllocSetAlloc()

Odd. I can't replicate this here. (I'm using 6.5.3, but I doubt that
matters.) There must be some factor involved that you haven't told us.
You don't have any triggers or rules on the table, do you?

Has anyone else seen anything like this?

regards, tom lane

From bouncefilter Mon Dec 6 21:00:13 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA31127
for <pgsql-hackers@postgresql.org>; Mon, 6 Dec 1999 20:59:25 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA54710;
Mon, 6 Dec 1999 21:57:49 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 6 Dec 1999 21:57:39 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Jan Wieck <wieck@debis.com>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <m11v7qW-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.BSF.4.21.9912062154180.823-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I personally agree with Jan on this...I think most users have found that
our releases have been "worth the wait", and altho we're askign them to
wait a little bit longer then normal, we *are* addressing problems with he
current release by putting out 6.5.x's as required, *and* we are highly
visible.

unlike some projects out there (gcc's "past" coming to mind), we have a
highly active mailing list where developers are constantly putting out,
and discussing, news ideas...the end user sees this, and with what is on
the todo list, 7.0 will be *more* worth the wait then our past
releases...7.0 is looking to be our *biggest* release yet, a little more
time will be required on this one...

On Tue, 7 Dec 1999, Jan Wieck wrote:

Bruce Momjian wrote:

I am concerned about a May release. That puts us at almost a year from
the last major release in mid-June. That is too long. Seems like we
should have some release around February.

Let's list the 7.0 items:
[...]
None of these are done, except for the system indexes, and that is a
small item. It seems everyone wants a grand 7.0, but that is months
away.

I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We
certainly have enough for a 6.6 release.

#define READ_BETWEEN_LINES true

THAT'S MY CHANCE :-)

Let's not call it 6.6, instead it should read 6.6.6 - the
BEASTS release. That number could probably make serious
database users/admins look somewhat more careful at the
release notes.

Also, I have never been a big fan of huge, fancy releases because they
take too long to become stable. Better for us to release what we have
now and work out those kinks.

#define READ_BETWEEN_LINES false

With all the PARTIALLY developed and COMMITTED fancy 7.0
features inside, do you really think that release would be
easy to get stable? I fear the partial features we already
have inside lead to a substantial increase in mailing list
traffic.

As far as I've read the responses, the users community called
6.5 one of the best releases ever made. Many nice, new
features and an outstanding quality WRT reliability and
performance. Never underestimate the users community hearsay
in open source - don't play with our reputation!

If we really go for a 6.6 release, we need to branch off from
the 6.5 tree and backpatch things we want to have in 6.6 into
there. Releasing some snapshot of the current 7.0 tree as 6.6
IMHO is a risk we cannot estimate.

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

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

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

From bouncefilter Mon Dec 6 21:20:13 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 VAA34995
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 21:20:07 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11vA6x-0003kGC; Tue, 7 Dec 99 03:12 MET
Message-Id: <m11vA6x-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Raising funds for PostgreSQL
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Tue, 7 Dec 1999 03:12:15 +0100 (MET)
Cc: kyle@actarg.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <20484.944529435@sss.pgh.pa.us> from "Tom Lane" at Dec 6,
99 08:17:15 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Tom Lane wrote:

Kyle Bateman <kyle@actarg.com> writes:

[ wish list ]
- Get rid of size restrictions on queries (16K)
- Could a subquery be included in the target list of a query
select a,(select b from c) from d where e = f;
(Not sure if this one is even standard SQL.)

FWIW, the above two things are already done in current sources.

Uh,

who did the latter one?

Just running some qry through psql I see that it works
partially. Especially I see a

ExecSetParamPlan: more than one tuple returned by expression subselect

So I assume it's not implemented in the form I outlined - the
subselecting range table entry. I'll take a look at it the
next days and maybe complain about that change if it
interferes with the needs of the rule system to make
aggregate, distinct, group by, sort by and all the other
(long wanted) view stuff possible.

Jan

--

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

From bouncefilter Mon Dec 6 21:14:15 1999
Received: from mecomb.com (gw.mecomb.com [161.142.249.98])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA33654;
Mon, 6 Dec 1999 21:13:37 -0500 (EST)
(envelope-from lylyeoh@mecomb.com)
Received: (from mail@localhost) by mecomb.com (8.8.7/8.8.7) id KAA25290;
Tue, 7 Dec 1999 10:13:28 +0800
Received: from <lylyeoh@mecomb.com> (ilab2.mecomb.po.my [192.168.3.22]) by
ns.mecomb.com via smap (V2.1)
id xma025284; Tue, 7 Dec 99 10:13:00 +0800
Message-Id: <3.0.5.32.19991207101333.00900430@pop.mecomb.po.my>
X-Sender: lylyeoh@pop.mecomb.po.my
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Tue, 07 Dec 1999 10:13:33 +0800
To: The Hermit Hacker <scrappy@hub.org>, pgsql-general@postgreSQL.org
From: Lincoln Yeoh <lylyeoh@mecomb.com>
Subject: Re: [GENERAL] Oft Ask: How to contribute to PostgreSQL?
Cc: jeff@pgsql.com, pgsql-hackers@postgreSQL.org
In-Reply-To: <Pine.BSF.4.21.9912052011040.823-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 08:56 PM 05-12-1999 -0400, The Hermit Hacker wrote:

pages off of http://www.pgsql.com that will provide a cleaner means of
contribute financially towards having features implemented, as well as

How about a website where the public can stick in their credit card number
and donate directly to
1) Postgres Inc/Org (which then could pay out "salaries")
2) A particular Postgres project (if necessary).
3) A particular developer (if it won't be detrimental to team spirit).

And everyone knows how much is going where- logs of total donations,
donations per month, per project etc.

Developers could even donate to each other if they feel that someone is not
being compensated enough for whatever reason (not enough visibility).

Could also have a Thank you page for things like "Keep up the good work",
"Mucho gracias!", etc (criticism and bug reports should be kept to mailing
lists).

I suggested something like this to GNU org some time back, dunno if they
like it at all. Open Destination Donation for Open Source Software.

The main problem is getting the money into bank accounts. But I figure
Postgres Inc could accept the donations, handle the financial details (card
problems etc), and then distribute money/thanks to the projects/developers
accordingly, via cheques, money orders or whatever.

Good idea?

Link.

From bouncefilter Mon Dec 6 21:26:13 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA36031
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 21:25:20 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA54936;
Mon, 6 Dec 1999 22:25:32 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 6 Dec 1999 22:25:30 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Kyle Bateman <kyle@actarg.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
In-Reply-To: <384C314D.2CA442CE@actarg.com>
Message-ID: <Pine.BSF.4.21.9912062224510.823-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Here...

http://www.pgsql.com/features/

Have to get it format'd and need to build up the CGI, but this is what you
asking for? :)

On Mon, 6 Dec 1999, Kyle Bateman wrote:

The Hermit Hacker wrote:

Hi Kyle...

Jeff is currently in the process of redoing the web site, and
we're going to be working this 'bidding' system into the new site, but its
going to take a litlte bit of time, since he would like to get it right
and not have to do it again :)

Keep an eye on the sight and expect *a variant* on what you
proposed to be in place around the first of the new year...but it will be
implemented...

Sounds good. I hope my input will prove helpful.

BTW, you don't have to wait for the web site to be working right to get me involved
(although I think that might help others to get more involved).

If you're interested in getting some money to help out with development now, this is
the list of things I have been hoping for. I'm sure my modest contribution alone is
not enough to justify the work they will take, but its probably better than a kick in
the butt.

- Allow a view of a union
- Get rid of size restrictions on tuples (8K?)
- Get rid of size restrictions on queries (16K)
- Make sequences roll back on abort (at least optionally)
- Resident functions that can execute with super-privileges
This would mean that a PL function could execute as the user who created
it (or perhaps some other user the database creater might specify). This
would allow certain information to come from a table that the calling user
might not normally have access to (without having access to the whole table).
- Support for outer (and other kinds of) joins
- Column based permissions (I don't know if there are SQL standards for this)
- Support for passwords in the TCL interface (is it there now?)
- Could a subquery be included in the target list of a query
select a,(select b from c) from d where e = f;
(Not sure if this one is even standard SQL.)
- Support for "alter table drop column"

Maybe some of the things have been done already. Some have not. The items are
roughly prioritized for our needs here at ATI.

If I knew that certain of these could be accomplished and for how much, that would
really help me move forward.

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

From bouncefilter Mon Dec 6 22:01:18 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA40633
for <pgsql-hackers@postgresql.org>; Mon, 6 Dec 1999 22:01:04 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA15475;
Mon, 6 Dec 1999 22:00:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912070300.WAA15475@candle.pha.pa.us>
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <Pine.BSF.4.21.9912062154180.823-100000@thelab.hub.org> from The
Hermit Hacker at "Dec 6, 1999 09:57:39 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 6 Dec 1999 22:00:26 -0500 (EST)
CC: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I personally agree with Jan on this...I think most users have found that
our releases have been "worth the wait", and altho we're askign them to
wait a little bit longer then normal, we *are* addressing problems with he
current release by putting out 6.5.x's as required, *and* we are highly
visible.

unlike some projects out there (gcc's "past" coming to mind), we have a
highly active mailing list where developers are constantly putting out,
and discussing, news ideas...the end user sees this, and with what is on
the todo list, 7.0 will be *more* worth the wait then our past
releases...7.0 is looking to be our *biggest* release yet, a little more
time will be required on this one...

OK, seeing as everyone disagrees with me...

Other than WAL, what else is half-completed and installed?

Foreign Keys - Jan
WAL - Vadim
Function args - Tom
Date/Time types - Thomas
Optimizer - Tom

Outer Joins - Thomas?
Long Tuples - ?

I guess I am wondering, other than WAL, what makes our current state
any worse than the time before previous beta cycles

I am very hesitant about our "one big release" thing coming? If we wait
for everything to get done, we would never have a release.

The more items in a release, the longer the beta cycle. If you wait too
long, you are fixing code you wrote 6 months ago, and that makes it very
hard. Smaller releases where the code is relatively fresh and the
additional features minimal are cleaner, faster betas.

The concern about a release sapping our energy when we should be adding
code is valid, but this delays how soon users can use the items we
_have_ finished.

Our 6.5.* subreleases are actually allowing us to take longer between
releases because we don't have to fix that _major_ bug a new release.
We fix it in the subrelease.

Obviously, no one agrees with me, so it looks like May.

-- 
  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 Dec 6 22:06:14 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA41459
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 22:05:17 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA15564;
Mon, 6 Dec 1999 22:02:19 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912070302.WAA15564@candle.pha.pa.us>
Subject: Re: [HACKERS] Raising funds for PostgreSQL
In-Reply-To: <m11vA6x-0003kGC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Dec 7, 1999 03:12:15 am"
To: Jan Wieck <wieck@debis.com>
Date: Mon, 6 Dec 1999 22:02:19 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, kyle@actarg.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

Tom Lane wrote:

Kyle Bateman <kyle@actarg.com> writes:

[ wish list ]
- Get rid of size restrictions on queries (16K)
- Could a subquery be included in the target list of a query
select a,(select b from c) from d where e = f;
(Not sure if this one is even standard SQL.)

FWIW, the above two things are already done in current sources.

Uh,

who did the latter one?

Tom Lane.

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

From bouncefilter Mon Dec 6 22:13:14 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA42785;
Mon, 6 Dec 1999 22:12:48 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id XAA55304;
Mon, 6 Dec 1999 23:12:14 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 6 Dec 1999 23:12:08 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Lincoln Yeoh <lylyeoh@mecomb.com>
cc: pgsql-general@postgreSQL.org, jeff@pgsql.com, pgsql-hackers@postgreSQL.org
Subject: Re: [GENERAL] Oft Ask: How to contribute to PostgreSQL?
In-Reply-To: <3.0.5.32.19991207101333.00900430@pop.mecomb.po.my>
Message-ID: <Pine.BSF.4.21.9912062257040.18029-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I'm glad we are all thinking alike :)

1. don't like that one...that's what we do the support contracts,
consulting and database hosting for...and the merchandise. the
merchandise has the added benefit of providing advertising for the
project too, so everyone wins.

we are looking into expanding the product line also, currently talking
with our supplier on this...

IMHO, I'd rather have ppl sign up for support contracts and use them,
then just having "donations" flow in...its what we formed PostgreSQL,
Inc to do...

2. see http://www.pgsql.com/features ... its a start, we will expand on it
over the next few days, add a cgi backend, etc etc...

3. I feel that this one ties directly into 2...pick a feature taht that
developer has taken on according to the TODO list...

On Tue, 7 Dec 1999, Lincoln Yeoh wrote:

At 08:56 PM 05-12-1999 -0400, The Hermit Hacker wrote:

pages off of http://www.pgsql.com that will provide a cleaner means of
contribute financially towards having features implemented, as well as

How about a website where the public can stick in their credit card number
and donate directly to
1) Postgres Inc/Org (which then could pay out "salaries")
2) A particular Postgres project (if necessary).
3) A particular developer (if it won't be detrimental to team spirit).

And everyone knows how much is going where- logs of total donations,
donations per month, per project etc.

Developers could even donate to each other if they feel that someone is not
being compensated enough for whatever reason (not enough visibility).

Could also have a Thank you page for things like "Keep up the good work",
"Mucho gracias!", etc (criticism and bug reports should be kept to mailing
lists).

A comments page? Lincoln Yech <lylyech@mecomb.com> says this about
PostreSQL...? Doable, let me play with it...

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

From bouncefilter Mon Dec 6 22:24:14 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA44812
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 22:23:29 -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 WAA21579;
Mon, 6 Dec 1999 22:22:19 -0500 (EST)
To: wieck@debis.com (Jan Wieck)
cc: kyle@actarg.com, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
In-reply-to: Your message of Tue, 7 Dec 1999 03:12:15 +0100 (MET)
<m11vA6x-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Date: Mon, 06 Dec 1999 22:22:18 -0500
Message-ID: <21577.944536938@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

Tom Lane wrote:

- Could a subquery be included in the target list of a query
select a,(select b from c) from d where e = f;

[ is done ]

Uh,
who did the latter one?

Me.

Just running some qry through psql I see that it works
partially. Especially I see a
ExecSetParamPlan: more than one tuple returned by expression subselect

Yes. I allowed the existing kinds of subselect expressions in
targetlists (not only in qual clauses), and fixed things so that
a subselect yielding a single result can appear anywhere in an
expression, not only as the righthand-side argument of an operator.
Subselects yielding multiple rows are still valid only as the
righthand argument of an IN, quantified boolean operator
(such as = ANY or = ALL), or EXISTS. It's a perfectly straightforward
generalization (and simplification!) of what we already had.

So I assume it's not implemented in the form I outlined - the
subselecting range table entry. I'll take a look at it the
next days and maybe complain about that change if it
interferes with the needs of the rule system to make
aggregate, distinct, group by, sort by and all the other
(long wanted) view stuff possible.

I don't believe this has anything to do with subselects as range
table entries. That facility will be quite separate from subselects
in expressions, no?

regards, tom lane

From bouncefilter Mon Dec 6 22:25:14 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA44998
for <pgsql-hackers@postgresql.org>; Mon, 6 Dec 1999 22:24:52 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA19731;
Mon, 6 Dec 1999 22:24:24 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912070324.WAA19731@candle.pha.pa.us>
Subject: Re: [HACKERS] RAW I/O device
In-Reply-To: <Pine.LNX.3.96.991206133158.26995A-100000@ara.zf.jcu.cz> from
Karel Zak - Zakkr at "Dec 6, 1999 01:47:18 pm"
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
Date: Mon, 6 Dec 1999 22:24:24 -0500 (EST)
CC: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I raise the question, because the linux kernel opening with raw-device
new way for a faster and better database engine. I know (and agree)
that it not is priority for next year(s?). But it is interesting, and
is prabably good remember it during development, and not write (in future)
features which close this good way.

I would be very surprised to see any significant change in raw vs.
filesystem i/o on modern file systems, and I am sorry, but Linux ext2
does not count as modern.

-- 
  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 Dec 6 22:28:14 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA45652
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 22:27:33 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA19865;
Mon, 6 Dec 1999 22:27:22 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912070327.WAA19865@candle.pha.pa.us>
Subject: Re: Book - SQL Aggregates
In-Reply-To: <199912061438.PAA20165@enseeiht.enseeiht.fr> from Max Buvry at
"Dec 6, 1999 03:38:13 pm"
To: Max Buvry <Max.Buvry@enseeiht.fr>
Date: Mon, 6 Dec 1999 22:27:22 -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

%--
%--> Dear sir,
%-->
%--> Just one remark for your book :
%--> in your chapter "SQL Aggregates", it is interessant perhaps if you
%--> say if COUNT(DISTINCT ...) for example is supported.
%-->
%--> mb
%-->
%--
%--It isn't supported.
%--

Sorry, I just want to say "It is not supported" obviously. I think, it is
important to say it, because I search for my mistake a little bit before
finding the answer in the FAQ.

CC to hackers.

The best way to do that is to display a mess to the user when they try
COUNT(DISTINCT...). That makes it easy because they see it as soon as
they try it. No hunting around, but I am not sure how to do that in the
grammer because we don't find out about aggregates until later.

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

From bouncefilter Mon Dec 6 22:31:14 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA46336
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 22:30:19 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA19878;
Mon, 6 Dec 1999 22:28:49 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912070328.WAA19878@candle.pha.pa.us>
Subject: Re: [HACKERS] RAW I/O device
In-Reply-To: <Pine.BSF.4.21.9912061041290.18029-100000@thelab.hub.org> from
The
Hermit Hacker at "Dec 6, 1999 10:44:55 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 6 Dec 1999 22:28:49 -0500 (EST)
CC: "Ing. Pavel PaJaSoft Janousek" <pajasoft@fonet.cz>, merlin@scl.cwru.edu,
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, 6 Dec 1999, Ing. Pavel PaJaSoft Janousek wrote:

other systems besides linux. Making the DB work w/ one FS (and write the
storage code for it) seems pointless if we are still stuck on normal FSs
on other machines.

Yes, of course, but storing databases directly to RAW device - not
through the filesystem - is one feature of modern DB engines...

Actually, Oracle has been moving *away* from this...more recent versions
of Oracle recommend using the Operating System file systems, since, in
most cases, the Operating System does a better job, and its too difficult
to have Oracle itself optimize internal for all the different variants
that it supports....

Ding, ding, ding. Give that man a cigar.

-- 
  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 Dec 6 23:05: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 XAA51994
for <pgsql-hackers@postgresql.org>; Mon, 6 Dec 1999 23:04:30 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgresql.org
id m11vBjC-0003kJC; Tue, 7 Dec 99 04:55 MET
Message-Id: <m11vBjC-0003kJC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] When is 7.0 going Beta?
To: pgman@candle.pha.pa.us (Bruce Momjian)
Date: Tue, 7 Dec 1999 04:55:50 +0100 (MET)
Cc: scrappy@hub.org, wieck@debis.com, pgsql-hackers@postgresql.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199912070300.WAA15475@candle.pha.pa.us> from "Bruce Momjian" at
Dec 6, 99 10:00:26 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

OK, seeing as everyone disagrees with me...

BADDAY.MPG?

Wasn't that I completely disagreed. Just that in the actual
case, I don't think we can make another release out of the
current tree. And about that I'm not alone.

Other than WAL, what else is half-completed and installed?

Foreign Keys - Jan
WAL - Vadim
Function args - Tom
Date/Time types - Thomas
Optimizer - Tom

Outer Joins - Thomas?
Long Tuples - ?

I guess I am wondering, other than WAL, what makes our current state
any worse than the time before previous beta cycles

At least FK. Just found myself a bug that makes things ugly.
Forces CKECK lookup in PK table even if FK values didn't
change on trigger invocation - otherwise someone could cause
RI violation not recognized by deleting DEFAULT key values of
FK from PK table.

That's IMHO something so easily to trigger, that I expect
more bugs in the stuff.

Since FOREIGN KEY is a feature so many ppl asked for, I
expect many of them penetrating the lists if things go bad -
what's really possible for now. Thus, I wouldn't feel
comfortable if it goes out in this state.

I am very hesitant about our "one big release" thing coming? If we wait
for everything to get done, we would never have a release.

The more items in a release, the longer the beta cycle. If you wait too
long, you are fixing code you wrote 6 months ago, and that makes it very
hard. Smaller releases where the code is relatively fresh and the
additional features minimal are cleaner, faster betas.

Hmmm,

yes and no. Yes, the more items the longer beta. But no, the
longer beta the better the release.

The last release had the longest of all beta delays. And it
was the best of all releases. Maybe because while feature A
prevents release, another bug in feature H shows up while B-G
are silent, but after fixing H's bug F shout's "stop". Not
surprising - (real) programmers experience.

The worst thing we can do is to release FEATURES, that are
current development state and must be deprecated because they
interfere with ongoing development. I just saw that someone
added some kind of subselect inside or the targetlist - and I
absolutely don't know if that will stand the test of time
(i.e. issues WRT the rewriter MIGHT be more important). So
that syntax might need to be removed/changed in 7.0 or a
subsequent release again.

The concern about a release sapping our energy when we should be adding
code is valid, but this delays how soon users can use the items we
_have_ finished.

I don't see any (of the important) issues finished.

Obviously, no one agrees with me, so it looks like May.

At least not me.

May? Vadim said he could probably come back to finish WAL by
April/May. And I'm so bored about the tuple split stuff up
to now, that I don't know if I should start on it for 7.0
right now. So May (optimistic) might be start of BETA - not
release.

And AFAIK, if we start beta that long after our last release,
the next wouldn't be out before July.

That would give me enough time for the other thing (Bruce
knows what I'm talking about).

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 Dec 6 22:59:14 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 WAA50856
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 22:58:44 -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 MAA01633; Tue, 07 Dec 1999 12:58:37 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Jan Wieck" <wieck@debis.com>
Cc: "PostgreSQL HACKERS" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] FOREIGN KEY and shift/reduce
Date: Tue, 7 Dec 1999 13:03:28 +0900
Message-ID: <001701bf4068$04aebc40$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <m11v2k6-0003kGC@orion.SAPserv.Hamburg.dsh.de>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Jan Wieck

Hi,

I just committed a patch that turns on FOREIGN KEY. Thus,
REFERENCES used in CREATE TABLE now automatically creates the
appropriate constraint triggers. The implementation also
supports omitting the PK column definition, if the
corresponding columns should be the PRIMARY KEY of the
referenced table.

Also I completed some more of the generic trigger procs. For
MATCH FULL, the key existence check in PK table and these
actions are completed:

ON DELETE RESTRICT
ON DELETE CASCADE
ON UPDATE RESTRICT
ON UPDATE CASCADE

Nice.
I tried a little.

< session 1 >
=> create table ri1 (id int4 primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit
index 'ri1_pkey' for table 'ri1'
CREATE
=> insert into ri1 values (1);
INSERT 92940 1
=>create table ri2 (id int4 references ri1 match full on delete restrict);
NOTICE: CREATE TABLE will create implicit trigger(s) for
FOREIGN KEY check(s)
CREATE
=> begin;
BEGIN
=> delete from ri1 where id=1;
DELETE 1

< session 2 >
=> insert into ri2 values (1);
INSERT 92960 1

< session 1 >
=> commit;
END
=> select * from ri1;
id
--
(0 rows)
=> select * from ri2;
id
--
1
(1 row)

Is this a temporary behavior ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Dec 6 23:15:15 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 XAA54470
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 23:15:07 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11vBuH-0003kIC; Tue, 7 Dec 99 05:07 MET
Message-Id: <m11vBuH-0003kIC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] TLE subselects (was: Raising funds for PostgreSQL)
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Tue, 7 Dec 1999 05:07:17 +0100 (MET)
Cc: wieck@debis.com, kyle@actarg.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <21577.944536938@sss.pgh.pa.us> from "Tom Lane" at Dec 6,
99 10:22:18 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Tom Lane wrote:

wieck@debis.com (Jan Wieck) writes:

Uh,
who did the latter one?

So I assume it's not implemented in the form I outlined - the
subselecting range table entry. I'll take a look at it the
next days and maybe complain about that change if it
interferes with the needs of the rule system to make
aggregate, distinct, group by, sort by and all the other
(long wanted) view stuff possible.

I don't believe this has anything to do with subselects as range
table entries. That facility will be quite separate from subselects
in expressions, no?

Now that you say it...

Yes, they are separate. They don't interfere.

Thank's for the *slap* - sometimes I need that :-).

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 Dec 6 23:13:15 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA53767
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 23:12:40 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA21382;
Mon, 6 Dec 1999 23:12:30 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912070412.XAA21382@candle.pha.pa.us>
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <Pine.BSF.4.21.9912061920260.18029-100000@thelab.hub.org> from
The
Hermit Hacker at "Dec 6, 1999 07:21:12 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 6 Dec 1999 23:12:30 -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

What do we have now for a v6.6? I'm not against, just wondering if we
have enough to warrant a v6.6, that's all...

Just from completed TODO list items I have many. This doesn't count the
non-list items like the psql rewrite and other big stuff that never made
it to this list. If this gets people interested, I can generate a full
log dump to show the items.

* -Recover or force failure when disk space is exhausted(Hiroshi)
* -INSERT INTO ... SELECT with AS columns matching result columns problem
* -Select a[1] FROM test fails, it needs test.a[1](Tom)
* -Array index references without table name cause problems [array](Tom)
* -INSERT ... SELECT ... GROUP BY groups by target columns not source columns(Tom)
* -CREATE TABLE test (a char(5) DEFAULT text '', b int4) fails on INSERT(Tom)
* -UNION with LIMIT fails
* -CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
* -CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction
* -mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
* -select * from pg_class where oid in (0,-1)
* -SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes
* -require SELECT DISTINCT target list to have all ORDER BY columns
* -When using aggregates + GROUP BY, no rows in should yield no rows out(Tom)
* -Allow HAVING to use comparisons that have no aggregates(Tom)
* -Eliminate limits on query length
* -Fix memory leak for aggregates(Tom)
* -Allow compression of large fields or a compressed field type
* -Allow pg_descriptions when creating tables
* -Allow pg_descriptions when creating types, columns, and functions
* -Add index on NUMERIC/DECIMAL type(Jan)
* -Move LIKE index optimization handling to the optimizer(Tom)
* -Allow psql \copy to allow delimiters
* -Add a function to return the last inserted oid, for use in psql scripts
* -Allow psql to print nulls as distinct from "" [null]
* -Certain indexes will not shrink, i.e. oid indexes with many inserts(Vadim)
* -Allow WHERE restriction on ctid(Hiroshi)
* -Transaction log, so re-do log can be on a separate disk by
* -Allow subqueries in target list
* -Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
* -Allow transaction commits with rollback with no-fsync performance [fsync](Vadim)
* -Prevent fsync in SELECT-only queries(Vadim)
* -Convert function(constant) into a constant for index use(Tom)
* -Make index creation use psort code, because it is now faster(Vadim)
* -Allow creation of sort temp tables > 1 Gig
* -Allow optimizer to prefer plans that match ORDER BY(Tom)
* -Fix memory exhaustion when using many OR's [cnfify](Tom)
* -Process const = const parts of OR clause in separate pass(Tom)
* -Add needed includes and removed unneeded include files(Bruce)
* -Make configure --enable-debug add -g on compile line

-- 
  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 Dec 6 22:44:14 1999
Received: from xavier.cc.xu.edu.ph (ian@xavier.cc.xu.edu.ph [165.220.40.15])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA48665;
Mon, 6 Dec 1999 22:43:46 -0500 (EST)
(envelope-from ian@xavier.cc.xu.edu.ph)
Received: from localhost (ian@localhost)
by xavier.cc.xu.edu.ph (8.8.6/8.8.6) with SMTP id MAA10114;
Tue, 7 Dec 1999 12:16:20 +0800
Date: Tue, 7 Dec 1999 12:16:20 +0800 (PST)
From: Chris Ian Capon Fiel <ian@xavier.cc.xu.edu.ph>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Vadim Mikheev <vadim@krs.ru>, Mike Mascari <mascarm@mascari.com>,
Lamar Owen <lamar.owen@wgcr.org>, Tom Lane <tgl@sss.pgh.pa.us>,
Lincoln Yeoh <lylyeoh@mecomb.com>, pgsql-general@postgresql.org,
PostgreSQL Developers List <hackers@postgresql.org>
Subject: Postgresql in win9x
In-Reply-To: <199911291910.OAA29896@candle.pha.pa.us>
Message-ID: <Pine.LNX.3.96.991207121520.10054B-100000@xavier.cc.xu.edu.ph>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

is there a PostgreSQL in win98 or win95?

From bouncefilter Mon Dec 6 23:27:19 1999
Received: from mecomb.com (gw.mecomb.com [161.142.249.98])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA56781
for <pgsql-general@postgreSQL.org>; Mon, 6 Dec 1999 23:26:59 -0500 (EST)
(envelope-from lylyeoh@mecomb.com)
Received: (from mail@localhost) by mecomb.com (8.8.7/8.8.7) id MAA28166;
Tue, 7 Dec 1999 12:26:41 +0800
Received: from <lylyeoh@mecomb.com> (ilab2.mecomb.po.my [192.168.3.22]) by
ns.mecomb.com via smap (V2.1)
id xma028164; Tue, 7 Dec 99 12:26:35 +0800
Message-Id: <3.0.5.32.19991207122703.008d3100@pop.mecomb.po.my>
X-Sender: lylyeoh@pop.mecomb.po.my
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Tue, 07 Dec 1999 12:27:03 +0800
To: The Hermit Hacker <scrappy@hub.org>
From: Lincoln Yeoh <lylyeoh@mecomb.com>
Subject: Re: [GENERAL] Oft Ask: How to contribute to PostgreSQL?
Cc: pgsql-general@postgreSQL.org, jeff@pgsql.com
In-Reply-To: <Pine.BSF.4.21.9912062257040.18029-100000@thelab.hub.org>
References: <3.0.5.32.19991207101333.00900430@pop.mecomb.po.my>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:12 PM 06-12-1999 -0400, The Hermit Hacker wrote:

I'm glad we are all thinking alike :)

Yep. I really would like a credit card thingy tho, coz it's more convenient
than trying to do international bank transfers, money orders and all that.

There's a bit of pain interfacing with the bank/card clearinghouse though.

On Tue, 7 Dec 1999, Lincoln Yeoh wrote:

At 08:56 PM 05-12-1999 -0400, The Hermit Hacker wrote:

pages off of http://www.pgsql.com that will provide a cleaner means of
contribute financially towards having features implemented, as well as

How about a website where the public can stick in their credit card number
and donate directly to
1) Postgres Inc/Org (which then could pay out "salaries")
2) A particular Postgres project (if necessary).
3) A particular developer (if it won't be detrimental to team spirit).

1. don't like that one...that's what we do the support contracts,

OK. Was just an idea for general funding.

2. see http://www.pgsql.com/features ... its a start, we will expand on it
over the next few days, add a cgi backend, etc etc...

Looks ok, heh maybe some bright spark will put a pledge for negative bucks
for stuff they don't like :).

I still would like support for credit card payments..

3. I feel that this one ties directly into 2...pick a feature taht that
developer has taken on according to the TODO list...

Yeah, probably better for teamwork/teamspirit..

Could also have a Thank you page for things like "Keep up the good work",
"Mucho gracias!", etc (criticism and bug reports should be kept to mailing
lists).

A comments page? Lincoln Yech <lylyech@mecomb.com> says this about
PostreSQL...? Doable, let me play with it...

More like a way of saying "Thanks" to the developers. I figure many times a
sincere word of thanks/encouragement at the right moment is priceless.
Problem is there could be abuses by nasty people.

The comments could actually be added to your existing projects page perhaps.

BTW the Postgres elephant doesn't look quite as attractive as the Linux
penguin.

That said, it could still make a decent stuffed toy. Give it big eyes and a
PostgreSQL t-shirt around a roly-poly body.

Thing is at current exchange rates, I can get cute stuffed toys for only
USD2 here. USD20 is like 20 lunches... Got to save up...

Cheerio,

Link.

From bouncefilter Mon Dec 6 23:31:15 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 XAA57796
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 23:31:10 -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 XAA21920;
Mon, 6 Dec 1999 23:29:54 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Max Buvry <Max.Buvry@enseeiht.fr>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: Book - SQL Aggregates
In-reply-to: Your message of Mon, 6 Dec 1999 22:27:22 -0500 (EST)
<199912070327.WAA19865@candle.pha.pa.us>
Date: Mon, 06 Dec 1999 23:29:54 -0500
Message-ID: <21918.944540994@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

The best way to do that is to display a mess to the user when they try
COUNT(DISTINCT...). That makes it easy because they see it as soon as
they try it.

I was actually thinking about trying to implement aggregate(DISTINCT ...),
or failing that, at least understand why it's hard ;-)

At the very least I think I can manage an explicit "DISTINCT not supported"
error message from the parser. Will take this as a TODO item.

regards, tom lane

From bouncefilter Mon Dec 6 23:41:15 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 XAA59444
for <pgsql-hackers@postgreSQL.org>; Mon, 6 Dec 1999 23:41:02 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11vCJO-0003kJC; Tue, 7 Dec 99 05:33 MET
Message-Id: <m11vCJO-0003kJC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] FOREIGN KEY and shift/reduce
To: Inoue@tpf.co.jp (Hiroshi Inoue)
Date: Tue, 7 Dec 1999 05:33:14 +0100 (MET)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <001701bf4068$04aebc40$2801007e@cadzone.tpf.co.jp> from "Hiroshi
Inoue" at Dec 7, 99 01:03:28 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Hiroshi Inoue wrote:

Nice.
I tried a little.

< session 1 >
=> create table ri1 (id int4 primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit
index 'ri1_pkey' for table 'ri1'
CREATE
=> insert into ri1 values (1);
INSERT 92940 1
=>create table ri2 (id int4 references ri1 match full on delete restrict);
NOTICE: CREATE TABLE will create implicit trigger(s) for
FOREIGN KEY check(s)
CREATE
=> begin;
BEGIN
=> delete from ri1 where id=1;
DELETE 1

< session 2 >
=> insert into ri2 values (1);
INSERT 92960 1

Outch,

I see the shared visibility conflict. So the CHECK constraint
trigger must get an exclusive lock somehow - I think an
internal "FOR UPDATE OF" can do it - will try.

Thanks, Jan

--

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

From bouncefilter Mon Dec 6 23:45:48 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA60020
for <pgsql-general@postgreSQL.org>; Mon, 6 Dec 1999 23:44:26 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id AAA56084;
Tue, 7 Dec 1999 00:44:10 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 7 Dec 1999 00:44:10 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Lincoln Yeoh <lylyeoh@mecomb.com>
cc: pgsql-general@postgreSQL.org, jeff@pgsql.com
Subject: Re: [GENERAL] Oft Ask: How to contribute to PostgreSQL?
In-Reply-To: <3.0.5.32.19991207122703.008d3100@pop.mecomb.po.my>
Message-ID: <Pine.BSF.4.21.9912070038490.823-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Dec 1999, Lincoln Yeoh wrote:

At 11:12 PM 06-12-1999 -0400, The Hermit Hacker wrote:

I'm glad we are all thinking alike :)

Yep. I really would like a credit card thingy tho, coz it's more
convenient than trying to do international bank transfers, money
orders and all that.

There's a bit of pain interfacing with the bank/card clearinghouse
though.

We do do credit cards...let me build the backend for that page first...it
will include the ability to do credit cards. Our products page currently
does handle credit cards, but i haven't had a chance to build up the cgi
yet for the 'pledge' page...

1. don't like that one...that's what we do the support contracts,

OK. Was just an idea for general funding.

There is a 'General Pool' option under the Contribute item in the products
page...I'm going to end up throwing in an 'Advertising' option also, for
magazine ads and such...

2. see http://www.pgsql.com/features ... its a start, we will expand on it
over the next few days, add a cgi backend, etc etc...

Looks ok, heh maybe some bright spark will put a pledge for negative bucks
for stuff they don't like :).

I still would like support for credit card payments..

Go make an order on he products page...ti will ask you for your credit
card number...the pledge page will have it too...i'll try hard to get it
in place tomorrow...

Could also have a Thank you page for things like "Keep up the good work",
"Mucho gracias!", etc (criticism and bug reports should be kept to mailing
lists).

A comments page? Lincoln Yech <lylyech@mecomb.com> says this about
PostreSQL...? Doable, let me play with it...

More like a way of saying "Thanks" to the developers. I figure many times a
sincere word of thanks/encouragement at the right moment is priceless.
Problem is there could be abuses by nasty people.

The comments could actually be added to your existing projects page perhaps.

BTW the Postgres elephant doesn't look quite as attractive as the Linux
penguin.

That said, it could still make a decent stuffed toy. Give it big eyes and a
PostgreSQL t-shirt around a roly-poly body.

Jeff? :)

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

From bouncefilter Tue Dec 7 00:06:39 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA64069
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 00:05:06 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id BAA56234;
Tue, 7 Dec 1999 01:04:20 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 7 Dec 1999 01:04:14 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <199912070412.XAA21382@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.9912070053040.823-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Here's my "fear"...we go beta on jan 1st, for a 6.6 ... if last beta was
any indication, we're talking 2-3 months of beta, so March/April before we
do a release, which disrupts everything that those working on v7.0
features is working on...plus, while debugging, it distracts them from
that work.

If we wait to break into Beta around June 1st, we're still going tobe
talking 2-3mos of beta work, max, so Sept 1 or so for a release...

We're to the point of "competing with the big boys"...how often does
Oracle release?

How about this? Out of the list below, how many can be *safely*
back-patched to the -STABLE tree? The kind of thing where ppl are
*confident* enough that we could put out a v6.5.4 based on those patches?

I would rather see the *safe* ones backpatched and a v6.5.4 released, then
tie up ppl working v7.0 features with debugging an interim release, but
that's just me :(

On Mon, 6 Dec 1999, Bruce Momjian wrote:

What do we have now for a v6.6? I'm not against, just wondering if we
have enough to warrant a v6.6, that's all...

Just from completed TODO list items I have many. This doesn't count the
non-list items like the psql rewrite and other big stuff that never made
it to this list. If this gets people interested, I can generate a full
log dump to show the items.

* -Recover or force failure when disk space is exhausted(Hiroshi)
* -INSERT INTO ... SELECT with AS columns matching result columns problem
* -Select a[1] FROM test fails, it needs test.a[1](Tom)
* -Array index references without table name cause problems [array](Tom)
* -INSERT ... SELECT ... GROUP BY groups by target columns not source columns(Tom)
* -CREATE TABLE test (a char(5) DEFAULT text '', b int4) fails on INSERT(Tom)
* -UNION with LIMIT fails
* -CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
* -CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction
* -mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
* -select * from pg_class where oid in (0,-1)
* -SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes
* -require SELECT DISTINCT target list to have all ORDER BY columns
* -When using aggregates + GROUP BY, no rows in should yield no rows out(Tom)
* -Allow HAVING to use comparisons that have no aggregates(Tom)
* -Eliminate limits on query length
* -Fix memory leak for aggregates(Tom)
* -Allow compression of large fields or a compressed field type
* -Allow pg_descriptions when creating tables
* -Allow pg_descriptions when creating types, columns, and functions
* -Add index on NUMERIC/DECIMAL type(Jan)
* -Move LIKE index optimization handling to the optimizer(Tom)
* -Allow psql \copy to allow delimiters
* -Add a function to return the last inserted oid, for use in psql scripts
* -Allow psql to print nulls as distinct from "" [null]
* -Certain indexes will not shrink, i.e. oid indexes with many inserts(Vadim)
* -Allow WHERE restriction on ctid(Hiroshi)
* -Transaction log, so re-do log can be on a separate disk by
* -Allow subqueries in target list
* -Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
* -Allow transaction commits with rollback with no-fsync performance [fsync](Vadim)
* -Prevent fsync in SELECT-only queries(Vadim)
* -Convert function(constant) into a constant for index use(Tom)
* -Make index creation use psort code, because it is now faster(Vadim)
* -Allow creation of sort temp tables > 1 Gig
* -Allow optimizer to prefer plans that match ORDER BY(Tom)
* -Fix memory exhaustion when using many OR's [cnfify](Tom)
* -Process const = const parts of OR clause in separate pass(Tom)
* -Add needed includes and removed unneeded include files(Bruce)
* -Make configure --enable-debug add -g on compile line

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

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

From bouncefilter Tue Dec 7 00:12:16 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 AAA65772
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 00:11:41 -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 AAA22017;
Tue, 7 Dec 1999 00:10:04 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: The Hermit Hacker <scrappy@hub.org>, Jan Wieck <wieck@debis.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-reply-to: Your message of Mon, 6 Dec 1999 22:00:26 -0500 (EST)
<199912070300.WAA15475@candle.pha.pa.us>
Date: Tue, 07 Dec 1999 00:10:04 -0500
Message-ID: <22015.944543404@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Other than WAL, what else is half-completed and installed?

WAL is probably the thing that forces our hand here. Vadim would know
better than anyone else whether the current state of the code is
releasable, but I bet he'll say "no".

However, I've got a couple of nontrivial concerns:

1. Table locking and shared-cache-invalidation (SI) handling. We've
made some fundamental changes in this area since 6.5, but I don't think
we're done yet. I know Hiroshi is very worried about this area, and
I'm not happy with it either. And this is the kind of thing we cannot
expect to validate with a short beta test cycle. I won't be happy until
I am logically convinced that the code is right, *and* we see solid
behavior in heavy beta testing.

2. Optimizer's handling of order-by cases, specifically whether to use
an index scan or an explicit sort. The current code is (finally!) able
to use an index scan in all the cases where one is applicable ... but it
is *too* eager to do so, because the cost model is underestimating the
cost of an index scan. If we don't fix that I think we will see
substantial performance degradation in some real-world cases, compared
to 6.5 which avoided some losing index scans simply because it was too
stupid to consider them. In particular, we really need some
consideration of the effects of LIMIT in there, because that has a huge
impact on the desirability of index scan vs. sort.

3. Alpha (and other platforms) porting problems. We're still hanging
fire on the issue of what to do about these. If we don't do the fmgr
rewrite the way I want, I think we have to put in the Alpha patches that
Uncle George did... and I'd rather we didn't hack up the code that
way...

The more items in a release, the longer the beta cycle. If you wait too
long, you are fixing code you wrote 6 months ago, and that makes it very
hard. Smaller releases where the code is relatively fresh and the
additional features minimal are cleaner, faster betas.

This is true, but it's also very hard to accomplish really large changes
that way. Some of the things we're trying to get done in this release
are pretty pervasive changes. I think every so often you need a slow-
birthing release where you take time to tackle big things. I don't want
to make a habit of slow releases either, but I see plenty of reasons to
take our time with this one.

regards, tom lane

From bouncefilter Tue Dec 7 08:54:38 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA33653
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 08:54:35 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id FAA20083;
Tue, 7 Dec 1999 05:16:06 GMT
Sender: lockhart@hub.org
Message-ID: <384C9816.21FB00C7@alumni.caltech.edu>
Date: Tue, 07 Dec 1999 05:16:06 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] FOREIGN KEY and shift/reduce
References: <m11v2k6-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If I allow the <constraint attributes> in column constraints,
I get 2 shift/reduce conflicts. Seems the syntax interferes
with NOT NULL. Actually I commented that part out, so the
complete syntax is available only for table constraints, not
on the column level.
Could some yacc-guru please take a look at it?

Guru I'm not, but I should be able to track it down if it isn't fixed
when I *finally* get time to finish the join syntax. Maybe a few
weeks...

- Thomas

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

From bouncefilter Tue Dec 7 00:39:16 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA69782
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 00:38:29 -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 MAA29155;
Tue, 7 Dec 1999 12:28:26 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <384C9AFA.842EBD0A@krs.ru>
Date: Tue, 07 Dec 1999 12:28:26 +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: Bruce Momjian <pgman@candle.pha.pa.us>,
The Hermit Hacker <scrappy@hub.org>, Jan Wieck <wieck@debis.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
References: <22015.944543404@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

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

Other than WAL, what else is half-completed and installed?

WAL is probably the thing that forces our hand here. Vadim would know
better than anyone else whether the current state of the code is
releasable, but I bet he'll say "no".

No.
-:)

But it's very easy to turn current functionality off -
WAL is called on startup/shutdown only, so, just ~10 lines of code
to do nothing here...

Vadim

From bouncefilter Tue Dec 7 02:24:17 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA80357
for <pgsql-hackers@postgresql.org>; Tue, 7 Dec 1999 02:23:37 -0500 (EST)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11vEyG-000Hg1-0K; Tue, 7 Dec 1999 07:23:36 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id IAA03127;
Tue, 7 Dec 1999 08:53:41 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <XXDHVNQT>; Tue, 7 Dec 1999 07:20:31 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70BEF4@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Mike Mascari'" <mascarm@mascari.com>, pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] When is 7.0 going Beta?
Date: Tue, 7 Dec 1999 07:20:27 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

I'd be interested in a data also, as it will give me a target for all
the JDBC stuff I'm working on for 7.0.

Peter (Still catching up :-( )

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

-----Original Message-----
From: Mike Mascari [mailto:mascarm@mascari.com]
Sent: Sunday, December 05, 1999 1:08 AM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] When is 7.0 going Beta?

Hello,

I was just wondering if there were any dates the major
developers had in mind as to when current will be released
as a beta release? For my trivial part, I still have to send
in a patch to allow pg_dump to dump COMMENT ON commands for
any descriptions the user might have created and was
wondering if any time frame had been established.

Just curious,

Mike

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

From bouncefilter Tue Dec 7 02:36:17 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA82004
for <hackers@postgresql.org>; Tue, 7 Dec 1999 02:35:52 -0500 (EST)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11vFA3-000Iqf-0K; Tue, 7 Dec 1999 07:35:47 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id JAA03179;
Tue, 7 Dec 1999 09:05:52 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <XXDHVNQZ>; Tue, 7 Dec 1999 07:32:42 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70BEF7@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'The Hermit Hacker'" <scrappy@hub.org>, Thomas Lockhart
<lockhart@alumni.caltech.edu>
Cc: Robert Aldridge <RALDRIDG@gulf-states.com>, Postgres Hackers List
<hackers@postgresql.org>
Subject: RE: [HACKERS] Re: Geometric Data Type in PostgreSQL
Date: Tue, 7 Dec 1999 07:32:41 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

GIS style, but I don't (yet) use the geometric types. That project's
been on hold for a while.

Saying that though, another project I have - the scheduler I'm working
on for the Tass project (www.tass-survey.org) - will use postgresql for
keeping track of areas of the sky observed, but it's still in the
planning phase at the moment.

Some of the code for the first project (the Java bit that handles the
map display) is on my web site, but it's not that stable, and doesn't
have any postgresql bits in it yet.

Possibly when I get 7.0's JDBC driver out of the way, I'll return to it.

Peter

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

-----Original Message-----
From: The Hermit Hacker [mailto:scrappy@hub.org]
Sent: Sunday, December 05, 1999 10:29 PM
To: Thomas Lockhart
Cc: Robert Aldridge; Postgres Hackers List
Subject: Re: [HACKERS] Re: Geometric Data Type in PostgreSQL

On Fri, 3 Dec 1999, Thomas Lockhart wrote:

I'm a geographic information systems (GIS) professional and a (home)
Linux user. After reading the documentation for the Geometric data
types in PostgreSQL, I'm excited about the possibilities. Are you
aware of any projects where the geometric data types in PostgreSQL

are

being used as the basis of a GIS or mapping package?

Not specifically, though I do know that folks have used it to do
GIS-like things (e.g. given a location on the earth surface, identify
satellite tracks which are visible).

Isn't Peter Mount using PostgreSQL & JDBC for a GIS project?

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

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

From bouncefilter Tue Dec 7 03:14:18 1999
Received: from dcave.digsys.bg (root@dcave.digsys.bg [192.92.129.5])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA89458
for <pgsql-hackers@hub.org>; Tue, 7 Dec 1999 03:14:16 -0500 (EST)
(envelope-from daniel@dcave.digsys.bg)
Received: from dcave.digsys.bg (daniel@localhost.digsys.bg [127.0.0.1])
by dcave.digsys.bg (8.9.0/8.9.0) with ESMTP id KAA25633;
Tue, 7 Dec 1999 10:14:07 +0200 (EET)
Message-Id: <199912070814.KAA25633@dcave.digsys.bg>
X-Mailer: exmh version 2.0.2 2/24/98
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] memory problem again
In-reply-to: Your message of "Mon, 06 Dec 1999 20:53:26 EST."
<20747.944531606@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 07 Dec 1999 10:14:07 +0200
From: Daniel Kalchev <daniel@digsys.bg>

Tom... this is getting even more weird:

logs=> select distinct confid from timelog199911;
pqReadData() -- backend closed the channel unexpectedly.
[...]

Now this:
logs=> \copy timelog199911 to timelog199911
Successfully copied.
logs=> drop table timelog199911;
DROP
logs=> CREATE TABLE "timelog199911" (
"loginname" text,
"site" character varying(16),
"start_time" datetime,
"elapsed" timespan,
"port" text,
"valid" bool,
"ipaddress" inet,
"confid" int4,
"session_id" text);
[...]
CREATE
logs=> CREATE INDEX "timelog199911_loginname_idx" on "timelog199911" using
btree ( "loginname" "text_ops" );
CREATE
logs=> \copy timelog199911 from timelog199911
(ok, I know it's smarted to build the index after copying in the data)
Successfully copied.

logs=> select distinct confid from timelog199911;
sbrk: grow failed, return = 12
sbrk: grow failed, return = 12
pqReadData() -- backend closed the channel unexpectedly.
[...]

logs=> select confid from timelog199911;
[...]
(208749 rows)

Weird!

Daniel

Tom Lane said:

Daniel Kalchev <daniel@digsys.bg> writes:

I have this problem with PostgreSQL 6.5.2:

logs=> select distinct confid
logs-> from timelog199910
logs-> where
logs-> confid IS NOT NULL;
pqReadData() -- backend closed the channel unexpectedly.

The logged message in stderr (of postmaster) is
FATAL 1: Memory exhausted in AllocSetAlloc()

Odd. I can't replicate this here. (I'm using 6.5.3, but I doubt that
matters.) There must be some factor involved that you haven't told us.
You don't have any triggers or rules on the table, do you?

Has anyone else seen anything like this?

regards, tom lane

From bouncefilter Tue Dec 7 03:26:18 1999
Received: from dcave.digsys.bg (root@dcave.digsys.bg [192.92.129.5])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA91121
for <pgsql-hackers@hub.org>; Tue, 7 Dec 1999 03:26:09 -0500 (EST)
(envelope-from daniel@dcave.digsys.bg)
Received: from dcave.digsys.bg (daniel@localhost.digsys.bg [127.0.0.1])
by dcave.digsys.bg (8.9.0/8.9.0) with ESMTP id KAA26222;
Tue, 7 Dec 1999 10:25:57 +0200 (EET)
Message-Id: <199912070825.KAA26222@dcave.digsys.bg>
X-Mailer: exmh version 2.0.2 2/24/98
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@hub.org
Subject: (resolution?) Re: [HACKERS] memory problem again
In-reply-to: Your message of "Mon, 06 Dec 1999 20:53:26 EST."
<20747.944531606@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 07 Dec 1999 10:25:56 +0200
From: Daniel Kalchev <daniel@digsys.bg>

I found out how to resolve this problem, yet it does not explain why it
happens anyway!

I had postmaster started with this script:

unlimit
postmaster -D/usr/local/pgsql/data -B 256 -i -o "-e -S 8192" >>
/usr/local/pgsql/errlog 2>&1 &

Removing all the parameters to postmaster

postmaster -D/usr/local/pgsql/data -i -o "-e" >> /usr/local/pgsql/errlog 2>&1 &

made it work....

Perhaps some memory management problem? I guess the -S option is the culprit
here, but this machine has 256 MB RAM and actually never swaps (yet).

Hope this helps somehow.

Daniel

Tom Lane said:

Daniel Kalchev <daniel@digsys.bg> writes:

I have this problem with PostgreSQL 6.5.2:

logs=> select distinct confid
logs-> from timelog199910
logs-> where
logs-> confid IS NOT NULL;
pqReadData() -- backend closed the channel unexpectedly.

The logged message in stderr (of postmaster) is
FATAL 1: Memory exhausted in AllocSetAlloc()

Odd. I can't replicate this here. (I'm using 6.5.3, but I doubt that
matters.) There must be some factor involved that you haven't told us.
You don't have any triggers or rules on the table, do you?

Has anyone else seen anything like this?

regards, tom lane

From bouncefilter Tue Dec 7 03:50:18 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA93356
for <pgsql-hackers@postgresql.org>; Tue, 7 Dec 1999 03:49:24 -0500 (EST)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from mailgate.maidstone.gov.uk ([194.159.6.98]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11vGJG-000PQq-0K; Tue, 7 Dec 1999 08:49:22 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.9.3/8.9.3) with ESMTP id KAA03486;
Tue, 7 Dec 1999 10:19:29 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <XXDHVNRN>; Tue, 7 Dec 1999 08:46:18 -0000
Message-ID:
<1B3D5E532D18D311861A00600865478C70BF05@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'The Hermit Hacker'" <scrappy@hub.org>, Bruce Momjian
<pgman@candle.pha.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] When is 7.0 going Beta?
Date: Tue, 7 Dec 1999 08:46:16 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

A 6.6 release won't bother me, as I've not committed any of the 7.0
changes to JDBC yet. If there is a release before 7.0, nothing for JDBC
will change.

Peter

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

-----Original Message-----
From: The Hermit Hacker [mailto:scrappy@hub.org]
Sent: Monday, December 06, 1999 11:21 PM
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] When is 7.0 going Beta?

What do we have now for a v6.6? I'm not against, just wondering if we
have enough to warrant a v6.6, that's all...

On Mon, 6 Dec 1999, Bruce Momjian wrote:

I am concerned about a May release. That puts us at almost a year

from

the last major release in mid-June. That is too long. Seems like

we

should have some release around February.

Let's list the 7.0 items:

Foreign Keys - Jan
WAL - Vadim
Function args - Tom
System indexes - Bruce
Date/Time types - Thomas
Optimizer - Tom

Outer Joins - Thomas?
Long Tuples - ?

None of these are done, except for the system indexes, and that is a
small item. It seems everyone wants a grand 7.0, but that is months
away.

I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We
certainly have enough for a 6.6 release.

I recommend this so the 6.5.* enhancements are accessible to users

now,

rather than waiting another severel months while we add the above

fancy

features.

Also, I have never been a big fan of huge, fancy releases because they
take too long to become stable. Better for us to release what we have
now and work out those kinks.

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

19026

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

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

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

From bouncefilter Tue Dec 7 04:54:21 1999
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA99874;
Tue, 7 Dec 1999 04:53:45 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (mail@sfcabop1.nettuno.it
[193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id KAA27863;
Tue, 7 Dec 1999 10:53:37 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 11vI6E-000829-00; Tue, 7 Dec 1999 10:44:02 +0000
Message-ID: <384CD795.4F163169@sferacarta.com>
Date: Tue, 07 Dec 1999 10:47:01 +0100
From: jose soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.5 [it] (Win95; I)
X-Accept-Language: it
MIME-Version: 1.0
To: hackers postgres <pgsql-hackers@postgreSQL.org>,
interfaces <pgsql-interfaces@postgreSQL.org>
Subject: Re: [HACKERS] TRANSACTION "WARNINGS"
References: <199909170445.AAA07310@candle.pha.pa.us>
<3844FE1A.9E48AF93@sferacarta.com>
Content-Type: multipart/alternative;
boundary="------------BFA2687FDAB6B9DFC492C35F"

--------------BFA2687FDAB6B9DFC492C35F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Its me again,

I'm trying to use transactions thru ODBC but it seems to be impossible.
I'm populating my tables using transactions thru ODBC and before to INSERT a row to a table
I check if such row already exist in that table.
if result is FALSE I insert the row into the table otherwise I skip the INSERT operation.
I have a log in which ODBC checks for an unexistent row but when I try to INSERT the row
I cannot insert it, there's a duplicate index error.
I have only two index in that table and only one of them is UNIQUE and I know there is no
other row with the same index in that table.
If I use the same program without transactions it works fine.

Any ideas?

here the log:

<DELETED>
conn=61438304, SQLDriverConnect(out)='DSN=PostgreSQL;DATABASE=hygea;SERVER=verde
conn=61438304, query='SELECT "utenti"."azienda","utenti"."inizio_attivita"
FROM "utenti" WHERE ("azienda" = '01879540308' ) '
[ fetched 0 rows ]
conn=61438304, SQLDisconnect
conn=61284284, query='INSERT INTO "utenti"
("azienda","ragione_sociale","istat","cap","indirizzo","partita_iva","istat_nascita","distretto","data_aggiornamento")

VALUES ('01879540308','FONZAR PAOLO-LUCA-LUCIANO E DANIELA','030120','33050','VIA PROVINCIALE
N.4','01879540308','000000','G10500','1999-11-17 00:00:00')'
ERROR from backend during send_query: 'ERROR: Cannot insert a duplicate key into a unique index'
conn=61284284, query='ABORT'
<DELETED>

and here the table structure:

Table    = utenti
+----------------------------------+----------------------------------+-------+
|Field                             |Type                              | Length|
+----------------------------------+----------------------------------+-------+
| azienda                          | char() not null                  |    16 |
| ragione_sociale                  | varchar() not null               |    45 |
| istat                            | char() not null                  |     6 |
| cap                              | char()                           |     5 |
| indirizzo                        | char()                           |    40 |
| civico                           | char()                           |    10 |
| distretto_interno                | char()                           |     3 |
| frazione                         | char()                           |    25 |
| telefono                         | char()                           |    15 |
| fax                              | char()                           |    15 |
| email                            | char()                           |    15 |
| codice_fiscale                   | char()                           |    16 |
| partita_iva                      | char()                           |    11 |
| cciaa                            | char()                           |     8 |
| data_ccia                        | date                             |     4 |
| data_nascita                     | date                             |     4 |
| istat_nascita                    | char()                           |     6 |
| stato_attivita                   | char()                           |     2 |
| fuori_usl                        | char() default 'N'               |     1 |
| assegnazione_codice              | date                             |     4 |
| inizio_attivita                  | date not null default date( 'cur |     4 |
| fine_attivita                    | date                             |     4 |
| dpr317                           | char() default 'N'               |     1 |
| distretto                        | char()                           |     6 |
| data_aggiornamento               | timestamp default now()          |     4 |
| aggiornato_da                    | char() default CURRENT_USER      |    10 |
| data_esportazione                | date                             |     4 |
| data_precedente_esp              | date                             |     4 |
+----------------------------------+----------------------------------+-------+
Indices:  utenti_pkey
          utenti_ragione_idx

Thanks for any help.
Jose'

jose soares ha scritto:

Hi all,

I have again a problem about TRANSACTIONS.
I had some answers about this matter some time ago, but unfortunately the solution wasn't yet found.
Transaction are essentials for a relational database but in the case of PostgreSQL some times it's
impossible
to use them. Right now I'm in a middle of a work and I need to use transactions but I can't go on because
there are some "warnings" that I would like to avoid but I can't.

Problem:

PostgreSQL automatically ABORTS at every error, even a syntax error.
I know that a transaction is a sequence of operations which either all succeed, or all fail, and
this behavior is correct for batch mode operations, but it is not useful in interactive mode where
the user
could decide if the transaction should be COMMITed or ROLLBACKed even in presence of errors.
Other databases have such behavior.

What about to have a variable to set like:

SET TRANSACTION MODE TO {BATCH | INTERACTIVE}

where:
BATCH: the transaction ROLLBACK at first error and COMMIT only if all operations
succeed.
INTERACTIVE: leaves the final decision to user to COMMIT or ROLLBACK even if some error occurred.

Comments...

Jose'

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

--------------BFA2687FDAB6B9DFC492C35F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Hi,</tt><tt></tt>
<p><tt>Its me again,</tt><tt></tt>
<p><tt>I'm trying to use transactions thru ODBC but it seems to be impossible.</tt>
<br><tt>I'm populating my tables using transactions thru ODBC and before
to INSERT a row to a table</tt>
<br><tt>I check if such row already exist in that table.</tt>
<br><tt>if result is FALSE I insert the row into the table otherwise I
skip the INSERT operation.</tt>
<br><tt>I have a log in which ODBC checks for an unexistent row but when
I try to INSERT the row</tt>
<br><tt>I cannot insert it, there's a duplicate index error.</tt>
<br><tt>I have only two index in that table and only one of them is UNIQUE
and I know there is no</tt>
<br><tt>other row with the same index in that table.</tt>
<br><tt>If I use the same program without transactions it works fine.</tt><tt></tt>
<p><tt>Any ideas?</tt><tt></tt>
<p><tt>here the log:</tt><tt></tt>
<p><tt>&lt;DELETED></tt>
<br><tt>conn=61438304, SQLDriverConnect(out)='DSN=PostgreSQL;DATABASE=hygea;SERVER=verde</tt>
<br><tt>conn=61438304, query='SELECT "utenti"."azienda","utenti"."inizio_attivita"</tt>
<br><tt>FROM "utenti" WHERE ("azienda" = '01879540308' ) '</tt>
<br><tt>&nbsp;&nbsp;&nbsp; [ fetched 0 rows ]</tt>
<br><tt>conn=61438304, SQLDisconnect</tt>
<br><tt>conn=61284284, query='INSERT INTO&nbsp; "utenti" ("azienda","ragione_sociale","istat","cap","indirizzo","partita_iva","istat_nascita","distretto","data_aggiornamento")</tt>
<br><tt>VALUES ('01879540308','FONZAR PAOLO-LUCA-LUCIANO E DANIELA','030120','33050','VIA
PROVINCIALE N.4','01879540308','000000','G10500','1999-11-17 00:00:00')'</tt>
<br><tt>ERROR from backend during send_query:&nbsp; 'ERROR:&nbsp; Cannot
insert a duplicate key into a unique index'</tt>
<br><tt>conn=61284284, query='ABORT'</tt>
<br><tt>&lt;DELETED></tt><tt></tt>
<p><tt>and here the table structure:</tt><tt></tt>
<p><tt>Table&nbsp;&nbsp;&nbsp; = utenti</tt>
<br><tt>+----------------------------------+----------------------------------+-------+</tt>
<br><tt>|Field&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| Length|</tt>
<br><tt>+----------------------------------+----------------------------------+-------+</tt>
<br><tt>| azienda&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char() not null&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; 16 |</tt>
<br><tt>| ragione_sociale&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| varchar() not null&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; 45 |</tt>
<br><tt>| istat&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char() not null&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 6 |</tt>
<br><tt>| cap&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 5 |</tt>
<br><tt>| indirizzo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; 40 |</tt>
<br><tt>| civico&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; 10 |</tt>
<br><tt>| distretto_interno&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 3 |</tt>
<br><tt>| frazione&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; 25 |</tt>
<br><tt>| telefono&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; 15 |</tt>
<br><tt>| fax&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; 15 |</tt>
<br><tt>| email&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; 15 |</tt>
<br><tt>| codice_fiscale&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; 16 |</tt>
<br><tt>| partita_iva&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; 11 |</tt>
<br><tt>| cciaa&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 8 |</tt>
<br><tt>| data_ccia&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 4 |</tt>
<br><tt>| data_nascita&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 4 |</tt>
<br><tt>| istat_nascita&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 6 |</tt>
<br><tt>| stato_attivita&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 2 |</tt>
<br><tt>| fuori_usl&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char() default 'N'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 1 |</tt>
<br><tt>| assegnazione_codice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 4 |</tt>
<br><tt>| inizio_attivita&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| date not null default date( 'cur |&nbsp;&nbsp;&nbsp;&nbsp; 4 |</tt>
<br><tt>| fine_attivita&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 4 |</tt>
<br><tt>| dpr317&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char() default 'N'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 1 |</tt>
<br><tt>| distretto&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 6 |</tt>
<br><tt>| data_aggiornamento&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| timestamp default now()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 4 |</tt>
<br><tt>| aggiornato_da&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| char() default CURRENT_USER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
10 |</tt>
<br><tt>| data_esportazione&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 4 |</tt>
<br><tt>| data_precedente_esp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp; 4 |</tt>
<br><tt>+----------------------------------+----------------------------------+-------+</tt>
<br><tt>Indices:&nbsp; utenti_pkey</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; utenti_ragione_idx</tt>
<br><tt></tt>&nbsp;
<p>Thanks for any help.
<br>Jose'
<br>&nbsp;
<p>jose soares ha scritto:
<blockquote TYPE=CITE>Hi all,
<p>I have again a problem about TRANSACTIONS.
<br>I had some answers about this matter some time ago, but unfortunately
the solution wasn't yet found.
<br>Transaction are essentials for a relational database but in the case
of PostgreSQL some times it's
<br>impossible
<br>to use them. Right now I'm in a middle of a work and I need to use
transactions but I can't go on because
<br>there are some "warnings" that I would like to avoid but I can't.
<p>Problem:
<p>&nbsp;&nbsp;&nbsp; PostgreSQL automatically ABORTS at every error, even
a syntax error.
<br>&nbsp;&nbsp;&nbsp; I know that a transaction is a sequence of operations
which either all succeed, or all fail, and
<br>&nbsp;&nbsp;&nbsp; this behavior is correct for batch mode operations,&nbsp;
but&nbsp; it is not useful in interactive mode where
<br>the user
<br>&nbsp;&nbsp;&nbsp; could decide if the transaction should be COMMITed
or ROLLBACKed even in presence of&nbsp; errors.
<br>&nbsp;&nbsp;&nbsp; Other databases have such behavior.
<p>What about to have a variable to set like:
<p>SET TRANSACTION MODE TO {BATCH | INTERACTIVE}
<p>where:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BATCH:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
the transaction ROLLBACK at first error and COMMIT only if all operations
<br>succeed.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTERACTIVE:&nbsp; leaves
the final decision to user to COMMIT or ROLLBACK even if some error occurred.
<p>Comments...
<p>Jose'
<p>************</blockquote>
</html>

--------------BFA2687FDAB6B9DFC492C35F--

From bouncefilter Tue Dec 7 04:48:19 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 EAA99331
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 04:47:57 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id KAA95398;
Tue, 7 Dec 1999 10:47:40 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <YFC9B7HA>; Tue, 7 Dec 1999 10:47:40 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC1AE@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'The Hermit Hacker'" <scrappy@hub.org>
Cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] RAW I/O device
Date: Tue, 7 Dec 1999 10:47:39 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Actually, Oracle has been moving *away* from this...more
recent versions
of Oracle recommend using the Operating System file systems, since, in
most cases, the Operating System does a better job, and its
too difficult
to have Oracle itself optimize internal for all the different variants
that it supports....

Actually Oracle has features that only work with raw/io, e.g. parallel
server.
Once you know how to handle the raw devs they are a lot more convenient
than flat files. If you have a 100 Gb + DB raw dev is the only way to go.

Andreas

From bouncefilter Tue Dec 7 05:45:36 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 FAA08639
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 05:44:36 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id LAA47426;
Tue, 7 Dec 1999 11:42:35 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <YFC9B7XW>; Tue, 7 Dec 1999 11:42:35 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC1B0@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Bruce Momjian'" <pgman@candle.pha.pa.us>
Cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] RAW I/O device
Date: Tue, 7 Dec 1999 11:42:35 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Actually, Oracle has been moving *away* from this...more

recent versions

of Oracle recommend using the Operating System file

systems, since, in

This is untrue. They need the raw devices for their big DB's
(Parallel Server)

most cases, the Operating System does a better job, and its

too difficult

to have Oracle itself optimize internal for all the

This is especially true for Oracle, since the don't have very
intelligent IO optimizations.

Good DB sided IO optimization can outperform any OS easily.
Especially once you reach the RAM limits of your system.
write cache, read ahead, indexed read ahead,
increased block size (up to 256k) .....

different variants

that it supports....

There is not really that much difference.

Andreas

From bouncefilter Tue Dec 7 06:07:36 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 GAA11893
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 06:07:33 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id MAA67402;
Tue, 7 Dec 1999 12:06:09 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <YFC9B77V>; Tue, 7 Dec 1999 12:06:09 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC1B1@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Bruce Momjian'" <pgman@candle.pha.pa.us>
Cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] RAW I/O device
Date: Tue, 7 Dec 1999 12:06:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

new way for a faster and better database engine. I know (and agree)
that it not is priority for next year(s?). But it is

interesting, and

is prabably good remember it during development, and not

write (in future)

features which close this good way.

I would be very surprised to see any significant change in raw vs.
filesystem i/o on modern file systems,

Beleive me, the difference is substantial.
When you test this you will typically need DB's, that
are larger than your OS file cache.
Second you need to add the memory, that is used by the OS to
cache the DB files to the DB buffer cache when testing raw devs.
Typically you will also use async IO.

One other advantage is, that extending/creating a big raw device
is way faster (takes subseconds for 2 Gb) than creating a big file
(takes minutes). This is especially a pain during restores.
Restores to raw devices (including device/file creation)
are typically only little slower than the backup.

Andreas

From bouncefilter Tue Dec 7 06:11:36 1999
Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA12368
for <hackers@postgresql.org>; Tue, 7 Dec 1999 06:11:07 -0500 (EST)
(envelope-from info@wd-g.com)
Received: from [195.74.116.204] (helo=j-wang)
by serv1.is1.u-net.net with smtp (Exim 2.00 #2)
for hackers@postgresql.org
id 11vIWQ-0005sk-00; Tue, 7 Dec 1999 11:11:06 +0000
From: "info@wd-g.com" <info@wd-g.com>
To: <hackers@postgresql.org>
Reply-To: info@wd-g.com
Subject: ����绰����ѳ�;�����ʹ��ڣ��������
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <E11vIWQ-0005sk-00@serv1.is1.u-net.net>
Date: Tue, 7 Dec 1999 11:11:06 +0000

����绰����ѳ�;�����ʹ��ڣ��������
��ӭ���أ�������ã���Խʱ�գ���������

http://www.wd-g.com

��̸����ͨ�������dzɶ�������Ϣ���緢չ
���޹�˾�����о������ľ��й����Ƚ�ˮƽ
����������ʵʱͨ�����������������ù���
����������ʵʱ�������ݴ�����ʵ�������
��;����ͨ�����䣬��ͨ��Ч��������ͨģ
��绰������������;ͨ�ŷ��ý���������
������������Ϊ�㡣

��̸����ͨ�������ڼ����Ϸdz����죬����
����˹�����ר�Ҽ��û��ĸ߶����ۣ�һ��
��Ϊ��ͨ��������ʵ�ֵ�����ͨ��������ͬ
������������ԶԶ��������������ͬ����һ
����������΢����˾���������ϵͳ��

ϵͳҪ��

���ڴ�������ʮ����Ȼ���ߣ�ʮ�����ڴ�
����ߣ�΢���Ӵ������Űˣ�ʮ�ĵ��ĵ�
�ƽ��������ߣ�˫����������˷������
��ͷ��ʽ������˷硣

��ע��

���ʹ������������Ӧ��֮���������
����һ�������Ÿ�������ǧ��Ҫʹ��һ
���ŵ��������磬��Ϊ�������з���ǽ����
ֹ�������룬�������������������¶Է���
����������һ�����û�û�а취�����Է���
������ֻ�ܱ�̸������

�������ϸ�Ķ�����˵����ע�᷽����̸��
ʱ������˵����

лл��ʹ�ó�̸����ͨ���������й����Լ�
��ͨ��������

�������ųɶ�������Ϣ���緢չ���޹�˾��
����

From bouncefilter Tue Dec 7 07:10:37 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 HAA18830
for <pgsql-hackers@postgresql.org>; Tue, 7 Dec 1999 07:09:47 -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 MAA05607;
Tue, 7 Dec 1999 12:55:03 +0100
Date: Tue, 7 Dec 1999 12:55:03 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] RAW I/O device
In-Reply-To: <199912070324.WAA19731@candle.pha.pa.us>
Message-ID: <Pine.LNX.3.96.991207123103.2896C-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 6 Dec 1999, Bruce Momjian wrote:

I raise the question, because the linux kernel opening with raw-device
new way for a faster and better database engine. I know (and agree)
that it not is priority for next year(s?). But it is interesting, and
is prabably good remember it during development, and not write (in future)
features which close this good way.

I would be very surprised to see any significant change in raw vs.
filesystem i/o on modern file systems, and I am sorry, but Linux ext2
does not count as modern.

Yes. The ext2's limitation and unavailable is public secret and use it for
raw is crazy idea. On a raw device can be implement specific data organization
(specific for DB demand). Raw's advantage is non-universal organization.

A raw is not only about filesystem, this feature remove full control from
OS kernel to DB (example data caching - kernel not has information
how/why/what remove to cache but DB has this information... etc).

Karel

From bouncefilter Tue Dec 7 07:09:37 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 HAA18784
for <hackers@postgreSQL.org>; Tue, 7 Dec 1999 07:09:14 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Panter.DoCS.UU.SE (e99re41@Panter.DoCS.UU.SE [130.238.9.114])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id NAA22455;
Tue, 7 Dec 1999 13:09:11 +0100
Received: from localhost (e99re41@localhost) by Panter.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA03118; Tue, 7 Dec 1999 13:09:09 +0100
X-Authentication-Warning: Panter.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 7 Dec 1999 13:09:07 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Multibyte in autoconf
In-Reply-To: <19991207102941N.t-ishii@sra.co.jp>
Message-ID: <Pine.GSO.4.02A.9912071254180.3057-100000@Panter.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Dec 1999, Tatsuo Ishii wrote:

1) It's not very clear to the casual observer (=end user). I was lead to
believe that the database system you are compiling will only support the
FOO encoding and I used several --with-mb's if I wanted more.

Have you ever read doc/README.mb?

Yes, and although it is nice, it didn't make this particular part easier
to figure out. I mean, if I configure the compilation of a program with
--with-something=foo, then I assume it actually uses "foo" somehow. And
then I see my compilation actually full of -DMULTIBYTE=XXX lines,
confusing me further.

Btw., why is this not in the main documentation?

2) It is very well possible that one initdb instance can be used to
install databases in several locations with varying encodings.

You can initialize database with specified default encoding by initdb -
e or -pgencoding. What's the problem with this?

First and foremost, non-obvious, multi-level meta-defaults. You actually
have a default for what initdb chooses as the default encoding. Also,
think about package maintainers. Which one are they going to pick?

I don't understabd why you do not complain about --with-pgport or --
with-maxbackends. Sounds they have same problems as mb:-)

Well, I can't complain about everything at once :) Surely, those are more
subtle things, though. The pg_ctl you are working on will pretty much
eliminate the need for those.

Anyway, I don't like the idea to have an yet another environment
variable to give a default encoding to initdb when -e or -pgencoding
is not specified. We alread y have enough. Changing --with-mb to --

I agree. Considering the fact that in a fairly normal environment you only
initdb once and you only configure once, would it be too far-fetched to
propose moving this sort of decision completely into initdb, that is, make
the --pgencoding mandatory if you do want some encoding? Because I'm also
not completely sure how you would initdb a database without any encoding
whatsoever if you have your initdb set to always use some default.

To be clear: This is not the end of the world, if you think this will be a
major pain for you, then I'll drop it. I just want to know what the
motivation behind this was.

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

From bouncefilter Tue Dec 7 07:11:37 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 HAA19173
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 07:10:59 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Panter.DoCS.UU.SE (e99re41@Panter.DoCS.UU.SE [130.238.9.114])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id NAA22467;
Tue, 7 Dec 1999 13:10:57 +0100
Received: from localhost (e99re41@localhost) by Panter.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA03122; Tue, 7 Dec 1999 13:10:56 +0100
X-Authentication-Warning: Panter.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 7 Dec 1999 13:10:55 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <199912062258.RAA05675@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.9912071309290.3057-100000@Panter.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 6 Dec 1999, Bruce Momjian wrote:

I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We
certainly have enough for a 6.6 release.

Just to add my two cents here, a Jan 1 feature-freeze is most definitely
not going to work for my part, as there are still some subtle and not so
subtle things to tie up.

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

From bouncefilter Tue Dec 7 07:15:37 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 HAA19767
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 07:15:22 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
HAA05861;
Tue, 7 Dec 1999 07:10:58 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912071210.HAA05861@candle.pha.pa.us>
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <22015.944543404@sss.pgh.pa.us> from Tom Lane at "Dec 7,
1999 00:10:04 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 7 Dec 1999 07:10:58 -0500 (EST)
CC: The Hermit Hacker <scrappy@hub.org>, Jan Wieck <wieck@debis.com>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Other than WAL, what else is half-completed and installed?

WAL is probably the thing that forces our hand here. Vadim would know
better than anyone else whether the current state of the code is
releasable, but I bet he'll say "no".

OK, seems Vadim can turn this off easily, which is what I expected.

The big question is whether we want to stop working on the "features"
list to put out a release?

We have a list of stuff, but other than the first two, they are not
being developed in the current tree, or are not started:

Foreign Keys - Jan
WAL - Vadim
Function args - Tom
Date/Time types - Thomas
Optimizer - Tom

Outer Joins - Thomas?
Long Tuples - ?

Seems the general agreement is that people don't want to stop for 2-3
months to polish what we have done so far. They want to use those 2-3
months for development of the above items.

That is fine, as long as everyone realizes we are going +1 year between
major releases in this case, and that in the period from June to
current, we only have two of these items partially done.

I agree we really don't have a MVCC-type feature to justify a 6.6 at
this time. If Jan could get foreign keys partially working for the
common cases, that may be enough to tip the scales.

I have never been a big release fan. I like to get the code out to the
users. Every release seems to be bigger than the last.

Marc, as far as backpatching, you really can't do that without going
into beta on the release, and if you do that, you might as well use the
current tree. Each patch has already been evaluated for backpatching.
Sorry, no free lunch there.

Another secret is that deadlines generate features. As beta approaches,
things seem to happen much faster.

However, since no one else agrees, I will drop the topic now.

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

From bouncefilter Tue Dec 7 07:15:37 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA19752
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 07:15:11 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
HAA06003;
Tue, 7 Dec 1999 07:14:56 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912071214.HAA06003@candle.pha.pa.us>
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <Pine.GSO.4.02A.9912071309290.3057-100000@Panter.DoCS.UU.SE> from
Peter Eisentraut at "Dec 7, 1999 01:10:55 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 7 Dec 1999 07:14:56 -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, 6 Dec 1999, Bruce Momjian wrote:

I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We
certainly have enough for a 6.6 release.

Just to add my two cents here, a Jan 1 feature-freeze is most definitely
not going to work for my part, as there are still some subtle and not so
subtle things to tie up.

That is interesting, because Peter's psql changes are some of the
features I wanted to get out to users in 6.6.

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

From bouncefilter Tue Dec 7 07:29:37 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 HAA22162
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 07:28:49 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Panter.DoCS.UU.SE (e99re41@Panter.DoCS.UU.SE [130.238.9.114])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id NAA01525;
Tue, 7 Dec 1999 13:28:48 +0100
Received: from localhost (e99re41@localhost) by Panter.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id NAA03152; Tue, 7 Dec 1999 13:28:44 +0100
X-Authentication-Warning: Panter.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 7 Dec 1999 13:28:28 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <199912071214.HAA06003@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.9912071319370.3057-100000@Panter.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Dec 1999, Bruce Momjian wrote:

Just to add my two cents here, a Jan 1 feature-freeze is most definitely
not going to work for my part, as there are still some subtle and not so
subtle things to tie up.

That is interesting, because Peter's psql changes are some of the
features I wanted to get out to users in 6.6.

In case you're interested, this is what definitely still needs to be done:

* \e to edit previous query
* match up \do with COMMENT ON OPERATOR
* actually fix up those comments in the catalogues
* smoothen out tab completion
* write a Windows makefile [ <--- up for grabs! ]
* re-generate regression tests
* make sure the output looks like it should before doing the above
* (maybe more)

These are all not very challenging but do take time, which I currently
don't have.

Also, I think there are some problems with using psql with old servers, in
particular some internal queries generated by \dd or \do create weird
notices.

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

From bouncefilter Tue Dec 7 07:34:37 1999
Received: from server2.gba.gov.ar (IDENT:root@server2.gba.gov.ar
[170.155.1.6])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA23005
for <pgsql-hackers@postgresql.org>; Tue, 7 Dec 1999 07:33:39 -0500 (EST)
(envelope-from sak@tribctas.gba.gov.ar)
Received: from tribctas.gba.gov.ar (IDENT:root@server.tribctas.gba.gov.ar
[10.42.1.1])
by server2.gba.gov.ar (8.9.3/8.8.7) with ESMTP id JAA32168
for <pgsql-hackers@postgresql.org>; Tue, 7 Dec 1999 09:30:57 -0300
Received: from juan ([10.42.1.130])
by tribctas.gba.gov.ar (8.9.3/8.8.7) with SMTP id JAA23548
for <pgsql-hackers@postgresql.org>; Tue, 7 Dec 1999 09:35:21 -0300
From: "Sergio A. Kessler" <sak@tribctas.gba.gov.ar>
Message-Id: <SAK.1999.12.07.fsbpkbqk@juan>
In-Reply-To: <199912070300.WAA15475@candle.pha.pa.us>
Date: Tue, 7 Dec 1999 09:41:33 -0300
X-Priority: 3
Reply-To: sak@tribctas.gba.gov.ar
X-Mailer: Correo F�cil
To: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Subject: Re: [HACKERS] When is 7.0 going Beta?
Content-Type: Text/Plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8Bit

Bruce Momjian <pgman@candle.pha.pa.us> el d�a Mon, 6 Dec 1999 22:00:26 -0500
(EST), escribi�:

I am very hesitant about our "one big release" thing coming? If we wait
for everything to get done, we would never have a release.

and if you declare a feature-freeze at some point ?

Sergio

From bouncefilter Tue Dec 7 08:01:37 1999
Received: from ns.prov-liege.be (ns.prov-liege.be [193.190.122.12])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA26628;
Tue, 7 Dec 1999 08:00:39 -0500 (EST)
(envelope-from Fabian.Frederick@prov-liege.be)
From: Fabian.Frederick@prov-liege.be
Received: by ns.prov-liege.be; (8.8.8/1.3/10May95) id NAA19403;
Tue, 7 Dec 1999 13:49:57 +0100 (GMT+0100)
Received: by mesepl.epl.prov-liege.be with Internet Mail Service (5.5.1960.3)
id <YNVMFRDW>; Tue, 7 Dec 1999 13:53:40 +0100
Message-ID: <17AB709C82E5D111ACF20000F805F4532B41FE@mesadm.epl.prov-liege.be>
To: ian@xavier.cc.xu.edu.ph, pgman@candle.pha.pa.us
Cc: vadim@krs.ru, mascarm@mascari.com, lamar.owen@wgcr.org, tgl@sss.pgh.pa.us,
lylyeoh@mecomb.com, pgsql-general@postgreSQL.org, hackers@postgreSQL.org
Subject: RE: [GENERAL] Postgresql in win9x
Date: Tue, 7 Dec 1999 13:53:39 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

www.postgresql.org doesn't speak about any port so I imagine nothing
exist for now on that platform ; however you can release ODBC accesses.

Fabian
http://www.geocities.com/lonestar_teklords

From bouncefilter Tue Dec 7 08:08:37 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA27501
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 08:07:50 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA59166;
Tue, 7 Dec 1999 09:03:20 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 7 Dec 1999 09:03:20 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, Jan Wieck <wieck@debis.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <199912071210.HAA05861@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.9912070901590.18029-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Dec 1999, Bruce Momjian wrote:

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

Other than WAL, what else is half-completed and installed?

WAL is probably the thing that forces our hand here. Vadim would know
better than anyone else whether the current state of the code is
releasable, but I bet he'll say "no".

OK, seems Vadim can turn this off easily, which is what I expected.

The big question is whether we want to stop working on the "features"
list to put out a release?

No

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

From bouncefilter Tue Dec 7 08:04:37 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA26852
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 08:03:46 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA59170;
Tue, 7 Dec 1999 09:03:48 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 7 Dec 1999 09:03:48 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <199912071214.HAA06003@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.9912070903310.18029-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Dec 1999, Bruce Momjian wrote:

On Mon, 6 Dec 1999, Bruce Momjian wrote:

I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We
certainly have enough for a 6.6 release.

Just to add my two cents here, a Jan 1 feature-freeze is most definitely
not going to work for my part, as there are still some subtle and not so
subtle things to tie up.

That is interesting, because Peter's psql changes are some of the
features I wanted to get out to users in 6.6.

But, as Peter pop'd up, he's not ready for a Beta yet either :)

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

From bouncefilter Tue Dec 7 08:45:38 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 IAA32717
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 08:45:27 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11vKo4-0003kGC; Tue, 7 Dec 99 14:37 MET
Message-Id: <m11vKo4-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: AW: [HACKERS] RAW I/O device
To: ZeugswetterA@wien.spardat.at (Zeugswetter Andreas SB)
Date: Tue, 7 Dec 1999 14:37:28 +0100 (MET)
Cc: scrappy@hub.org, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC1AE@sdexcsrv1.f000.d0188.sd.spardat.at>
from "Zeugswetter Andreas SB" at Dec 7, 99 10:47:39 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Actually Oracle has features that only work with raw/io, e.g. parallel
server.
Once you know how to handle the raw devs they are a lot more convenient
than flat files. If you have a 100 Gb + DB raw dev is the only way to go.

I've seen a 800+ GB Oracle database using filesystem and
performing well. But that needs a GOOD filesystem, not
something like ext2.

Jan

--

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

From bouncefilter Tue Dec 7 08:56:38 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 IAA34053
for <hackers@postgreSQL.org>; Tue, 7 Dec 1999 08:56:23 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id WAA10904;
Tue, 7 Dec 1999 22:56:19 +0900 (JST)
Received: from localhost (IDENT:t-ishii@portsv3-25 [133.137.84.25])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id WAA21024;
Tue, 7 Dec 1999 22:56:17 +0900
To: peter_e@gmx.net, e99re41@DoCS.UU.SE
Cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Multibyte in autoconf
In-Reply-To: <Pine.GSO.4.02A.9912071254180.3057-100000@Panter.DoCS.UU.SE>
References: <19991207102941N.t-ishii@sra.co.jp>
<Pine.GSO.4.02A.9912071254180.3057-100000@Panter.DoCS.UU.SE>
X-Mailer: Mew version 1.94 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991207225614C.t-ishii@sra.co.jp>
Date: Tue, 07 Dec 1999 22:56:14 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 31

Have you ever read doc/README.mb?

Yes, and although it is nice, it didn't make this particular part easier
to figure out. I mean, if I configure the compilation of a program with
--with-something=foo, then I assume it actually uses "foo" somehow. And
then I see my compilation actually full of -DMULTIBYTE=XXX lines,
confusing me further.

I must admit that I'm not good at English and writing:-)

Btw., why is this not in the main documentation?

Ok, I will do it for 7.0. Please give me some idea to enhance
README.mb (you already gave one) if you have any.

Anyway, I don't like the idea to have an yet another environment
variable to give a default encoding to initdb when -e or -pgencoding
is not specified. We alread y have enough. Changing --with-mb to --

I agree. Considering the fact that in a fairly normal environment you only
initdb once and you only configure once, would it be too far-fetched to
propose moving this sort of decision completely into initdb, that is, make
the --pgencoding mandatory if you do want some encoding? Because I'm also
not completely sure how you would initdb a database without any encoding
whatsoever if you have your initdb set to always use some default.

I think I see your point. Giving a default-default encoding to initdb
is not a good idea, right? If so, it comes sounding reasonable to me
too.
--
Tatsuo Ishii

From bouncefilter Tue Dec 7 08:57:38 1999
Received: from daytona.istec.de (firewall-user@daytona.istec.de
[194.77.233.44]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA34145
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 08:57:31 -0500 (EST)
(envelope-from matthias.oestreicher@istec.de)
From: matthias.oestreicher@istec.de
Received: by daytona.istec.de; id OAA20319;
Tue, 7 Dec 1999 14:57:30 +0100 (CET)
Received: from atlas.istec.de(192.168.105.3) by daytona.istec.de via smap
(V4.2) id xma020277; Tue, 7 Dec 99 14:56:49 +0100
Received: by atlas.istec.de with Internet Mail Service (5.5.2448.0)
id <YNCDSL4D>; Tue, 7 Dec 1999 14:56:38 +0100
Message-ID: <07A5A9869AABD21191A100A0C9F2754ABADA@atlas.istec.de>
To: pgsql-hackers@postgreSQL.org
Subject: Referential integrity
Date: Tue, 7 Dec 1999 14:56:36 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Hello,

i am a novice postgresql user (and i like it very much!).
i found out, that the ref.int. doesn't work via a constraining
create table definition...

now my question: has anyone writen a 'compiler' that translates
ri-constraints into triggers and PL/pgSQL procedures?
if so, please tell me where i can find it. if not, tell me about!
perhaps i will write a 'compiler' to do that work automatically.

thanks for your help!

Matthias Oestreicher

mailto:matthias.oestreicher@istec.de
or
mailto:matthias.oestreicher@t-online.de

From bouncefilter Tue Dec 7 09:16:38 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA36809
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 09:15:59 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA20795;
Tue, 7 Dec 1999 14:18:29 GMT
Sender: lockhart@hub.org
Message-ID: <384D1735.9048473D@alumni.caltech.edu>
Date: Tue, 07 Dec 1999 14:18:29 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
References: <Pine.BSF.4.21.9912070901590.18029-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

OK, seems Vadim can turn this off easily, which is what I expected.
The big question is whether we want to stop working on the "features"
list to put out a release?

No

Hmm. istm that several of the folks expecting to make major changes
for a 7.0 release are not able to work on it (much anyway) for the
next couple of months. Tom Lane is the only one to have feet in both
camps (big (?) changes already committed, more coming) but perhaps he
might reconsider his vote for "no 6.6". A 6.6 release cycle would get
that stuff out in the field and tested soon (Jan/Feb timeframe) rather
than waiting 'til May/June to start intensive testing.

I know that we made the commitment for v7.0 (and that waffling on that
issue for past releases drove me nuts ;), but I suspect that what we
already have in the code tree could come close to standing on its own
(especially in light of easily disabling the WAL framework, per
Vadim's note).

I could have "join syntax" ready for a 6.6 (no major changes to the
query tree required), then do the outer joins (with bigger query
tree/optimizer changes) and date/time reunification for 7.0...

- Thomas

Maybe we could steal Scott McNealy's (of Sun Microsystems) term for
Win2K for our 7.0 release:

"The big hairball"

:))

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

From bouncefilter Tue Dec 7 09:23:38 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA37699
for <hackers@postgreSQL.org>; Tue, 7 Dec 1999 09:23:27 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA20983;
Tue, 7 Dec 1999 14:26:16 GMT
Sender: lockhart@hub.org
Message-ID: <384D1908.6479687D@alumni.caltech.edu>
Date: Tue, 07 Dec 1999 14:26:16 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: peter_e@gmx.net, e99re41@DoCS.UU.SE, hackers@postgreSQL.org
Subject: Re: [HACKERS] Multibyte in autoconf
References: <19991207102941N.t-ishii@sra.co.jp>
<Pine.GSO.4.02A.9912071254180.3057-100000@Panter.DoCS.UU.SE>
<19991207225614C.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Btw., why is this not in the main documentation?

Ok, I will do it for 7.0. Please give me some idea to enhance
README.mb (you already gave one) if you have any.

If this is on the same scale as the basic locale support, it might fit
into doc/src/sgml/config.sgml (to appear in the chapter on
Configuration Options in the Admin's Guide). Or if you want put it
into a separate file (e.g. multibyte.sgml) as either plain text or
with some markup and I'll help to integrate it.

Also, I'll be happy to help edit and adjust language, so don't worry
about the translation details ;)

- Thomas

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

From bouncefilter Tue Dec 7 10:05:39 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA43511
for <hackers@postgreSQL.org>; Tue, 7 Dec 1999 10:05: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 KAA23260;
Tue, 7 Dec 1999 10:04:52 -0500 (EST)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: peter_e@gmx.net, hackers@postgreSQL.org
Subject: Re: [HACKERS] Multibyte in autoconf
In-reply-to: Your message of Tue, 07 Dec 1999 22:56:14 +0900
<19991207225614C.t-ishii@sra.co.jp>
Date: Tue, 07 Dec 1999 10:04:52 -0500
Message-ID: <23258.944579092@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

I agree. Considering the fact that in a fairly normal environment you only
initdb once and you only configure once, would it be too far-fetched to
propose moving this sort of decision completely into initdb, that is, make
the --pgencoding mandatory if you do want some encoding? Because I'm also
not completely sure how you would initdb a database without any encoding
whatsoever if you have your initdb set to always use some default.

I think I see your point. Giving a default-default encoding to initdb
is not a good idea, right? If so, it comes sounding reasonable to me
too.

OK, so the proposal is

configure: --enable-mb
Enables compilation of MULTIBYTE code, does not select a default

initdb: --pgencoding=FOO
Establishes coding of database; it's an error to specify non-
default encoding if MULTIBYTE wasn't compiled.
If no --pgencoding, you get default (non-multibyte) coding even
if you compiled with --enable-mb.

Seems reasonable and flexible to me.

regards, tom lane

From bouncefilter Tue Dec 7 10:24:39 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 KAA45966
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 10:23:41 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 16581 invoked by uid 1001); 7 Dec 1999 15:23:42 -0000
Date: Tue, 7 Dec 1999 10:23:42 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: The Hermit Hacker <scrappy@hub.org>,
Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <384D1735.9048473D@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.05.9912071021440.16469-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Dec 1999, Thomas Lockhart wrote:

OK, seems Vadim can turn this off easily, which is what I expected.
The big question is whether we want to stop working on the "features"
list to put out a release?

No

Hmm. istm that several of the folks expecting to make major changes
for a 7.0 release are not able to work on it (much anyway) for the
next couple of months. Tom Lane is the only one to have feet in both
camps (big (?) changes already committed, more coming) but perhaps he
might reconsider his vote for "no 6.6". A 6.6 release cycle would get
that stuff out in the field and tested soon (Jan/Feb timeframe) rather
than waiting 'til May/June to start intensive testing.

Then why not just move 7.0 up to Mar/Apr (or even Feb/Mar) and plan on
the other new stuff for 7.1 if it's not ready?

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

From bouncefilter Tue Dec 7 10:31:39 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA47145
for <hackers@postgresql.org>; Tue, 7 Dec 1999 10:30:43 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA21077;
Tue, 7 Dec 1999 15:33:45 GMT
Sender: lockhart@hub.org
Message-ID: <384D28D9.91876370@alumni.caltech.edu>
Date: Tue, 07 Dec 1999 15:33:45 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Vince Vielhaber <vev@michvhf.com>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] When is 7.0 going Beta?
References: <Pine.BSF.4.05.9912071021440.16469-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Then why not just move 7.0 up to Mar/Apr (or even Feb/Mar) and plan on
the other new stuff for 7.1 if it's not ready?

Even though we make pretty major changes for "minor releases", istm
7.0 should be the release which is the sum of what we've been working
towards in the v6.x series. It would include WAL, outer joins,
integrated date/time, reworked locking, referential integrity,
reworked parse/query tree, yada yada yada...

- Thomas

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

From bouncefilter Tue Dec 7 10:42:40 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA48908
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 10:41:59 -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 KAA23476;
Tue, 7 Dec 1999 10:40:54 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-reply-to: Your message of Tue, 07 Dec 1999 14:18:29 +0000
<384D1735.9048473D@alumni.caltech.edu>
Date: Tue, 07 Dec 1999 10:40:54 -0500
Message-ID: <23474.944581254@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

I know that we made the commitment for v7.0 (and that waffling on that
issue for past releases drove me nuts ;), but I suspect that what we
already have in the code tree could come close to standing on its own
(especially in light of easily disabling the WAL framework, per
Vadim's note).

As Bruce's list reminds us, there are a lot of nice fixes in place
already. I'm not changing my vote (yet), but let's just think a little
further on this...

Considering Bruce's "major items":

WAL: if we can turn it off and leave it in the tree, then this could be
postponed past a 6.6 release.

Foreign keys: Jan has made some commits; features are there but probably
rather broken. As long as the FK stuff is unlikely to break any *existing*
functionality (Jan, do you think that's a safe assumption?) it'd be OK
to leave it in the tree, documented as "work in progress, use at your
own risk". Getting feedback from users might actually help with the
debugging here.

Date/Time types: no commits yet, but because of compatibility issues
we'd want to postpone this to 7.0 anyway.

Function arg changes: same comments. However, we'd have to plug in
Uncle George's Alpha fixes instead. Those are ugly, but I could live
with them as a short-term hack.

Optimizer: really needs some work, but perhaps not very much to get to a
releasable state. Much of what I'd hoped to do for 7.0 could be put off.

Outer joins: As yet no commits, and I'd be inclined to say "leave it
that way for 6.6".

Long tuples: not started, postpone to 7.0.

Query tree redesign: not started, postpone to 7.0.

Things Bruce didn't list:

psql: not ready for prime time, according to Peter (who should know ;-)).

Table locking/SI handling: also not ready for prime time.

Long queries: although this area is almost done, we cannot release
without fixing pg_dump, else it will choke on complex table definitions
and rules that are now possible. Michael Ansley is working on this ---
Michael, do you have an ETA? I think there were some loose ends in
some of the interface libraries, too.

So, if we refocused our energies into cleaning up these items, we
probably could make a reasonable 6.6 release. I'd have to say that
1 Jan is too soon for beta freeze --- dunno about you guys, but family
commitments and Christmas shopping are going to be soaking up most of my
spare cycles through New Year's Day. I can't promise to get much of
anything done until January. 1 Feb would be a reasonable date for me.
I think Hiroshi and I could have the locking stuff solved by then, and
I could find some time to do what must be done in the optimizer. If
Peter can have psql in a presentable state by 1 Feb, it could work.

There is an awful lot to be said for finishing undone work and getting
it out the door to people who need it. Bruce has a good point about
how difficult it is to remember what you were doing 6 months ago.
On the other hand, if we do this then serious 7.0 feature development
will probably not resume till about May, which is a long way off.
Maybe that's a good tradeoff for consolidating our current gains and
getting a beta-test cycle under our belts for what we have already done.

Comments? What other stuff do we have in progress that needs to be
taken into account?

At this point I'm sitting on the fence --- I can see the arguments for
going either way. But I think I might be leaning in favor of a 6.6,
unless someone points out an issue I missed.

regards, tom lane

From bouncefilter Tue Dec 7 10:50: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 KAA50616
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 10:50:37 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11vMlR-0003kGC; Tue, 7 Dec 99 16:42 MET
Message-Id: <m11vMlR-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] FOREIGN KEY and shift/reduce
To: Inoue@tpf.co.jp (Hiroshi Inoue)
Date: Tue, 7 Dec 1999 16:42:53 +0100 (MET)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <001701bf4068$04aebc40$2801007e@cadzone.tpf.co.jp> from "Hiroshi
Inoue" at Dec 7, 99 01:03:28 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Hiroshi Inoue wrote:

Nice.
I tried a little.

[...]
=> begin;
BEGIN
=> delete from ri1 where id=1;
DELETE 1

< session 2 >
=> insert into ri2 values (1);
INSERT 92960 1

< session 1 >
=> commit;
END
=> select * from ri1;
id
--
(0 rows)
=> select * from ri2;
id
--
1
(1 row)

Is this a temporary behavior ?

Fixed.

Session 2 waits now until session 1 ends transaction.

I'm thinking about another enhancement to the regression test
now. Something where at least two sessions can run queries
in a predefined order. Otherwise, something like the above
cannot be checked during regression.

I'm not sure how that can be done with a standard shell, and
that's a must. Maybe something using named pipes and so -
will play around a little.

Jan

--

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

From bouncefilter Tue Dec 7 10:50:39 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 KAA50579
for <hackers@postgreSQL.org>; Tue, 7 Dec 1999 10:50:17 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 16647 invoked by uid 1001); 7 Dec 1999 15:50:18 -0000
Date: Tue, 7 Dec 1999 10:50:18 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <384D28D9.91876370@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.05.9912071049280.16469-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Dec 1999, Thomas Lockhart wrote:

Then why not just move 7.0 up to Mar/Apr (or even Feb/Mar) and plan on
the other new stuff for 7.1 if it's not ready?

Even though we make pretty major changes for "minor releases", istm
7.0 should be the release which is the sum of what we've been working
towards in the v6.x series. It would include WAL, outer joins,
integrated date/time, reworked locking, referential integrity,
reworked parse/query tree, yada yada yada...

But wouldn't much of that end up in a 6.6 release leaving considerably
less for 7.0?

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

From bouncefilter Tue Dec 7 11:04:53 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 LAA52811
for <pgsql-hackers@hub.org>; Tue, 7 Dec 1999 11:04:05 -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 LAA23537;
Tue, 7 Dec 1999 11:02:45 -0500 (EST)
To: Daniel Kalchev <daniel@digsys.bg>
cc: pgsql-hackers@hub.org
Subject: Re: (resolution?) Re: [HACKERS] memory problem again
In-reply-to: Your message of Tue, 07 Dec 1999 10:25:56 +0200
<199912070825.KAA26222@dcave.digsys.bg>
Date: Tue, 07 Dec 1999 11:02:44 -0500
Message-ID: <23535.944582564@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Daniel Kalchev <daniel@digsys.bg> writes:

I found out how to resolve this problem, yet it does not explain why it
happens anyway!
I had postmaster started with this script:
postmaster -D/usr/local/pgsql/data -B 256 -i -o "-e -S 8192" >>
/usr/local/pgsql/errlog 2>&1 &
Removing all the parameters to postmaster
postmaster -D/usr/local/pgsql/data -i -o "-e" >> /usr/local/pgsql/errlog 2>&1 &
made it work....
Perhaps some memory management problem? I guess the -S option is the culprit
here, but this machine has 256 MB RAM and actually never swaps (yet).

8192 * 1K = 8 meg workspace per sort sure doesn't sound unreasonable.
There is a sort going on under-the-hood in your SELECT DISTINCT (it's
implemented in the same fashion as "sort | uniq"), but under ordinary
circumstances that doesn't cause any problem. I can see a couple of
possibilities:
1. You have a very small kernel limit on per-process data space,
probably 8M or at most 16M.
2. Something is broken in the sort code that makes it fail to
obey the -S limit.
I favor #1, since if #2 were true we'd probably have noticed it before.

You might try experimenting with a couple of different -S values (-B
shouldn't make any difference here, it just affects the size of the
shared-memory-block request), and watching the size of the backend
process with top(1) or something like it.

In the meantime, find out where kernel parameters are set on your
system, and look at what MAXDSIZ is set to...

regards, tom lane

From bouncefilter Tue Dec 7 11:17:15 1999
Received: from dcave.digsys.bg (root@dcave.digsys.bg [192.92.129.5])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA55145
for <pgsql-hackers@hub.org>; Tue, 7 Dec 1999 11:16:19 -0500 (EST)
(envelope-from daniel@dcave.digsys.bg)
Received: from dcave.digsys.bg (daniel@localhost.digsys.bg [127.0.0.1])
by dcave.digsys.bg (8.9.0/8.9.0) with ESMTP id SAA17598;
Tue, 7 Dec 1999 18:13:42 +0200 (EET)
Message-Id: <199912071613.SAA17598@dcave.digsys.bg>
X-Mailer: exmh version 2.0.2 2/24/98
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@hub.org
Subject: Re: (resolution?) Re: [HACKERS] memory problem again
In-reply-to: Your message of "Tue, 07 Dec 1999 11:02:44 EST."
<23535.944582564@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 07 Dec 1999 18:13:42 +0200
From: Daniel Kalchev <daniel@digsys.bg>

Tom,

I think the #2 is more likely, because:

the kernel is compiled with large enough data size:

# support for larger processes and number of childs
options "DFLDSIZ=\(128*1024*1024\)"
options "MAXDSIZ=\(256*1024*1024\)"
options "CHILD_MAX=256"
options "OPEN_MAX=256"
options "KMAPENTRIES=4000" # Prevents kmem malloc errors !
options "KMEMSIZE=\(32*1024*1024\)"

the default postgres acocunt limits are:

coredumpsize unlimited
cputime unlimited
datasize 131072 kbytes
filesize unlimited
maxproc 256
memorylocked 85380 kbytes
memoryuse 256136 kbytes
openfiles 128
stacksize 2048 kbytes

I run the postmaster after unlimit, which sets limits thus:

coredumpsize unlimited
cputime unlimited
datasize 262144 kbytes
filesize unlimited
maxproc 4116
memorylocked 256140 kbytes
memoryuse 256136 kbytes
openfiles 13196
stacksize 262144 kbytes

I will do some experimentation with the -S flag to see how it works.

BTW, this postgres is compiled with default of 64 backends - I saw recently
note here that this may interfere with the -S option somehow....

(another not related bug, but still on memory allocation)
Still - this does not explain why postgres cannot allocated more than 76 MB
(according to top) on BSD/OS (never did, actually - any previous version too),
while a simple malloc(1 MB) loop allocates up to the process limit.

Maybe at some time postrges tries to allocate 'larger' chunk, which the BSD/OS
malloc does not like?

Daniel

Tom Lane said:

Daniel Kalchev <daniel@digsys.bg> writes:

I found out how to resolve this problem, yet it does not explain why it
happens anyway!
I had postmaster started with this script:
postmaster -D/usr/local/pgsql/data -B 256 -i -o "-e -S 8192" >>
/usr/local/pgsql/errlog 2>&1 &
Removing all the parameters to postmaster
postmaster -D/usr/local/pgsql/data -i -o "-e" >> /usr/local/pgsql/errlog 2

&1 &

made it work....
Perhaps some memory management problem? I guess the -S option is the culpr

it

here, but this machine has 256 MB RAM and actually never swaps (yet).

8192 * 1K = 8 meg workspace per sort sure doesn't sound unreasonable.
There is a sort going on under-the-hood in your SELECT DISTINCT (it's
implemented in the same fashion as "sort | uniq"), but under ordinary
circumstances that doesn't cause any problem. I can see a couple of
possibilities:
1. You have a very small kernel limit on per-process data space,
probably 8M or at most 16M.
2. Something is broken in the sort code that makes it fail to
obey the -S limit.
I favor #1, since if #2 were true we'd probably have noticed it before.

You might try experimenting with a couple of different -S values (-B
shouldn't make any difference here, it just affects the size of the
shared-memory-block request), and watching the size of the backend
process with top(1) or something like it.

In the meantime, find out where kernel parameters are set on your
system, and look at what MAXDSIZ is set to...

regards, tom lane

From bouncefilter Tue Dec 7 11:35:54 1999
Received: from Radha.DoCS.UU.SE (root@Radha.DoCS.UU.SE [130.238.9.99])
by hub.org (8.9.3/8.9.3) with SMTP id LAA57973
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 11:35:48 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Panter.DoCS.UU.SE (e99re41@Panter.DoCS.UU.SE [130.238.9.114])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id RAA27297;
Tue, 7 Dec 1999 17:35:33 +0100
Received: from localhost (e99re41@localhost) by Panter.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id RAA03349; Tue, 7 Dec 1999 17:35:30 +0100
X-Authentication-Warning: Panter.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 7 Dec 1999 17:35:28 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-Reply-To: <23474.944581254@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.9912071706480.3057-100000@Panter.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Dec 1999, Tom Lane wrote:

psql: not ready for prime time, according to Peter (who should know ;-)).

I could also go for a Feb 1st deadline. By then I could also have some
minor tweakage of initdb and makefiles done, and rewrite the INSTALL doc
so the install process is easier. (Always a good selling point.)

I would have to agree that waiting for all our 7.0 wishes to become true
might mean an indefinite wait at the worst. Release early, release often
is what makes open source projects successful.

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

From bouncefilter Tue Dec 7 12:24:55 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 MAA67302
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 12:23:57 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11vODM-0003kGC; Tue, 7 Dec 99 18:15 MET
Message-Id: <m11vODM-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] When is 7.0 going Beta?
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Tue, 7 Dec 1999 18:15:48 +0100 (MET)
Cc: lockhart@alumni.caltech.edu, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <23474.944581254@sss.pgh.pa.us> from "Tom Lane" at Dec 7,
99 10:40:54 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Tom Lane wrote:

Foreign keys: Jan has made some commits; features are there but probably
rather broken. As long as the FK stuff is unlikely to break any *existing*
functionality (Jan, do you think that's a safe assumption?) it'd be OK
to leave it in the tree, documented as "work in progress, use at your
own risk". Getting feedback from users might actually help with the
debugging here.

Not as safe as you probably want it.

Initially some ppl offered help for FK stuff. The basic's
have been committed for several weeks now, and no contributor
surfaced. So I don't expect any other help now than what I
already got - bug reports. And that's why I concentrated on
the parser/utility area, to get full support into CREATE
TABLE, and the completeness of MATCH FULL. Voila - a few
hours later I got the first bug report.

Now the bad part, the major change I did was the internal
change of the trigger manager to run driven by a deferred
invocation queue. That's the part that could hurt, because
it isn't complete. All trigger events are collected in memory
up to now, and during a huge transaction with millions of
trigger invocations, it could potentially blow away the
backend. Not only RI triggers, ALL trigger events must run
through the queue, and it must remember anything from the
beginning to detect the "triggered data change" violation or
decide what the actual operation really is and which trigger
to invoke finally.

This queue must be able to use a temp file in the case it
grows too big. Since I cannot easily rollback these changes,
it's a show stopper. I knew that from the beginning and
wouldn't have committed that if we hadn't agreed on 7.0 for
the next release. This work is now delayed due to the missed
help, and it must be delayed more to build a multibackend
test driver. Hiroshi's report showed, that especially
referential integrity tests don't make much sense if run by a
single backend serialized.

At this point I'm sitting on the fence --- I can see the arguments for
going either way. But I think I might be leaning in favor of a 6.6,
unless someone points out an issue I missed.

From my point of view, we could start BETA for a 6.6.6 when I
have the temp file buffered queue and the multibackend driver
plus a test suite ready. Even if I don't like it, personally.

Jan

--

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

From bouncefilter Tue Dec 7 12:21:55 1999
Received: from www.actarg.com (root@[209.180.91.25])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA66904
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 12:20:55 -0500 (EST)
(envelope-from kyle@actarg.com)
Received: from actarg.com (root@tao.actarg.com [192.168.1.1])
by www.actarg.com (8.8.7/8.8.7) with ESMTP id KAA30003;
Tue, 7 Dec 1999 10:25:37 -0700
Received: from actarg.com (kyle@chi.actarg.com [192.168.2.16])
by actarg.com (8.8.7/8.8.7) with ESMTP id KAA06573;
Tue, 7 Dec 1999 10:19:16 -0700
Sender: kyle@actarg.com
Message-ID: <384D4239.16EC24@actarg.com>
Date: Tue, 07 Dec 1999 10:22:01 -0700
From: Kyle Bateman <kyle@actarg.com>
Organization: Action Target Inc
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
References: <Pine.BSF.4.21.9912062224510.823-100000@thelab.hub.org>
Content-Type: multipart/mixed; boundary="------------4B1CE0E832528A2B6780AB99"

This is a multi-part message in MIME format.
--------------4B1CE0E832528A2B6780AB99
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The Hermit Hacker wrote:

Here...

http://www.pgsql.com/features/

Have to get it format'd and need to build up the CGI, but this is what you
asking for? :)

That looks great. You don't waste alot of time, do you...

For what its worth, here's the language I would suggest for the page:

"This page enables you to help the Postgresql project move along more quickly and at the
same time it will help you get the new features you want and need the most. Below are a
list of enhancements under consideration by the development team. However it is not known
when each will bubble up to the top of the priority list and actually get done.

If one of these features is important to you, you can pledge a certain amount of money
($100 minimum, please) toward that feature. If you want to help build the pool, tell
others about this page and encourage them to pledge toward those features they feel are
needed the most.

When the accumulation of pledges on any feature reaches the level preset by the
development team, you will be contacted at the email address you supply. You will then
have 2 weeks to actually send in your pledge. If the pledges actually received are still
high enough to justify the project, your feature will be completed and you will be
notified of the next release which includes it.

If the development team does not successfully complete your feature, or if an insufficient
amount of the pledges are actually collected, you will be given the option of getting your
money back or applying the amount toward another feature. If you make a pledge and then
do not honor it, you will not be eligible to make future pledges or for support through
PostgreSQL Inc.

Of the funds collected through this mechanism, 10% will be used for administrative
purposes. The remaining 90% will go directly to the developer(s) working on your
enhancement.

To get an item added to this list, please send email to Jeff MacDonald. If the item is not
already on the TODO list, it will get brought up, discussed, and if entered onto the TODO
list, will also be entered here. You will then be contacted to let you know your entry has
been added, so that you can make your pledge.

Now again, these are just suggestions, but I think the following are good ideas:

1. Exclude items from the list which will be completed in the next 2-3 months anyway
2. Take bids from the development team in advance on each feature. In other words, how
many dollars would they need to start on the enhancement today.
3. Do not disclose these bids to the public
4. Do not disclose the received pledges to date to the public
5. Show on the page how much has been pledged toward the feature only as a percentage of
the amount needed to start the work
6. Include a buffer (20%?) to allow for uncollectable pledges
7. When the pledge is made, bring up a page with an electronic contract with Accept and
Decline buttons. This contract should contain language which is legally binding and which
would hold up in a small claims court. That way if someone makes a pledge and you
complete the feature, you could actually collect your money from them if you wanted to. I
can probably help with the language of this if you want.
8. After a feature has been funded and completed, publish all the details (bids, pledge
amounts, who donated, who flaked on their pledges, etc.)
9. Include prominent information about how to participate in this program on all the web
page headers/footers and in the distribution README's. A catchy link might be "How to get
your favorite feature added into PostgreSQL" You should probably throw something into
these mailing lists from time to time too.
10. Are you set up to take credit cards? This would be nice but I think you can do
without it.
11. You probably should probably choose US Dollars as the standard interchange format.
However, this should appeal to an international market. If you get set up with a web
credit card vendor, they can probably handle exchange issues for you automatically.

Hope this is helpful.

Kyle

--------------4B1CE0E832528A2B6780AB99
Content-Type: text/x-vcard; charset=us-ascii;
name="kyle.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Kyle Bateman
Content-Disposition: attachment;
filename="kyle.vcf"

begin:vcard
n:Bateman;Kyle
tel;fax:801-377-8096
tel;work:801-377-8033x101
x-mozilla-html:FALSE
url:www.actiontarget.com
org:Action Target Inc
adr:;;PO Box 636;Provo;UT;84603;US
version:2.1
email;internet:kyle@actiontarget.com
title:President
x-mozilla-cpt:;-15520
fn:Kyle Bateman
end:vcard

--------------4B1CE0E832528A2B6780AB99--

From bouncefilter Tue Dec 7 12:42:55 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 MAA71063
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 12:42:00 -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 MAA23831;
Tue, 7 Dec 1999 12:40:36 -0500 (EST)
To: wieck@debis.com (Jan Wieck)
cc: lockhart@alumni.caltech.edu, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] When is 7.0 going Beta?
In-reply-to: Your message of Tue, 7 Dec 1999 18:15:48 +0100 (MET)
<m11vODM-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Date: Tue, 07 Dec 1999 12:40:36 -0500
Message-ID: <23829.944588436@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

This queue must be able to use a temp file in the case it
grows too big. Since I cannot easily rollback these changes,
it's a show stopper.

OK, so having the queue file is a must-do before we could release a 6.6.
(BTW, please consider using storage/file/buffile.c for the queue file;
that handles virtual-file access, segmenting of multi-gig files, and
resource cleanup at abort for you. If you need features buffile hasn't
got, let me know.)

... it must be delayed more to build a multibackend
test driver. Hiroshi's report showed, that especially
referential integrity tests don't make much sense if run by a
single backend serialized.

Clearly a good thing for testing referential integrity, but is it needed
to verify that old functionality still works?

OTOH, such a testbed would also be nice for stress-testing the table
locking and SI changes, so maybe it is critical for 6.6 anyway.

From my point of view, we could start BETA for a 6.6.6 when I
have the temp file buffered queue and the multibackend driver
plus a test suite ready. Even if I don't like it, personally.

Would 1 Feb be a good target date for you? How much would doing things
this way distort your development path, compared to what you'd do if
we didn't plan a 6.6 release?

regards, tom lane

From bouncefilter Tue Dec 7 12:53:55 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 MAA72790
for <pgsql-hackers@postgresql.org>; Tue, 7 Dec 1999 12:53:28 -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 MAA23952;
Tue, 7 Dec 1999 12:52:54 -0500 (EST)
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgresql.org
Subject: Parallel regress tests (was Re: FOREIGN KEY and shift/reduce)
In-reply-to: Your message of Tue, 7 Dec 1999 16:42:53 +0100 (MET)
<m11vMlR-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Date: Tue, 07 Dec 1999 12:52:54 -0500
Message-ID: <23950.944589174@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

I'm thinking about another enhancement to the regression test
now. Something where at least two sessions can run queries
in a predefined order. Otherwise, something like the above
cannot be checked during regression.

Yes, we could really use something like that.

I'm not sure how that can be done with a standard shell, and
that's a must. Maybe something using named pipes and so -
will play around a little.

Would probably be more portable to write a little bit of C code that
opens several libpq connections and reads a script file with interleaved
commands to send to the different connections. OTOH, by the time you
got done, it might have much of psql in it (certainly at least the
display code).

Peter, in your slicing and dicing of psql, did you end up with anything
that might make this a feasible approach?

regards, tom lane

From bouncefilter Tue Dec 7 13:08:55 1999
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA75850
for <pgsql-hackers@postgresql.org>; Tue, 7 Dec 1999 13:08:50 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.57.207]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Tue, 7 Dec 1999 12:00:38 -0600
Sender: ed
Message-ID: <384D4D3A.2C2C3DF5@austin.rr.com>
Date: Tue, 07 Dec 1999 12:08:58 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Kyle Bateman <kyle@actarg.com>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
References: <Pine.BSF.4.21.9912062224510.823-100000@thelab.hub.org>
<384D4239.16EC24@actarg.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Kyle Bateman wrote:

Now again, these are just suggestions, but I think the following are good ideas:

3. Do not disclose these bids to the public

4. Do not disclose the received pledges to date to the public

I'm curious about your rationale for 3 and 4. Why not disclose bid amounts (not bidders) and
received pledge amounts (not pledgers) to the public prior to the work being completed? What
do you think would happen?

Ed Loehr

From bouncefilter Tue Dec 7 13:10:55 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 NAA75997
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 13:09:58 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Panter.DoCS.UU.SE (e99re41@Panter.DoCS.UU.SE [130.238.9.114])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id TAA17178;
Tue, 7 Dec 1999 19:09:55 +0100
Received: from localhost (e99re41@localhost) by Panter.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id TAA03443; Tue, 7 Dec 1999 19:09:52 +0100
X-Authentication-Warning: Panter.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 7 Dec 1999 19:09:50 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and
shift/reduce)
In-Reply-To: <23950.944589174@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.9912071904440.3057-100000@Panter.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Dec 1999, Tom Lane wrote:

wieck@debis.com (Jan Wieck) writes:

I'm thinking about another enhancement to the regression test
now. Something where at least two sessions can run queries
in a predefined order. Otherwise, something like the above
cannot be checked during regression.

Peter, in your slicing and dicing of psql, did you end up with anything
that might make this a feasible approach?

Um, you could call another psql from within psql, like so:

/* psql script */
create this
select that
\! psql -f 'second-script'
select more

That satisfies the requirement of two separate sessions and a predefined
order. I haven't actually tried it, but if it happens to not work as
desired, it could certainly be fixed.

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

From bouncefilter Tue Dec 7 13:21:55 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 NAA80631
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 13:21: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 NAA24118;
Tue, 7 Dec 1999 13:21:07 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and
shift/reduce)
In-reply-to: Your message of Tue, 7 Dec 1999 19:09:50 +0100 (MET)
<Pine.GSO.4.02A.9912071904440.3057-100000@Panter.DoCS.UU.SE>
Date: Tue, 07 Dec 1999 13:21:07 -0500
Message-ID: <24116.944590867@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

Peter, in your slicing and dicing of psql, did you end up with anything
that might make this a feasible approach?

Um, you could call another psql from within psql, like so:

/* psql script */
create this
select that
\! psql -f 'second-script'
select more

That satisfies the requirement of two separate sessions and a predefined
order.

I assume that the \! command won't continue until the subjob exits?
If so, this doesn't give us any way to verify that query A will wait for
query B to finish ... at least not without locking up the test...

Another possible approach is to accept that a parallel multi-backend
test lashup *doesn't* have to run on every single system that Postgres
runs on, if we keep it separate from the standard regress tests.
For example, it's not much work to build a parallel test driver in Perl
(I have done it), and I think that an auxiliary test package that
requires Perl would be acceptable.

regards, tom lane

From bouncefilter Tue Dec 7 13:35:56 1999
Received: from www.actarg.com (root@[209.180.91.25])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA82628
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 13:35:08 -0500 (EST)
(envelope-from kyle@actarg.com)
Received: from actarg.com (root@tao.actarg.com [192.168.1.1])
by www.actarg.com (8.8.7/8.8.7) with ESMTP id LAA30168;
Tue, 7 Dec 1999 11:39:50 -0700
Received: from actarg.com (kyle@chi.actarg.com [192.168.2.16])
by actarg.com (8.8.7/8.8.7) with ESMTP id LAA08514;
Tue, 7 Dec 1999 11:33:28 -0700
Sender: kyle@actarg.com
Message-ID: <384D539E.F90489B6@actarg.com>
Date: Tue, 07 Dec 1999 11:36:14 -0700
From: Kyle Bateman <kyle@actarg.com>
Organization: Action Target Inc
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Loehr <ELOEHR@austin.rr.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
References: <Pine.BSF.4.21.9912062224510.823-100000@thelab.hub.org>
<384D4239.16EC24@actarg.com> <384D4D3A.2C2C3DF5@austin.rr.com>
Content-Type: multipart/mixed; boundary="------------48F24BFA73A3BAEE6BE540FB"

This is a multi-part message in MIME format.
--------------48F24BFA73A3BAEE6BE540FB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed Loehr wrote:

Kyle Bateman wrote:

Now again, these are just suggestions, but I think the following are good ideas:

3. Do not disclose these bids to the public

4. Do not disclose the received pledges to date to the public

I'm curious about your rationale for 3 and 4. Why not disclose bid amounts (not bidders) and
received pledge amounts (not pledgers) to the public prior to the work being completed? What
do you think would happen?

Ed Loehr

I'm not really that strong on those issues. I just think if I were setting it up that's
probably the way I would do it to try to maximize the amount of money actually raised and
perhaps keep things a bit more discrete for the developers.

I don't think anything really bad would happen if people know what the numbers are. You could
in fact figure out about what the numbers were anyway by placing a pledge and watching the
change in the percentage. That might be a good reason for hiding them right there... :)

--------------48F24BFA73A3BAEE6BE540FB
Content-Type: text/x-vcard; charset=us-ascii;
name="kyle.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Kyle Bateman
Content-Disposition: attachment;
filename="kyle.vcf"

begin:vcard
n:Bateman;Kyle
tel;fax:801-377-8096
tel;work:801-377-8033x101
x-mozilla-html:FALSE
url:www.actiontarget.com
org:Action Target Inc
adr:;;PO Box 636;Provo;UT;84603;US
version:2.1
email;internet:kyle@actiontarget.com
title:President
x-mozilla-cpt:;-15520
fn:Kyle Bateman
end:vcard

--------------48F24BFA73A3BAEE6BE540FB--

From bouncefilter Tue Dec 7 13:37:56 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 NAA82866
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 13:37:48 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 17058 invoked by uid 1001); 7 Dec 1999 18:37:50 -0000
Date: Tue, 7 Dec 1999 13:37:50 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>, Jan Wieck <wieck@debis.com>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and
shift/reduce)
In-Reply-To: <24116.944590867@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.05.9912071335500.16469-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Dec 1999, Tom Lane wrote:

/* psql script */
create this
select that
\! psql -f 'second-script'
select more

That satisfies the requirement of two separate sessions and a predefined
order.

I assume that the \! command won't continue until the subjob exits?
If so, this doesn't give us any way to verify that query A will wait for
query B to finish ... at least not without locking up the test...

\! psql -f 'second-script' &

will do it. You may wanna redirect your output.

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

From bouncefilter Tue Dec 7 13:41:59 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 NAA04700
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 13:40:59 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Panter.DoCS.UU.SE (e99re41@Panter.DoCS.UU.SE [130.238.9.114])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id TAA22502;
Tue, 7 Dec 1999 19:40:56 +0100
Received: from localhost (e99re41@localhost) by Panter.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id TAA03453; Tue, 7 Dec 1999 19:40:52 +0100
X-Authentication-Warning: Panter.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 7 Dec 1999 19:40:49 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and
shift/reduce)
In-Reply-To: <24116.944590867@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.9912071929470.3057-100000@Panter.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Dec 1999, Tom Lane wrote:

Um, you could call another psql from within psql, like so:

/* psql script */
create this
select that
\! psql -f 'second-script'
select more

That satisfies the requirement of two separate sessions and a predefined
order.

I assume that the \! command won't continue until the subjob exits?
If so, this doesn't give us any way to verify that query A will wait for
query B to finish ... at least not without locking up the test...

I'm kind of losing you here. You want parallel execution *and* a
predefined order of execution? In my (limited) book, those contradict each
other a little bit. If it helps you can also do this:
\! psql -f 'second-script' >& output &
and the thus invoked script will happily continue executing even after you
quit the first psql.

I guess you could also do some simple synchronization things, like have
the second psql wait on a file to spring into existence:
/* second-script */
\! while [ ! -f /tmp/lock.file ]; do ;; done
\! rm /tmp/lock.file

Kind of like a simple semaphore. Isn't that what you are getting at?

In the overall view of things it almost seems like these kind of tests
need a human eye supervising them, because how do really determine "query
A waits for query B to finish" otherwise?

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

From bouncefilter Tue Dec 7 14:07:56 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id OAA24304
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 14:07:12 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11vPpT-0003kGC; Tue, 7 Dec 99 19:59 MET
Message-Id: <m11vPpT-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and
To: peter_e@gmx.net
Date: Tue, 7 Dec 1999 19:59:15 +0100 (MET)
Cc: tgl@sss.pgh.pa.us, wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <Pine.GSO.4.02A.9912071929470.3057-100000@Panter.DoCS.UU.SE> from
"Peter Eisentraut" at Dec 7, 99 07:40:49 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Peter Eisentraut wrote:

On Tue, 7 Dec 1999, Tom Lane wrote:

I assume that the \! command won't continue until the subjob exits?
If so, this doesn't give us any way to verify that query A will wait for
query B to finish ... at least not without locking up the test...

I'm kind of losing you here. You want parallel execution *and* a
predefined order of execution? In my (limited) book, those contradict each
other a little bit. If it helps you can also do this:
\! psql -f 'second-script' >& output &
and the thus invoked script will happily continue executing even after you
quit the first psql.

Yes, we mean controlled order of execution across multiple
backends. And a script invoked in background, like the above,
doesn't do the trick - and BTW we already have that kind of
testing.

I guess you could also do some simple synchronization things, like have
the second psql wait on a file to spring into existence:
/* second-script */
\! while [ ! -f /tmp/lock.file ]; do ;; done
\! rm /tmp/lock.file

Kind of like a simple semaphore. Isn't that what you are getting at?

Kind of, but wasting CPU while waiting. OTOH, some sleep(1)
inside the loop would slow down to a certain degree.

As usual, Tom and I had similar ideas. A little amount of C
code should do it. Only that I would like to use pipes
to/from psql instead of dealing with libpq and formatting
myself.

One problem I noticed so far is, that the new psql (in
contrast to the v6.5 one) doesn't flush it's output when
doing it to a pipe. To control that one backend finished
execution of a query, I thought to send a special comment
line and wait for it to be echoed back. This would only work
if psql flushes.

Peter, could you please add some switch to psql that
activates an fflush() whenever psql would like to read more
input commands. In the meantime I can start to write the
driver using the v6.5 psql.

Jan

--

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

From bouncefilter Tue Dec 7 16:03:07 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 QAA51595;
Tue, 7 Dec 1999 16:02:04 -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 QAA15509;
Tue, 7 Dec 1999 16:00:48 -0500
Message-ID: <384D7577.D4C80586@wgcr.org>
Date: Tue, 07 Dec 1999 16:00:39 -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: Chris Ian Capon Fiel <ian@xavier.cc.xu.edu.ph>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, Vadim Mikheev <vadim@krs.ru>,
Mike Mascari <mascarm@mascari.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Lincoln Yeoh <lylyeoh@mecomb.com>, pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: Postgresql in win9x
References: <Pine.LNX.3.96.991207121520.10054B-100000@xavier.cc.xu.edu.ph>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Ian Capon Fiel wrote:

is there a PostgreSQL in win98 or win95?

http://www.postgresql.org/docs/pgsql/doc/README.NT

The NT port will, AFAIK, run on any Win32 implementation, as long as you
have the Cygwin stuff loaded (talked about in the README.NT file....).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Dec 7 16:16:08 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA53402
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 16:15:28 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA63282;
Tue, 7 Dec 1999 17:15:34 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 7 Dec 1999 17:15:33 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Kyle Bateman <kyle@actarg.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
In-Reply-To: <384D4239.16EC24@actarg.com>
Message-ID: <Pine.BSF.4.21.9912071655160.18029-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I like most of the wording, but the idea behind a pledge is to provide a
pool of money, dedicated towards a particular feature, that we have
reserved, on hand, to be able to contract out. If a "feature" gets $100
in pledges and someone pops up, says I'll do it, pledging for that feature
will freeze at that point, and the programmer will get paid after his code
has been submitted, approved and entered into the repository...

A pledge is record/valid when, and only when, the pledge has been
received...

On Tue, 7 Dec 1999, Kyle Bateman wrote:

The Hermit Hacker wrote:

Here...

http://www.pgsql.com/features/

Have to get it format'd and need to build up the CGI, but this is what you
asking for? :)

That looks great. You don't waste alot of time, do you...

For what its worth, here's the language I would suggest for the page:

"This page enables you to help the Postgresql project move along more
quickly and at the same time it will help you get the new features you
want and need the most. Below are a list of enhancements under
consideration by the development team. However it is not known when
each will bubble up to the top of the priority list and actually get
done.

If one of these features is important to you, you can pledge a certain
amount of money ($100 minimum, please) toward that feature. If you
want to help build the pool, tell others about this page and encourage
them to pledge toward those features they feel are needed the most.

When the accumulation of pledges on any feature reaches the level
preset by the development team, you will be contacted at the email
address you supply. You will then have 2 weeks to actually send in
your pledge. If the pledges actually received are still high enough
to justify the project, your feature will be completed and you will be
notified of the next release which includes it.

If the development team does not successfully complete your feature,
or if an insufficient amount of the pledges are actually collected,
you will be given the option of getting your money back or applying
the amount toward another feature. If you make a pledge and then do
not honor it, you will not be eligible to make future pledges or for
support through PostgreSQL Inc.

Of the funds collected through this mechanism, 10% will be used for
administrative purposes. The remaining 90% will go directly to the
developer(s) working on your enhancement.

To get an item added to this list, please send email to Jeff
MacDonald. If the item is not already on the TODO list, it will get
brought up, discussed, and if entered onto the TODO list, will also be
entered here. You will then be contacted to let you know your entry
has been added, so that you can make your pledge.

1. Exclude items from the list which will be completed in the next 2-3 months anyway

why? if someone feels that WAL is important, and wants to pledge towards
getting that completed, so be it...most of the TODO list is currently
under someone's responsibility (WAL == Vadim)...if ppl want to pledge
$100+ for Vadim to work on this, so be it...when its released, we send
Vadim a cheque for $100+ - 10% ... I don't think he'd refuse, now, do
you? :)

2. Take bids from the development team in advance on each feature.
In other words, how many dollars would they need to start on the
enhancement today.
3. Do not disclose these bids to the public
4. Do not disclose the received pledges to date to the public

I don't like this ...

5. Show on the page how much has been pledged toward the feature only
as a percentage of the amount needed to start the work

The pledges are, IMHO, an incentive for a developer to develop that
feature...if 10 ppl pledge $100 for WAL (sorry, so much talk about it
recently its what first comes to mind), and the 11th person feels its
worth another $100 to get done, why put a cap? Or, if feature X is
something that none of the developers really care about, but 15 admins do,
the higher the pledges go, the more incentive there is for it to get
done...I think its up to those doing the pledges to determine what they
thing a feature is worth in the scheme of things...if the pledges to get
$1000 for a feature, and none of the developers feels up to doing it,
should we cap it?

6. Include a buffer (20%?) to allow for uncollectable pledges

As mentioned above...a pledge isn't listed if not-collected...

7. When the pledge is made, bring up a page with an electronic
contract with Accept and Decline buttons. This contract should
contain language which is legally binding and which would hold up in a
small claims court. That way if someone makes a pledge and you
complete the feature, you could actually collect your money from them
if you wanted to. I can probably help with the language of this if
you want.

More headaches then its worth, really...see above...

8. After a feature has been funded and completed, publish all the
details (bids, pledge amounts, who donated, who flaked on their
pledges, etc.)

Not in my life time...what are we trying for, guilt trips? :(

9. Include prominent information about how to participate in this
program on all the web page headers/footers and in the distribution
README's. A catchy link might be "How to get your favorite feature
added into PostgreSQL" You should probably throw something into these
mailing lists from time to time too.

Agreed...

10. Are you set up to take credit cards? This would be nice but I
think you can do without it.

Definitely...

11. You probably should probably choose US Dollars as the standard
interchange format. However, this should appeal to an international
market. If you get set up with a web credit card vendor, they can
probably handle exchange issues for you automatically.

We do all our values in Canadian, actually...with a link to one of the
online Exchanges for translating values...if I can somehow figure out how
to tie into one of those, where I pass it something like:

?from=canadian&to=us&value=###.##

then I wouldn't be adverse to adding that to the web page...anyone?

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

From bouncefilter Tue Dec 7 16:52:08 1999
Received: from www.actarg.com (root@[209.180.91.25])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA58502
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 16:51:44 -0500 (EST)
(envelope-from kyle@actarg.com)
Received: from actarg.com (root@tao.actarg.com [192.168.1.1])
by www.actarg.com (8.8.7/8.8.7) with ESMTP id OAA30544;
Tue, 7 Dec 1999 14:56:26 -0700
Received: from actarg.com (kyle@chi.actarg.com [192.168.2.16])
by actarg.com (8.8.7/8.8.7) with ESMTP id OAA12035;
Tue, 7 Dec 1999 14:50:03 -0700
Sender: kyle@actarg.com
Message-ID: <384D81B3.79C8E35A@actarg.com>
Date: Tue, 07 Dec 1999 14:52:51 -0700
From: Kyle Bateman <kyle@actarg.com>
Organization: Action Target Inc
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
References: <Pine.BSF.4.21.9912071655160.18029-100000@thelab.hub.org>
Content-Type: multipart/mixed; boundary="------------9580F64EE82A18E1CB1F487D"

This is a multi-part message in MIME format.
--------------9580F64EE82A18E1CB1F487D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The Hermit Hacker wrote:

I like most of the wording, but the idea behind a pledge is to provide a
pool of money, dedicated towards a particular feature, that we have
reserved, on hand, to be able to contract out. If a "feature" gets $100
in pledges and someone pops up, says I'll do it, pledging for that feature
will freeze at that point, and the programmer will get paid after his code
has been submitted, approved and entered into the repository...

A pledge is record/valid when, and only when, the pledge has been
received...

What can we do to assure a donor that his feature will actually get completed as a result
of his donation? It seems to me this will be most people's hesitation (mine, at least)
is sending money in without any kind of mechanism to control how it is spent.

1. Exclude items from the list which will be completed in the next 2-3 months anyway

why? if someone feels that WAL is important, and wants to pledge towards
getting that completed, so be it...most of the TODO list is currently
under someone's responsibility (WAL == Vadim)...if ppl want to pledge
$100+ for Vadim to work on this, so be it...when its released, we send
Vadim a cheque for $100+ - 10% ... I don't think he'd refuse, now, do
you? :)

I guess my thought here was if an item was already being worked on, it would be difficult
(impossible) to determine a target value (the amount of money needed before work would
begin). The target value is inherently 0 once the work has already begun. I think the
goal is to give donors positive feedback i.e. "I pledged, I paid, the feature got done.
Without me, it probably wouldn't have happened (so soon)." Once they have that cycle
happen, they'll be back to do it again because it will feel good.

2. Take bids from the development team in advance on each feature.
In other words, how many dollars would they need to start on the
enhancement today.
3. Do not disclose these bids to the public
4. Do not disclose the received pledges to date to the public

I don't like this ...

Understood. I think this part can be done in a number of ways. But let me explain what
this does.

By setting a bid from the development team, that tells the donor that you are serious
about using his money for its intended purpose. The team is committed to that feature,
they're just waiting for the pool to build up to the target value. A donor will want to
know that his cash is not just going to be sucked into whatever cash flow needs are
urgent that week--he'll know exactly what he needs to do to make the enhancement a
reality. And the rules won't change on him after he sends his check in.

5. Show on the page how much has been pledged toward the feature only
as a percentage of the amount needed to start the work

The pledges are, IMHO, an incentive for a developer to develop that
feature...if 10 ppl pledge $100 for WAL (sorry, so much talk about it
recently its what first comes to mind), and the 11th person feels its
worth another $100 to get done, why put a cap? Or, if feature X is
something that none of the developers really care about, but 15 admins do,
the higher the pledges go, the more incentive there is for it to get
done...I think its up to those doing the pledges to determine what they
thing a feature is worth in the scheme of things...if the pledges to get
$1000 for a feature, and none of the developers feels up to doing it,
should we cap it?

I don't consider it a cap. If you get more money than the feature needs, it would be
great to have the right to throw the excess off into a second feature. That would
accelerate the development even more.

6. Include a buffer (20%?) to allow for uncollectable pledges

As mentioned above...a pledge isn't listed if not-collected...

7. When the pledge is made, bring up a page with an electronic
contract with Accept and Decline buttons. This contract should
contain language which is legally binding and which would hold up in a
small claims court. That way if someone makes a pledge and you
complete the feature, you could actually collect your money from them
if you wanted to. I can probably help with the language of this if
you want.

More headaches then its worth, really...see above...

I think the key here is no matter what we do, if no one sends in the $, its not going to
work. It has to be something enticing enough that people will actually pay.

8. After a feature has been funded and completed, publish all the
details (bids, pledge amounts, who donated, who flaked on their
pledges, etc.)

Not in my life time...what are we trying for, guilt trips? :(

9. Include prominent information about how to participate in this
program on all the web page headers/footers and in the distribution
README's. A catchy link might be "How to get your favorite feature
added into PostgreSQL" You should probably throw something into these
mailing lists from time to time too.

Agreed...

10. Are you set up to take credit cards? This would be nice but I
think you can do without it.

Definitely...

11. You probably should probably choose US Dollars as the standard
interchange format. However, this should appeal to an international
market. If you get set up with a web credit card vendor, they can
probably handle exchange issues for you automatically.

We do all our values in Canadian, actually...with a link to one of the
online Exchanges for translating values...if I can somehow figure out how
to tie into one of those, where I pass it something like:

--------------9580F64EE82A18E1CB1F487D
Content-Type: text/x-vcard; charset=us-ascii;
name="kyle.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Kyle Bateman
Content-Disposition: attachment;
filename="kyle.vcf"

begin:vcard
n:Bateman;Kyle
tel;fax:801-377-8096
tel;work:801-377-8033x101
x-mozilla-html:FALSE
url:www.actiontarget.com
org:Action Target Inc
adr:;;PO Box 636;Provo;UT;84603;US
version:2.1
email;internet:kyle@actiontarget.com
title:President
x-mozilla-cpt:;-15520
fn:Kyle Bateman
end:vcard

--------------9580F64EE82A18E1CB1F487D--

From bouncefilter Tue Dec 7 16:58:08 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 QAA59386
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 16:57:07 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Panter.DoCS.UU.SE (e99re41@Panter.DoCS.UU.SE [130.238.9.114])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id WAA24208;
Tue, 7 Dec 1999 22:56:53 +0100
Received: from localhost (e99re41@localhost) by Panter.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id WAA03542; Tue, 7 Dec 1999 22:56:51 +0100
X-Authentication-Warning: Panter.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 7 Dec 1999 22:56:51 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Jan Wieck <wieck@debis.com>
cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and
In-Reply-To: <m11vPpT-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.GSO.4.02A.9912072138190.3057-100000@Panter.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 7 Dec 1999, Jan Wieck wrote:

I guess you could also do some simple synchronization things, like have
the second psql wait on a file to spring into existence:
/* second-script */
\! while [ ! -f /tmp/lock.file ]; do ;; done
\! rm /tmp/lock.file

Kind of like a simple semaphore. Isn't that what you are getting at?

Kind of, but wasting CPU while waiting. OTOH, some sleep(1)
inside the loop would slow down to a certain degree.

Well, we're testing and not benchmarking...

code should do it. Only that I would like to use pipes
to/from psql instead of dealing with libpq and formatting
myself.

If you like, the print routines in psql are competely isolated from the
rest of the code and you can just #include and use them.

Peter, could you please add some switch to psql that
activates an fflush() whenever psql would like to read more
input commands. In the meantime I can start to write the
driver using the v6.5 psql.

I'm going to go an a flush hunt...

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

From bouncefilter Tue Dec 7 17:39:08 1999
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net
[194.217.242.39]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA65164
for <hackers@postgresql.org>; Tue, 7 Dec 1999 17:38:18 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1)
id 11vTFR-000C1n-0B
for hackers@postgreSQL.org; Tue, 7 Dec 1999 22:38:17 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id WAA08259; Tue, 7 Dec 1999 22:38:09 GMT
Message-Id: <199912072238.WAA08259@mtcc.demon.co.uk>
Date: Tue, 7 Dec 1999 22:38:08 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Table aliases in delete statements?
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: g7ZtNv0CRZpj+JkeeOIUfQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

Hi All,

Is there any reason for not allowing table aliases in
delete statements?

I was trying to delete duplicates from an ascend log
database when I hit the following "parse" error.

(Perhaps I shouldn't be using a correlated subquery!!)

Simplified example follows.....

emkxp01=> create table deltest ( sessionid int, respdate datetime );
CREATE
emkxp01=> insert into deltest values ( 1, now() );
INSERT 58395 1
emkxp01=> insert into deltest values ( 1, now() );
INSERT 58396 1
emkxp01=> insert into deltest values ( 2, now() );
INSERT 58397 1
emkxp01=> insert into deltest values ( 2, now() );
INSERT 58398 1
emkxp01=> select * from deltest s1 where s1.respdate not in ( select
min(s2.respdate) from deltest s2 where s1.sessionid = s2.sessionid);
sessionid | respdate
-----------+------------------------------
1 | Tue 07 Dec 22:32:08 1999 GMT
2 | Tue 07 Dec 22:32:19 1999 GMT
(2 rows)

emkxp01=> select * from deltest;
sessionid | respdate
-----------+------------------------------
1 | Tue 07 Dec 22:32:01 1999 GMT
1 | Tue 07 Dec 22:32:08 1999 GMT
2 | Tue 07 Dec 22:32:14 1999 GMT
2 | Tue 07 Dec 22:32:19 1999 GMT
(4 rows)

emkxp01=> delete from deltest s1 where s1.respdate not in ( select
min(s2.respdate) from deltest s2 where s1.sessionid = s2.sessionid);
ERROR: parser: parse error at or near "s1"
emkxp01=>

From bouncefilter Tue Dec 7 18:06:09 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 SAA68949
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 18:05:28 -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 SAA24942;
Tue, 7 Dec 1999 18:04:51 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY and
In-reply-to: Your message of Tue, 7 Dec 1999 22:56:51 +0100 (MET)
<Pine.GSO.4.02A.9912072138190.3057-100000@Panter.DoCS.UU.SE>
Date: Tue, 07 Dec 1999 18:04:51 -0500
Message-ID: <24940.944607891@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

Peter, could you please add some switch to psql that
activates an fflush() whenever psql would like to read more
input commands. In the meantime I can start to write the
driver using the v6.5 psql.

I'm going to go an a flush hunt...

Offhand I see no reason why psql shouldn't *always* fflush its output
before reading a new command. It'd waste a few microseconds per command
when reading from a file, but that'd hardly be noticeable in the great
scheme of things. Adding another switch is just offering another way
for people to make a mistake...

regards, tom lane

From bouncefilter Tue Dec 7 18:16:09 1999
Received: from rage.hub.org (root@nat202.25.mpoweredpc.net [142.177.202.25])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA70364
for <pgsql-general@postgreSQL.org>; Tue, 7 Dec 1999 18:15:53 -0500 (EST)
(envelope-from jeffm@pgsql.com)
Received: from localhost (jeffm@localhost)
by rage.hub.org (8.9.3/8.9.3) with ESMTP id TAA47735;
Tue, 7 Dec 1999 19:15:40 -0400 (AST) (envelope-from jeffm@pgsql.com)
X-Authentication-Warning: rage.hub.org: jeffm owned process doing -bs
Date: Tue, 7 Dec 1999 19:15:40 -0400 (AST)
From: "Jeff MacDonald <jeff@pgsql.com>" <jeffm@pgsql.com>
X-Sender: jeffm@rage.hub.org
Reply-To: Jeff MacDonald <jeff@pgsql.com>
To: Lincoln Yeoh <lylyeoh@mecomb.com>
cc: The Hermit Hacker <scrappy@hub.org>, pgsql-general@postgreSQL.org,
jeff@pgsql.com
Subject: Re: [GENERAL] Oft Ask: How to contribute to PostgreSQL?
In-Reply-To: <3.0.5.32.19991207122703.008d3100@pop.mecomb.po.my>
Message-ID: <Pine.BSF.4.10.9912071913240.13793-100000@rage.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

BTW the Postgres elephant doesn't look quite as attractive as the Linux
penguin.

that being said, the linun penguin isn't nearly as attractive as the freebsd
deemon , but don't get us started :)

That said, it could still make a decent stuffed toy. Give it big eyes and a
PostgreSQL t-shirt around a roly-poly body.

20usd is 30+cdn : for a stuffed toy ? we'll look into it.

on a side note we are looking into cofee mugs, keychains(alredy ordered)
and possibly mouse pads

jeff

From bouncefilter Tue Dec 7 18:34:09 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 SAA72198
for <pgsql-hackers@hub.org>; Tue, 7 Dec 1999 18:33:25 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA13688;
Tue, 7 Dec 1999 18:16:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912072316.SAA13688@candle.pha.pa.us>
Subject: Re: (resolution?) Re: [HACKERS] memory problem again
In-Reply-To: <199912071613.SAA17598@dcave.digsys.bg> from Daniel Kalchev at
"Dec 7, 1999 06:13:42 pm"
To: Daniel Kalchev <daniel@digsys.bg>
Date: Tue, 7 Dec 1999 18:16:17 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@hub.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

(another not related bug, but still on memory allocation)
Still - this does not explain why postgres cannot allocated more than 76 MB
(according to top) on BSD/OS (never did, actually - any previous version too),
while a simple malloc(1 MB) loop allocates up to the process limit.

Maybe at some time postrges tries to allocate 'larger' chunk, which the BSD/OS
malloc does not like?

You can easily put in errlog(NOTICE...) and dump out the allocations to
see what is being requested. It is also possible TOP display is not
accurate in some way. Does ps vm flags show this too?

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

From bouncefilter Tue Dec 7 19:26:09 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 TAA81149
for <hackers@postgreSQL.org>; Tue, 7 Dec 1999 19:25:36 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA15217;
Tue, 7 Dec 1999 19:23:55 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912080023.TAA15217@candle.pha.pa.us>
Subject: Re: [HACKERS] Table aliases in delete statements?
In-Reply-To: <199912072238.WAA08259@mtcc.demon.co.uk> from Keith Parks at "Dec
7, 1999 10:38:08 pm"
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Date: Tue, 7 Dec 1999 19:23:55 -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

emkxp01=> delete from deltest s1 where s1.respdate not in ( select
min(s2.respdate) from deltest s2 where s1.sessionid = s2.sessionid);
ERROR: parser: parse error at or near "s1"
emkxp01=>

Don't use s1. Just refer to native deltest in the subquery. That
should reference the outer table.

-- 
  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 Dec 7 19:39:10 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 TAA82771
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 19:39:06 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11vV0n-0003kGC; Wed, 8 Dec 99 01:31 MET
Message-Id: <m11vV0n-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Raising funds for PostgreSQL
To: kyle@actarg.com (Kyle Bateman)
Date: Wed, 8 Dec 1999 01:31:17 +0100 (MET)
Cc: scrappy@hub.org, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <384D81B3.79C8E35A@actarg.com> from "Kyle Bateman" at Dec 7,
99 02:52:51 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Kyle Bateman wrote:

The Hermit Hacker wrote:

A pledge is record/valid when, and only when, the pledge has been
received...

What can we do to assure a donor that his feature will actually get completed as a result
of his donation? It seems to me this will be most people's hesitation (mine, at least)
is sending money in without any kind of mechanism to control how it is spent.

Maybe we have to make pools per feature. Requires IMHO to
move features, where donations can be thrown on, onto a
separate DONOTODO list. Items there should have a clear,
detailed specification, what the feature finally will
implement and expected implementation time, assuming a
developer can work at least X hours per week on it.

Each of these DONOTODO items has it's own account, and a
donator can send in cash for specific items. As soon, as the
account balance raised high enough, someone will claim to do
it - sure. At this point, the item is locked and a deadline
for finishing, depending on the estimated efford (from the
detailed feature spec) is set.

Up to the point, where an item get's locked, the donator can
transfer any amount between item accounts and (of course) get
back his money. After that point, only additional donations
can be placed on the item to increase the efford to finish it
in time.

At deadline overruns, donators can decide again what to do
with their money. So the developers have some pressure in the
neck to complete the items in time.

In the backside, we must coordinate if multiple developers
need each other to do one item together. They have to decide
a split ratio of the account balance. Should IMHO be a
floating process and depending on the developers involved,
could be open until the end.

Well, there must be a steering commitee, controlling the
DONOTODO items and the cash flow - PostgreSQL Inc. would be
my first guess.

Jan

--

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

From bouncefilter Tue Dec 7 19:49:10 1999
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net
[194.217.242.41]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA84154
for <hackers@postgresql.org>; Tue, 7 Dec 1999 19:48:17 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 11vVHE-000F1E-0C; Wed, 8 Dec 1999 00:48:16 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id AAA10593; Wed, 8 Dec 1999 00:48:12 GMT
Message-Id: <199912080048.AAA10593@mtcc.demon.co.uk>
Date: Wed, 8 Dec 1999 00:48:12 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] Table aliases in delete statements?
To: emkxp01@mtcc.demon.co.uk, pgman@candle.pha.pa.us
Cc: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: OTBDNcPP9R0L4cpN/JnuDg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

Bruce Momjian <pgman@candle.pha.pa.us>

emkxp01=> delete from deltest s1 where s1.respdate not in ( select
min(s2.respdate) from deltest s2 where s1.sessionid = s2.sessionid);
ERROR: parser: parse error at or near "s1"
emkxp01=>

Don't use s1. Just refer to native deltest in the subquery. That
should reference the outer table.

That doesn't seem to work as 3 rows are deleted and not just the
two duplicates.

emkxp01=> delete from deltest where respdate not in ( select min(s2.respdate)
from deltest s2 where sessionid = s2.sessionid);
DELETE 3
emkxp01=> select * from deltest;
sessionid | respdate
-----------+------------------------------
1 | Tue 07 Dec 22:32:01 1999 GMT
(1 row)

emkxp01=>

Keith.

From bouncefilter Wed Dec 8 06:11:18 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id GAA50093
for <hackers@postgresql.org>; Wed, 8 Dec 1999 06:10:34 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11vezR-000Poi-0K; Wed, 8 Dec 1999 11:10:33 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id AAA10604; Wed, 8 Dec 1999 00:52:03 GMT
Message-Id: <199912080052.AAA10604@mtcc.demon.co.uk>
Date: Wed, 8 Dec 1999 00:52:03 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] Table aliases in delete statements?
To: emkxp01@mtcc.demon.co.uk, pgman@candle.pha.pa.us
Cc: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: MFvJoinf7wgbO6C7jPLb5A==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

Keith Parks <emkxp01@mtcc.demon.co.uk>

Bruce Momjian <pgman@candle.pha.pa.us>

emkxp01=> delete from deltest s1 where s1.respdate not in ( select
min(s2.respdate) from deltest s2 where s1.sessionid = s2.sessionid);
ERROR: parser: parse error at or near "s1"
emkxp01=>

Don't use s1. Just refer to native deltest in the subquery. That
should reference the outer table.

That doesn't seem to work as 3 rows are deleted and not just the
two duplicates.

emkxp01=> delete from deltest where respdate not in ( select min(s2.respdate)
from deltest s2 where sessionid = s2.sessionid);
DELETE 3
emkxp01=> select * from deltest;
sessionid | respdate
-----------+------------------------------
1 | Tue 07 Dec 22:32:01 1999 GMT
(1 row)

emkxp01=>

Ooops sorry, it does work if I use the tablename.colname syntax.

emkxp01=> delete from deltest where respdate not in ( select min(s2.respdate)
from deltest s2 where deltest.sessionid = s2.sessionid);
DELETE 2
emkxp01=> select * from deltest;
sessionid | respdate
-----------+------------------------------
1 | Tue 07 Dec 22:32:01 1999 GMT
2 | Wed 08 Dec 00:48:59 1999 GMT
(2 rows)

emkxp01=>

From bouncefilter Tue Dec 7 23:07:13 1999
Received: from trends.net (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA02052
for <hackers@postgresql.org>; Tue, 7 Dec 1999 23:06:09 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by trends.net (8.8.8/8.8.8) with ESMTP id UAA03276
for <hackers@postgreSQL.org>; Tue, 7 Dec 1999 20:33:45 -0500 (EST)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA18591;
Tue, 7 Dec 1999 20:05:18 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912080105.UAA18591@candle.pha.pa.us>
Subject: Re: [HACKERS] Table aliases in delete statements?
In-Reply-To: <199912080048.AAA10593@mtcc.demon.co.uk> from Keith Parks at "Dec
8, 1999 00:48:12 am"
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Date: Tue, 7 Dec 1999 20:05:18 -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

Don't use s1. Just refer to native deltest in the subquery. That
should reference the outer table.

That doesn't seem to work as 3 rows are deleted and not just the
two duplicates.

emkxp01=> delete from deltest where respdate not in ( select min(s2.respdate)
from deltest s2 where sessionid = s2.sessionid);
DELETE 3
emkxp01=> select * from deltest;
sessionid | respdate
-----------+------------------------------
1 | Tue 07 Dec 22:32:01 1999 GMT
(1 row)

No. Use:

emkxp01=> delete from deltest where respdate not in ( select min(s2.respdate)
from deltest s2 where deltest.sessionid = s2.sessionid);
^^^^^^^

-- 
  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 Dec 7 23:07:10 1999
Received: from trends.net (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA01839
for <pgsql-hackers@postgresql.org>; Tue, 7 Dec 1999 23:05:00 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from www.wgcr.org (root@www.wgcr.org [206.74.232.194])
by trends.net (8.8.8/8.8.8) with ESMTP id VAA06252
for <pgsql-hackers@postgreSQL.org>; Tue, 7 Dec 1999 21:48:51 -0500 (EST)
Received: from lorc.wgcr.org (dial-39.r11.ncbrvr.infoave.net [207.144.78.103])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id VAA15995;
Tue, 7 Dec 1999 21:44:55 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Daniel.Veillard@w3.org, Daniel Veillard <Daniel.Veillard@w3.org>
Subject: Re: [HACKERS] perl-DBD-Pg (was Re: BOUNCE pgsql-ports@postgreSQL.org:
Non-member submission from[Joe Brenner
<doom@kzsu.stanford.edu>] (fwd))
Date: Tue, 7 Dec 1999 21:46:40 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Joe Brenner <doom@kzsu.stanford.edu>, pgsql-hackers@postgresql.org,
Ian Macdonald <ian@caliban.org>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Vince Vielhaber <vev@michvhf.com>, ianmacd@xs4all.nl,
Daniel.Veillard@w3.org
References: <199912021141.DAA28586@kzsu.stanford.edu>
<38469062.F85D1726@wgcr.org> <19991204090954.C32494@w3.org>
In-Reply-To: <19991204090954.C32494@w3.org>
MIME-Version: 1.0
Message-Id: <99120721475700.07034@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Sat, 04 Dec 1999, Daniel Veillard wrote:

On Thu, Dec 02, 1999 at 10:29:38AM -0500, Lamar Owen wrote:

This is something that the rpmfind.net maintainer needs to know about.
So, I've cc:'d him (Daniel Veillard). Daniel, the problem is that the
CPAN archive under the redhat powertools is not indexed or searched
under rpmfind.net's RPM database. This has caused some confusion
relating to the perl-DBD-Pg RPM package, which is in the CPAN part of
powertools.

Ok, I will try to get this fixed by tomorrow,

Looks good. Thanks for doing that -- and for the excellent rpmfind resource!

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

From bouncefilter Wed Dec 8 01:29:19 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA11830
for <hackers@postgreSQL.org>; Wed, 8 Dec 1999 01:28:31 -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 BAA25767;
Wed, 8 Dec 1999 01:27:53 -0500 (EST)
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Table aliases in delete statements?
In-reply-to: Your message of Tue, 7 Dec 1999 22:38:08 +0000 (GMT)
<199912072238.WAA08259@mtcc.demon.co.uk>
Date: Wed, 08 Dec 1999 01:27:53 -0500
Message-ID: <25765.944634473@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Keith Parks <emkxp01@mtcc.demon.co.uk> writes:

Is there any reason for not allowing table aliases in
delete statements?

Not much, I suppose, but it's not in SQL92:

<delete statement: searched> ::=
DELETE FROM <table name>
[ WHERE <search condition> ]

The expansion of <table name> doesn't mention anything about aliases.

As Bruce points out in another followup, there's no real need for
an alias for the target table; if you have sub-selects that need
independent references to the target, you can always alias *them*.
The same goes for INSERT and UPDATE, which also take unadorned
<table name> as the target table specification.

regards, tom lane

From bouncefilter Wed Dec 8 02:24:15 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 CAA16018
for <hackers@postgreSQL.org>; Wed, 8 Dec 1999 02:23:38 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id QAA00568;
Wed, 8 Dec 1999 16:23:06 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id QAA31369;
Wed, 8 Dec 1999 16:23:04 +0900
To: tgl@sss.pgh.pa.us
Cc: peter_e@gmx.net, hackers@postgreSQL.org
Subject: Re: [HACKERS] Multibyte in autoconf
In-Reply-To: Your message of "Tue, 07 Dec 1999 10:04:52 -0500"
<23258.944579092@sss.pgh.pa.us>
References: <23258.944579092@sss.pgh.pa.us>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991208162304M.t-ishii@sra.co.jp>
Date: Wed, 08 Dec 1999 16:23:04 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 29

OK, so the proposal is

configure: --enable-mb
Enables compilation of MULTIBYTE code, does not select a default

Agreed.

initdb: --pgencoding=FOO
Establishes coding of database; it's an error to specify non-
default encoding if MULTIBYTE wasn't compiled.

Agreed.

If no --pgencoding, you get default (non-multibyte) coding even
if you compiled with --enable-mb.

Not agreed. I think it would be better to give an error if no default
encoding is not sepecified if configured with --enable-mb. Reasons:

1) Users tend to use only one encoding rather than switching multiple
encoding database. Thus major encoding for the user should be properly
set as the default.

2) if non-multibyte coding such as SQL_ASCII is accidently set as the
default, and if a multi-byte user create a database with no encoding
arugument, the result would be a disaster.
--
Tatsuo Ishii

From bouncefilter Wed Dec 8 02:40:15 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA18151
for <hackers@postgreSQL.org>; Wed, 8 Dec 1999 02:39:16 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
CAA22563;
Wed, 8 Dec 1999 02:36:22 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912080736.CAA22563@candle.pha.pa.us>
Subject: Re: [HACKERS] Multibyte in autoconf
In-Reply-To: <19991208162304M.t-ishii@sra.co.jp> from Tatsuo Ishii at "Dec 8,
1999 04:23:04 pm"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Wed, 8 Dec 1999 02:36:22 -0500 (EST)
CC: tgl@sss.pgh.pa.us, peter_e@gmx.net, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

encoding database. Thus major encoding for the user should be properly
set as the default.

2) if non-multibyte coding such as SQL_ASCII is accidently set as the
default, and if a multi-byte user create a database with no encoding
arugument, the result would be a disaster.

Tatsuo, glad you are handling the multi-byte issues. Most of us are
clueless about it.

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

From bouncefilter Wed Dec 8 02:49:15 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 CAA19415
for <pgsql-hackers@hub.org>; Wed, 8 Dec 1999 02:49:05 -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 CAA25907;
Wed, 8 Dec 1999 02:47:55 -0500 (EST)
To: Daniel Kalchev <daniel@digsys.bg>
cc: pgsql-hackers@hub.org
Subject: Re: (resolution?) Re: [HACKERS] memory problem again
In-reply-to: Your message of Tue, 07 Dec 1999 18:13:42 +0200
<199912071613.SAA17598@dcave.digsys.bg>
Date: Wed, 08 Dec 1999 02:47:55 -0500
Message-ID: <25905.944639275@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Daniel Kalchev <daniel@digsys.bg> writes:

I run the postmaster after unlimit, which sets limits thus:
datasize 262144 kbytes

Oh well, so much for the small-DSIZ theory. But I still don't much
care for the other theory (sort ignores -S) because (a) I can't
reproduce any such behavior here, (b) I've been through that code
recently and didn't see anything that looked like it would cause
that behavior, and (c) if it were true then we ought to be seeing
more complaints.

I think there's probably some platform-specific issue that's causing
the misbehavior you see, but I'm at a loss to guess what it is.
Anyone have any ideas?

BTW, this postgres is compiled with default of 64 backends - I saw recently
note here that this may interfere with the -S option somehow....

I must've missed that --- I don't know any reason for number of backends
to interfere with -S, because -S just sets the amount of memory that
any one backend thinks it can expend for local working storage (per
sort or hash node). Can you recall where/when this discussion was?

(another not related bug, but still on memory allocation)
Still - this does not explain why postgres cannot allocated more than
76 MB (according to top) on BSD/OS (never did, actually - any previous
version too), while a simple malloc(1 MB) loop allocates up to the
process limit.

That does seem odd. Could it be that the shared memory segment used
by Postgres gets placed at 64M or so in your process's virtual address
space, thus preventing the malloc arena from expanding past that point?
If so, is there anything we can do to force a higher placement?

Maybe at some time postrges tries to allocate 'larger' chunk, which
the BSD/OS malloc does not like?

There is some code in aset.c that asks for larger and larger chunks,
but it should fall back to asking for a smaller chunk if it can't
get a bigger one. More to the point, the sort operation invoked by
SELECT DISTINCT shouldn't ask for more than (roughly) your -S setting.
So I'm still clueless where the problem is :-(

regards, tom lane

From bouncefilter Wed Dec 8 03:26:15 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 DAA27718
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Dec 1999 03:25:26 -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 DAA25960;
Wed, 8 Dec 1999 03:23:52 -0500 (EST)
To: Kyle Bateman <kyle@actarg.com>
cc: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Raising funds for PostgreSQL
In-reply-to: Your message of Tue, 07 Dec 1999 10:22:01 -0700
<384D4239.16EC24@actarg.com>
Date: Wed, 08 Dec 1999 03:23:52 -0500
Message-ID: <25958.944641432@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Kyle Bateman <kyle@actarg.com> writes:

[ lots of good thoughts snipped ]

2. Take bids from the development team in advance on each feature. In
other words, how many dollars would they need to start on the
enhancement today.

I don't think that's very practical; the "bids" will be changing
constantly. For one thing, many user-level features will change in
difficulty depending on what other things have been completed.
For another, a developer might unexpectedly find himself with spare time
on his hands ... or a sudden need for cash ;-) ... which might induce
him to pick up some feature request that he hadn't been excited about
doing before. In the terms you're using that'd correspond to an
unpredictable drop in the bid price.

Before I comment too much on this topic I should probably mention that
I have myself engaged in exactly this kind of transaction: a few months
ago, someone who need not be named here sent me a couple hundred bucks
in return for my dealing with a Postgres problem that they needed fixed
pronto (ie, within a week or two). It was something I would have fixed
anyway, eventually, but it was worth their cash to encourage me to deal
with that issue sooner rather than later. So I've certainly got no
moral objection to arrangements like this.

But I do have a practical concern, which is that bidding like this might
distort the development process, for example by tempting someone to put
in a quick-and-dirty hack that would provide the requested feature and
yet cause trouble down the line for future improvements. In the long
run that's not good for the health of the project.

I'm not sure how to answer that concern. One possible answer is to
put a cap on the amounts bid --- a person's judgment is less likely
to be swayed in the wrong direction by $$ than $$$$$$, no? But the
cap would probably have to vary depending on the difficulty of the
proposed feature. I don't think we want to get into spending a lot
of effort on cost-estimating everything that's on the TODO list,
so administering a bid cap might well be impractical.

Maybe there's a better answer. No good ideas at the moment...

regards, tom lane

From bouncefilter Wed Dec 8 03:27:15 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 DAA27814
for <pgsql-hackers@hub.org>; Wed, 8 Dec 1999 03:26:16 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id RAA10542
for <pgsql-hackers@hub.org>; Wed, 8 Dec 1999 17:26:15 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id RAA00543
for <pgsql-hackers@hub.org>; Wed, 8 Dec 1999 17:26:15 +0900
To: pgsql-hackers@hub.org
Subject: FreeBSD problem under heavy load
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991208172614V.t-ishii@sra.co.jp>
Date: Wed, 08 Dec 1999 17:26:14 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 65

I seem to run into a serious problem. With 6.5.x + FreeBSD 3.2, I get
a core under heavy load (16 or more concurrent users). FreeBSD 2.2.x
seems more stable but soon or later same thing happens. Examing a
core, I found it segfaulted in hash_search(). It was not possible to
get more info having a -g compiled backend becasue it did not fail if -
g was given. It is likely that random memory corruptions occured. It
is also reported by a user that he often sees:

NOTICE: LockReplace: xid table corrupted

Note that these problems never happen on Linux (even running 128 users
are ok on Linux). Only FreeBSD is suffered as far as I can see(not
sure about other *BSD). Increasing shmem or semaphore never helps.

How to reproduce the problem:

1) obtain pgbench source from
ftp.sra.co.jp/pub/cmd/postgres/pgbench/pgbench-1.1.tar.gz

2) unpack the archive and run configure

3) edit the first line in Makefile

POSTGRESHOME = /usr/local/pgsql

4) make. you will get an executable "pgbench" there.

5) make a fresh DB (suppose it is "test")

6) initialize DB

pgbench -i test

this will take for a while

7) run the test

pgbench -n -c numeber_of_concurrent users test

I see problems with numeber_of_concurrent users ~ 16 or more.

Here are my shmem settings:

shminfo:
shmmax: 41943041 (max shared memory segment size)
shmmin: 1 (min shared memory segment size)
shmmni: 32 (max number of shared memory identifiers)
shmseg: 8 (max shared memory segments per process)
shmall: 10240 (max amount of shared memory in pages)

seminfo:
semmap: 40 (# of entries in semaphore map)
semmni: 32 (# of semaphore identifiers)
semmns: 256 (# of semaphores in system)
semmnu: 30 (# of undo structures in system)
semmsl: 256 (max # of semaphores per id)
semopm: 100 (max # of operations per semop call)
semume: 10 (max # of undo entries per process)
semusz: 92 (size in bytes of undo structure)
semvmx: 32767 (semaphore maximum value)
semaem: 16384 (adjust on exit max value)

Any thoughts?
--
Tatsuo Ishii

From bouncefilter Wed Dec 8 03:35:16 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 DAA29001
for <hackers@postgreSQL.org>; Wed, 8 Dec 1999 03:34:19 -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 DAA26013;
Wed, 8 Dec 1999 03:33:36 -0500 (EST)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: peter_e@gmx.net, hackers@postgreSQL.org
Subject: Re: [HACKERS] Multibyte in autoconf
In-reply-to: Your message of Wed, 08 Dec 1999 16:23:04 +0900
<19991208162304M.t-ishii@sra.co.jp>
Date: Wed, 08 Dec 1999 03:33:36 -0500
Message-ID: <26011.944642016@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

If no --pgencoding, you get default (non-multibyte) coding even
if you compiled with --enable-mb.

Not agreed. I think it would be better to give an error if no default
encoding is not sepecified if configured with --enable-mb.

OK, I could live with that too. I think Peter's main point is that
there's no good reason to select a particular encoding at configure
time, even just as a "default". It'll be less confusing if initdb time
is the *only* time where you specify the particular MULTIBYTE encoding
you want.

regards, tom lane

From bouncefilter Wed Dec 8 04:17:16 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 EAA35146
for <pgsql-hackers@hub.org>; Wed, 8 Dec 1999 04:17:07 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id SAA20856
for <pgsql-hackers@hub.org>; Wed, 8 Dec 1999 18:17:06 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id SAA01637
for <pgsql-hackers@hub.org>; Wed, 8 Dec 1999 18:17:05 +0900
To: pgsql-hackers@hub.org
Subject: Re: [HACKERS] FreeBSD problem under heavy load
In-Reply-To: Your message of "Wed, 08 Dec 1999 17:26:14 +0900"
<19991208172614V.t-ishii@sra.co.jp>
References: <19991208172614V.t-ishii@sra.co.jp>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991208181705H.t-ishii@sra.co.jp>
Date: Wed, 08 Dec 1999 18:17:05 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 71

Note that same phenomen happens on current too.
--
Tatsuo Ishii

Show quoted text

I seem to run into a serious problem. With 6.5.x + FreeBSD 3.2, I get
a core under heavy load (16 or more concurrent users). FreeBSD 2.2.x
seems more stable but soon or later same thing happens. Examing a
core, I found it segfaulted in hash_search(). It was not possible to
get more info having a -g compiled backend becasue it did not fail if -
g was given. It is likely that random memory corruptions occured. It
is also reported by a user that he often sees:

NOTICE: LockReplace: xid table corrupted

Note that these problems never happen on Linux (even running 128 users
are ok on Linux). Only FreeBSD is suffered as far as I can see(not
sure about other *BSD). Increasing shmem or semaphore never helps.

How to reproduce the problem:

1) obtain pgbench source from
ftp.sra.co.jp/pub/cmd/postgres/pgbench/pgbench-1.1.tar.gz

2) unpack the archive and run configure

3) edit the first line in Makefile

POSTGRESHOME = /usr/local/pgsql

4) make. you will get an executable "pgbench" there.

5) make a fresh DB (suppose it is "test")

6) initialize DB

pgbench -i test

this will take for a while

7) run the test

pgbench -n -c numeber_of_concurrent users test

I see problems with numeber_of_concurrent users ~ 16 or more.

Here are my shmem settings:

shminfo:
shmmax: 41943041 (max shared memory segment size)
shmmin: 1 (min shared memory segment size)
shmmni: 32 (max number of shared memory identifiers)
shmseg: 8 (max shared memory segments per process)
shmall: 10240 (max amount of shared memory in pages)

seminfo:
semmap: 40 (# of entries in semaphore map)
semmni: 32 (# of semaphore identifiers)
semmns: 256 (# of semaphores in system)
semmnu: 30 (# of undo structures in system)
semmsl: 256 (max # of semaphores per id)
semopm: 100 (max # of operations per semop call)
semume: 10 (max # of undo entries per process)
semusz: 92 (size in bytes of undo structure)
semvmx: 32767 (semaphore maximum value)
semaem: 16384 (adjust on exit max value)

Any thoughts?
--
Tatsuo Ishii

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