PostgreSQL 6.5.2

Started by Tatsuo Ishiiover 26 years ago5 messages

Tatsuo Ishii

t-ishii@sra.co.jp

over 26 years ago

Are we going to release 6.5.2? If yes, then when?
---
Tatsuo Ishii

Tom Lane

tgl@sss.pgh.pa.us

over 26 years ago

In reply to: Tatsuo Ishii (#1)

Re: [HACKERS] PostgreSQL 6.5.2

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

Are we going to release 6.5.2? If yes, then when?

Marc proposed Sept 1 (back on 8/15), and there were no objections...

regards, tom lane

Import Notes

Reply to msg id not found: YourmessageofSun29Aug1999214524+0900199908291245.VAA00668@ext16.sra.co.jp | Resolved by subject fallback

The Hermit Hacker

scrappy@hub.org

over 26 years ago

In reply to: Tom Lane (#2)

Re: [HACKERS] PostgreSQL 6.5.2

On Sun, 29 Aug 1999, Tom Lane wrote:

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

Are we going to release 6.5.2? If yes, then when?

Marc proposed Sept 1 (back on 8/15), and there were no objections...

And its still the date I'm planning around...So Wednesday this week :)

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

Tatsuo Ishii

t-ishii@sra.co.jp

over 26 years ago

In reply to: The Hermit Hacker (#3)

Re: [HACKERS] PostgreSQL 6.5.2

On Sun, 29 Aug 1999, Tom Lane wrote:

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

Are we going to release 6.5.2? If yes, then when?

Marc proposed Sept 1 (back on 8/15), and there were no objections...

And its still the date I'm planning around...So Wednesday this week :)

Marc,

Could you make a tarball of 6.5.2-beta or 6.5.2-release-candidate or
whatever so that volunteers could get it by anon ftp for testing?
--
Tatsuo Ishii

Import Notes

Reply to msg id not found: YourmessageofSun29Aug1999163929-0300.Pine.BSF.4.10.9908291638520.4130-100000@thelab.hub.org | Resolved by subject fallback

The Hermit Hacker

scrappy@hub.org

over 26 years ago

In reply to: Tatsuo Ishii (#4)

Re: [HACKERS] PostgreSQL 6.5.2

Try her out...just put up a release candidate now...

On Mon, 30 Aug 1999, Tatsuo Ishii wrote:

On Sun, 29 Aug 1999, Tom Lane wrote:

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

Are we going to release 6.5.2? If yes, then when?

Marc proposed Sept 1 (back on 8/15), and there were no objections...

And its still the date I'm planning around...So Wednesday this week :)

Marc,

Could you make a tarball of 6.5.2-beta or 6.5.2-release-candidate or
whatever so that volunteers could get it by anon ftp for testing?
--
Tatsuo Ishii

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

From bouncefilter Mon Aug 30 13:54:51 1999
Received: from px.com.br ([200.253.250.2])
by hub.org (8.9.3/8.9.3) with SMTP id NAA79529
for <pgsql-hackers@postgresql.org>;
Mon, 30 Aug 1999 13:54:21 -0400 (EDT)
(envelope-from rcoelho@px.com.br)
Received: from [200.253.250.12] by px.com.br (AIX 4.1/UCB 5.64/4.03)
id AA16050; Mon, 30 Aug 1999 14:52:17 -0300
Message-Id: <001f01bef310$bb477000$0cfafdc8@px.com.br>
From: "Ricardo Coelho" <rcoelho@px.com.br>
To: <denny@namsi.com>
Cc: <pgsql-hackers@postgresql.org>
References: <37CAAB4C.2EFA8C28@namsi.com>
Subject: Re: HELP Re: pg_group, etc..
Date: Mon, 30 Aug 1999 14:54:35 -0300
Organization:
Mime-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi Denny,

I solved this problem (backend crashes when we delete a group without
revoking privileges) adding the group again with the same grosysid, revoking
all privileges on all tables and deleting this group.

Best Regards,

Ricardo Coelho.

----- Original Message -----
From: D Herssein <denny@namsi.com>
To: Ricardo Coelho <rcoelho@px.com.br>
Sent: Monday, August 30, 1999 1:03 PM
Subject: HELP Re: pg_group, etc..

I just read your post AFTER I sent the HELP request to the group.
I must have deleted the group/user in the wrong order while playing with
the db trying to learn how to gran group access to users.
How do I get myself back to normal?

--
Life is complicated. But the simpler alternatives are not very
desirable. (R' A. Kahn)

From bouncefilter Mon Aug 30 13:56:52 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id NAA79591
for pgsql-hackers@postgresql.org; Mon, 30 Aug 1999 13:54:57 -0400 (EDT)
(envelope-from news)
Date: Mon, 30 Aug 1999 13:54:57 -0400 (EDT)
From: "Hub.Org News Admin" <news>
Message-Id: <199908301754.NAA79591@hub.org>
X-Authentication-Warning: hub.org: news set sender to <news> using -f
To: undisclosed-recipients:;

From bouncefilter Mon Aug 30 13:55:51 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA79902
for <pgsql-hackers@postgresql.org>;
Mon, 30 Aug 1999 13:55:39 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id OAA23508
for <pgsql-hackers@postgresql.org>;
Mon, 30 Aug 1999 14:55:45 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 30 Aug 1999 14:55:44 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: bouncefilter added to majordomo lists ...
Message-ID: <Pine.BSF.4.10.9908301453550.8660-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

growing tired of the ever increasing "User Unknown" or "Host Unreachable"
messages, I've implemented 'bouncefilter2' on the majordomo lists, which
acts as a sort of 'inbetween' agent to catch, record and act on these
DSNs...

The goal is to reduce the overall processing required, and increase the
responsiveness of the lists by eliminating the queuing resulting from
these messages...

Let me know if you notice any unusual problems...

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

From bouncefilter Mon Aug 30 14:15:18 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id NAA79958
for pgsql-hackers@postgresql.org; Mon, 30 Aug 1999 13:56:00 -0400 (EDT)
(envelope-from news)
Date: Mon, 30 Aug 1999 13:56:00 -0400 (EDT)
From: "Hub.Org News Admin" <news>
Message-Id: <199908301756.NAA79958@hub.org>
X-Authentication-Warning: hub.org: news set sender to <news> using -f
To: undisclosed-recipients:;

From bouncefilter Tue Aug 31 12:41:09 1999
Received: from fandango.cs.unitn.it (root@fandango.cs.unitn.it
[193.205.199.228]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA95964
for <hackers@postgreSQL.org>; Tue, 31 Aug 1999 12:40:48 -0400 (EDT)
(envelope-from dz@wizard.net)
Received: from nikita.wizard.net (root@ts-slip38.gelso.unitn.it
[193.205.200.38]) by fandango.cs.unitn.it (8.8.5/8.6.9) with
ESMTP id SAA28059; Tue, 31 Aug 1999 18:56:17 +0200
Received: (from dz@localhost)
by nikita.wizard.net (8.9.2+3.1W/8.9.3/Debian/GNU) id WAA19560;
Mon, 30 Aug 1999 22:42:37 +0200 (MEST)
From: Massimo Dal Zotto <dz@wizard.net>
Message-Id: <199908302042.WAA19560@nikita.wizard.net>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <Pine.BSF.4.10.9908291638520.4130-100000@thelab.hub.org> from The
Hermit Hacker at "Aug 29, 1999 4:39:29 pm"
To: hackers@postgreSQL.org (PostgreSQL Hackers)
Date: Mon, 30 Aug 1999 22:42:37 +0200 (MEST)
Cc: scrappy@hub.org (The Hermit Hacker),
maillist@candle.pha.pa.us (Bruce Momjian), tgl@sss.pgh.pa.us
X-UIDL: 12257892_192897.483
X-Mailer: ELM [version 2.4ME+ PL48 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM936045757-19360-0_
Content-Transfer-Encoding: 7bit

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

On Sun, 29 Aug 1999, Tom Lane wrote:

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

Are we going to release 6.5.2? If yes, then when?

Marc proposed Sept 1 (back on 8/15), and there were no objections...

And its still the date I'm planning around...So Wednesday this week :)

May I ask that the patches I submitted two months ago for 6.5.0 are applied
at least to 6.5.2?

Here is the 6.5.1 version of my patches.

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

--ELM936045757-19360-0_
Content-Type: application/x-gzipped-tar
Content-Disposition: inline; filename="/tmp/pgsql-6.5.1-patches.tgz"
Content-Transfer-Encoding: base64

H4sIAHrryjcAA+w8a3faRtP5Sn7FmvZNwBZGEnfc5CnBSuIWGxdw2vRyOLJYg46FRHWx4zT+7+/M
7uqCENhO4qQX6/gYaS+j2ZnZmdnZWe2WH937Rapyo1EjjwhRGjU5+RteMiH1Rl2t1Wu1WhWe6zVZ
eURq94/ao0eB5+suIY8m7ze3u6n+H3oZju275unuQveN2T29Q5Hler26jv+q0pAVxn8orVXrFahW
lKr6iMj3hM/S9R/n//b2NhEyUD7Uz+mZadFdxzWnuaHukx8Cm5AasKgtt9qVKlFardbjUqm00iU3
mgWkE0yhBVHq7VqrrdR56+3lC59JRZYqNcIeEVhFlapVAnelx4TkUCbOzD3yOz5MHJvC7+MdYtrA
KMsqTRyjnYPn3JnjkonpQgXZ3iMTBzrs8N7mGfmNlCj59luoj1Akf+wRf0Zt3i73beGw86NWJKUu
b0e+/Z7sxTA4BjscA/LhA6HvTJ/IUALoGBbVbcCCZGJBbolFkvS66+pXNzKgtsqA5Y65l67J2KDK
RG62oVu1uoENLaR7xIZqRarVIjbkPIC/IECm/v7+waBYZncnPa3Iao0FKWHt8KfevvZyWBS32HAN
v3KcIBOS/7aw3+9i03yKJ0g2Dnh7F/qRqKHgRY5aHl3bVrw/bHtmcmZFI2gzxOfnyC7E/XtEdJUJ
7P/Y9Kmr+467a9yZGWkArC9jSpMo1bYKfKmtZ0pdUgRPYIDbhFp0Tm3fI84ZUoow4ES3J+zpQrcC
yp4MZ74IfLgnLvUCyye6xwFgM8uZmoZukf6AgLh2jvZDaBxJ07FFL2+XdXq8hT27zuIKhj7zScEo
IsINiRzqnmfOHbIP0H51fN8h303ef294u4Ft+vau6T/nb104rk8BRwfuPH/qUmAOqe9WdlVJn0yg
xjEn47PANvDlnkSU5q6yizSReP+Rc2rqHnmlnwIByHdT9vv9pfkeX1Q6ByyotTuh/G1M4gj5xrQN
K5hAc8O/WtDd2XPGHCBoI5Tqvw1Bu4ygrb8hQXcQ3R3WZWZ6xHPO/EvdhZF5oOdQJ5wGiEhgT6jL
hvzq6IS8ojaM2yLHwallGqRnGtT2KAdDTWjlkgvqekgXVUKSFWBKXDmBS5wFIlwEkl8RS/fjhrs3
sPbGiQtKgU/dnwHdI+eCTV21XWm0KxUmzTdPXQCRmrwVBf7WT15FSuhTRWqFctdhQhbCJQk+nV7d
RgR2PlZ2dlAVfw5GfjQXmQ6GP4aE5egT/RQEcO5MAviZgNWyqQeTzKaXYFZhQDiTIvqQy5lpzIgP
5g1A6HZiturEgxkIrhubspIgLo3LnYWgtnPBB7gkMhNo65tzeqPNra+q+ZW+abMLUtZ6MLu3NbsR
OcObWI+tt76b2JIFZ9UIK5UNLJIUJTbCQoOiADMXLpRalNlYVNETxGmEb2YSimjgP52gztpsWpu3
tgQcQIzMx0xn8nn0MvPdkVKRdb1XSt3VZiYo9UnK7zNR67YiH9mtIQg8SmxFRqEHu6UypdK8tdBn
m68N6zJFqiTNlyJzzu4ApTnwmIm7/3CbxHTUAZnpF5Rcuqbvgzb0HBihENWEpK6RUmGbDN0GSKeU
BB73z+g739UNn8wACWlu2jAiT/IoMGwCAF1nziEyswUOAEK+orqLftocmDqTJmDhWDudvXIXaEU5
jXTLc6CUsXlinp1BsW1w5CLGLMnZ3PSMwDetG61cc1WdrvRNW7lKu7ppjf9g5bJZgTdjvNtg3Tax
I9k/Nb2rrXZV3mTVWjcbNQRPLUu3qRN45DhebOArTf8qqQI+j0EjX9ugcTvWutmMfTJt7mzCvjpt
bhLh9daKC3HzRiFetVJqC1zoWy+ymiHfDpe4s8ISpsxjnv2jDRhbUf0ZUPdqbJlz0y/YxbS+QWTs
6U2KP1QXSSaleqbVfnWjC/Gg9jPZwH/GprNW52/gRKLz6kzZuNK81TKmW7LMcxBhexH4ZSfw4Qcx
CKXShSLWDucPR+U/vZb5fOT6Fy1oViR1vV2oVlbtQlb39NJFbasbfJu1S5chg0lMJ4w5IV9EDNX7
0/pHm4FwHQMLBNBhQhZjgwdLk2hhogOWwannm37AwtMiXg361J7oLixcYNkCkFZgwMCn1E/ExrEj
tIU5QS1Y0CyAujhU02ZtgLhzHQGxlyKpu9Ek4LQC/e1ceqyxeBlARFNmwpwRgQH6joe7l0QMILqW
Y5zHhmlVhyb85tXmKTtWa1cbD3bstnYsIifejPFu/fKlmrF8yey/Gp2QN7CkKilqYmcsK6AsgbyC
uOJsuoRJReZXTA5K+D6e4kD0xcIy+UodY8IM1KlunFN7IoE0OxfmhOJcWaAIMgnmEOgFteB19rQE
U3AO4+LxZfMCd4NwNP9Kk8hoHm+e/TNo/i+yq1nTJjatHzvxMgODm61r9r7WCcDkrPiP72R9zCT4
PDPgE/N/DOBGCRwFWDmX2ILyHjLBNud/EUVtsPy/WqWmVhRoSJSKrCgP+V9f4sLZ7blGWQhj2XDm
c3AJvTIKRmjhDx3uwxNYayrgwLerSqxoNvROdaw128qmuE5TUpNOPDxGWWFLOQC6YVDPK8+ovtDn
mAuQrPTh1WWYTD5W7MQVeVaB/2C6QWV+qdfZfOqmIWGMSp/MTTtdweJW5dPAtGCl54lkhFV3Ra5K
VbmV8CHlmlSNzSl6XJcztPGF1zCSUbCw6IH3RrfMScHHB/KM4BDHoFds8LgLgA1oOM+QiFwsMk/z
r9B3LPyEU7fLpnGRFeb4AysvFPfE+1hbxwS//ckTsnVq2rp7xX3WvzLHUG/UpXpTicdQb7SgIMqn
yVmw1LUdwFTeS4xnC5Pm7orhToxhCjOk/Rksv0m3f/x2fNwZdV9/qtp7uMRF57rhlS5017u/FOCb
9H9Nrgv9X60oah3zf2tK9UH/f4kr1P9CuZW5bsMdTLo7W3EzwceU5aVQ5dq+bLmN3RS0FW1ZaVc2
OJjNitSKQpXfgCkxz3KkDE75oNPVxq+jRLCycNZ7Dqbfgdia6IR5bVaa8/XT0qU58WdtUuUlRskE
nWn73JNKFJ/qnmmUnLMzj/pYzHx3zZ60hR+OY2vWpVZkgW6N1JtlpAhZwQoW55loYflNeKXtNac5
mipB+NW1AWdapZFtslcBZHBuQ8obM3Pxwvz6K/CpKjcAhSg8k4nC/XLla8/ij7/OXEpLzN0ozen8
fmzAZv0P6h/cvkj/11RcEcDvg/7/Ele2/sdVqG6FBgATaA/1KwKmGXVJIzrbkW0Aws5LeqTZlusb
o3tNWWomzoTgYxRmAO+XujY5ZoDDmXxI5457JQpfUX+5vMDLCUeGOcBLUNDlTkOIyzJ6s7UE80Jf
DjRtPDo57mnjQ+2wP3gLVaeOY4Esp2GH/jx/6jo2C50b/FeC5hg8x+0I9sucYG5nuDcMtgYWMuYc
E49EwH6uvzPnwZzYwfwUekKps6C2QBQTaTFuQC6dwJqw5CaR/s3C8aYNf6Zv6pZ1RTzzPe6LIEyB
te7NRiykYdo5zcY7XnGo2/qUuoXiZhMEKyjBelQkRqbogAioG81QCsiqCKnN9SKkNluS2kpEqrCg
Eq+4ctehddjIy7LIf1/DTMK2lcIk+e6MGud41kcPuUjEJoehi30Rncy5oAm+78bdy0J04OcTRQcg
sLVWDOAFBojIKfv/jLzWOscwwhe9fvfHQiH9smIImK/DAE7HAznyhz4MoiDeFWLEQBajli71A5hW
hQ6OeUh9RFWHdXHhCWtYeg42c1/3dSnClXW9XpX1Uupi8pbLpZEdUEZeLtgrff4mDm29KtUTa394
bMRy2D8ejYdvh73+KymHV5lNUOJdeZYzZdE/6rrwf049D6aexz1N1u11fzjq9fs/nhxLoidlU5XM
HM+39TnGBZ3zYIGCt/DGYNz8INl/+Lr/83F/MDo6OXyhDSQOwps5l0yFhGol3XnjfGFwVyokBtkH
scczK+hmhNOAjU/HtH4W5eDguSTwKAXgNj5+NQawB/2joRjmHAw17may4zc63Js+naP+o4AzH+D1
3t/PPW5UpEYzlgN4bEY5Brk853j+TlKQR05zJufvLgN55DWymnM6/3kkII/8HTN+jjmX85/Af+i3
LALQ5hNkQIQLMTbp2CxqyF68xkQp7VorWxTWwklLRFOcMFpjpRpSRU3YKHiM4mlxjNHzHReYXj4N
zhbwmx2CBILyHDpWu5lH6b6hl/Y8o05ovOcpFQ3QbQT/uvOGAT7sv9GWsHLplL4rJ1D6BjelM6nQ
ggV/Yl60mpIi16OJAXYC5NLci++5WPbPOr7Y7/HAqDH671PPKD23dd/3WPuXjjsfL6ZjPWxJtuF2
uTXWeXs3CDUa5lxuRbIBEkDn+0Teb5m674+9tEhjVPPU9MnWMxDtXk/ERrMIo1QUSanUE3HwSkvC
VVGUfJDLbZv2mTPXvXPygVv28evO8E1n0NOOOnuiDSaqjy1qT/0ZYAyVw4NftQIY4mAOrq4w6QWW
0/Gb+UexGPaDQc6dC1qYMJO9tr1EEi8o3kTK3KoyCCGREpm850oAmyGhVkn+5ImoXnEGQqekG7gu
LN2XvCUp7MSv0I8pknjU3GnCi2EVj29PlF8nOYkFpy7VzwWxDB31tfmeOmcFY6a7Io0CGMSOCTwj
IGcAjMnb6RXAJv/L5nm1ASyOjv2GCKODUygAzqgvkljvZeACtNcDy8fwxl3YKJrncglUgalZr7hm
/8XI2HgRK2g/1icTLgiFAu5VFgl/6zJIiSSIywS7XpGURiMp2F9q1GRltFvr5XfrdvK7tVl+tz5G
frduIb9ba+R3S8jv1lr5/ZwMTRtd+o4aAdiwsu1MaGc6XWNt1XZtjeO1CiBlZhW5rW5K4FKkpBaF
x6qyYmbz3N6By2WAQ0JTu4J5VPJzmN5u2bB08M083uDeDW1ZpDjBsF8GtnEA2p6I1RAh55QueP4c
9LY9k6XzxQl7aBowBw9LddcJ7Em2ylEw27WVVDmmdxRYlgKy8LLTG2rSUrEaFjPR4abxz0C3xvyc
O4pb7L2lF2Xhai4HA8BsQnQrKcOUH3RCFnOVoIAfoNaTKuFTsdo0rT/Jwm+tOK0fNexMF7GqSGo1
Ib1qtSmptYSqRB+6sLcX75ACSdgOMovgDC3HJ9sO+D4urCX8m61z35wgUdl8Hl0tqLB+nD5A6xdX
b1jyJ9vnTbk2IS+gMuZVzB5ZaOoIGyjTYG4fu45xBAQosIpjSwd9UsAf1EFIGa5UVmkDnqOadB0r
clWqVKpLZsSml4CweJMGw9LeLdyCPp269Kz03NddYIdEaBhNSVgftD9POPYS3uzjTnZoea5vdnMy
9X/CzfAuTUwGKuAIR/o0hVPSIWHOxWgMtsAD+xZ6MkleFAqsEui1Aqb03MAq5nTsRZ2F7l9+wRvd
jcFHEsDAQ1U28Avd9WMxSaGFNeypgHfmBMEVIsDF4g34sG8lrBswq9wuZqDEvgyAH/e4zZgZmAE9
y3yNeAtUZ74IHm/7GpS6dbTFumziItVgQn5e4kaOUnb1dZa7G6paEGkxxTFrJEQY7KENZV4xnD04
m0w7oHuoC82p7bi4Ujc9sc7np74xODqdijDyqtGuVaRKLTm5my2pKlfTPiLO0sLL+dRlZPGY2+JO
PSmcumo0ZUUgs7CVrrjm4cs7rlqEYgGS2KDJYsbcbhFDtuIe8PRZ1zQcs6LIrcml1jWidt2q5jri
NrgeX3tL6uH6gtfC+9MqgSqYYCbXPaUA3ZT/Iyu1KP+zrmD+p6rK9Yf93y9xRes20y6jLLB/66Pk
zdRibbkXO+zFVmgV4Gq7Um3LG750pjYbNUltNuXkhh0vSni6iz89sCVg74YHrw6ORhKZ6TYsTsdQ
CpqvuMd0NEt2d6xSlzx7Tng2Mw8HC/V+MtTGA62z3zs40hhUj/o+O5QEVmwgpB+sq8IVpFCebCMQ
bc02GYozUCyJ2+CrK4y0S/FBp4XuerijustOBroGDAGMQghBmAa+yF64zpTF6Z/h4ShjBq6pO734
Tf5DIkPteNx93RmEqtrFtQzHbyy6FKLu/yPh7Y5C2kQAEV2vo6SlcOtTEON4+FNv3On93Hk7HL/S
RuPjznD4c3+wP3zQ/P+9CyZCKUzPuq8M0Bvyf+qVWvj9V6XaAI0B+l+uNR70/5e40nG7KIM/EopE
4O6HwCKkgan8lXq7WrvhDEAMYekcgIpHL9UNp9YVMAEJm4CP6mrkbvU1qeBdOkt/XWiP+c82Rujy
S+cFliJ0y1VgAHTLmZYX07E30yfOZRq62Cp8pxvpkwYhWIxShVVMKx+e9EYHL96OtEya1NSGVEtu
G9bUllRrRt++CLMwRoMTFgu7RqvoUpjdY/xa0HvHpoWiSFhNZLhEUa4oGwVjVKYRJqWgTaPjOBhW
YFEFwq0YW3VGiScsb98LFtTFDKRCFMmgQKiCNhj0BxLJ922LH4zy+DGpqD2eI74wLTql7NQy4J0I
weW5RWNrVI5RiE4UtBYfAcTh88ZhVkpUItZ7y+PDbe/k8C4ccxKNiFWGNXeByum+DuwXIhR6DUkc
5M0jCEWCHccg7KMiG2Ui+fGR9ULBWvWwEdsMc0weqrgzi5JvWyImI9pRf3TQ1YBqiWaYhfV/k7xE
YhTuzsK1r10al7wBLsbyM8PCd7/CbHPwGAPDjxKaj5EdrpetNep1qdZIHt9RValeqcQJcRLfiEaX
OP8LaKsDz+lh8jMQjvM5WShxZiwXcUoly5gIsjgFF+x8QkClFZUipSehtDJ/VgAm+BJBTJRJK0Ij
rTI0PXzclpdI+v/jtH2MtqXw5lA37dA+4gfQ2dIH7GOjrdTa1TVpJBkQkodxYaFVq7VrG1KKmk2p
lTgn18TUiUriVBnLB5pgWozFUt8n1LC8SPdjOsWq+MaRsJ9OtMHbce/g8GDEW8N/TaDMuuDWLFcQ
0XQQsr8ElrW4ZaLfXS+RGBiiNQQPzmdl2evMmiyptURusVqHgnoreRCPH4xj+f3kOyKLmOaSSuZq
RbQB3YsBwFOMCE7Zedyk7mWfYkCICYo8R6iRCBtOYCOV4gZ74SqNbybFgpdcYr+m1iLMYkSfCh0y
RSWYwthoq+lDmas9U4JWBVnbcCBTbdWlihwd7cj9lWezKM/3S/JIBzewS+xzhtS+MF3Hxk9rs4PN
GDIVMWfePv/74y3yuz/QhtqI7HdG2nD0tqd96PaHozGmsPC7g6N97ZcPr7Sf+h9+HMK/3238nv7o
4FD7tX+kffil0x0dDPs97Y3W+9DtHWhHo7F21O3vHxy9+jDUBm+0QfScF7MbkL5wzmmINX8i3EML
Awfh9xaZhYW1/NR1MLuOS4ugQqgzvwIV4ky4D4np+bWJkyUyFXBLcTMummu8INrR/d3HgceDJKM+
+YaPg1fhoLHwaf/ot2ff/PH0w9P+y5dPky2QIqJFonZH1CaSBrENczeWGiQImGoRviAk6LrqQedo
iKTuHxEkd4fdMaqTp0Dmg07v4NfOi54G2GHMCUZ7CC8baftLYNIMOuocahxn7aQ7/uEYeg9/OBjC
Dz53j8TNjwNxM/r5KROATC5UZakS7h8zNqNBjCT2/9u7ot60YSD8zL+IkCq1NKWQFlrKqgmN0SEN
OgGTmCqEKCQoEhBEwqQ+7L/v7uwkjnFptbFOle57Ajt2U/vOPp/vOzDWcyruFoyimxFVDBh+W33d
rhZ+GLmr5H2jYG2JIvSvoa8N1l7fi/1wGOiAsjrzE7ecVN2LSwfG4VpR3bcah3+osYcZnoIWJq+Q
3dO8XdKVC9sLmDTOhTlIXmmpnfOx0T7/r2M7V8quDF9r6TlfhJp22v1PjWan3R1/wVKRg00r3X9q
J4vjkIjjcOaL4HGCga7wzrksZPK4Q8J8X4pRtEkMj+Q30TmstQgmUYsCgR5Gda0SszmrdSDfsppo
TDM/xINFK3xaTZWmVEfZu/pPIGxLijTpBLNQeQaNy36wwStL6hjntVYB+7SsUbn+6CXj6VdfMKdF
6nTvW/0f3U+jv3vvgpFGgOSp83jaY7N/64p4tgoSlEDo1V9JeqkLXV8qN6V9dr9jX1/rMaJC3Kwl
UWI+WsPhUFj6OIa5nDrCTmkEBmf+yMuLqbFEdI86mFDvwYu5+ICoNY2b+pQIzpZDBxWVspNMPL6v
vMgpFF5NysEMIcgUTGLo9fUmS8rRPIu1m/K+fJja706V7NQyUSQhoqR2Hh10vMVkbluqh8NbRnax
WDzRxMeVjV54FN0IlHDcHQuihzhOibO0aIV3PXSYUJtknFHki9A7zXrGRFdhtLGFAoRwVNq4O410
L1G/fddtfB03enf9k1gTdoaxWrarVdWpYFfTPVaQ45Fm1vssbCPap1A3RWGj+a3Xvu+1B5IiRAQ1
GDyQgugJju6uSG1UnCqspSbe3UFr3Dnvvw9Ewxnei2Fj3LeDbSTarjfBVLSVzCS5IsRUGTqpeiTt
cJZTmVHviZBlXqCe5zklWuU847U38Jy0xamWEGNMMnFVsq8U1cKvaRhnHqdpPHMft/Pxxl34M2lZ
UbEQQTn/+dfJRD6e+7Gc+5jH9AqZyK8Cmv6UdWUUiXfEzTLNx2Wpal+WFdcfJUlIL1Jy00UQusee
WEckKRaXhNjlavZd43Lvx8xPCkL1b0t1y/+QJWxByelpxrGd+GiPwlvyy0L/dKEdPvgjW423jckX
v6TvyFIjoneSOVi7yRx03YD1L4KFcLJOP5l3b1CPStWsHsY+9M0nZRGaZqQM+2E53cB3aUr4iX5Z
4qHTGDYGg96IIumINUuJWNNHKYaYhEa6rRXnu9Z8GgQbN1yj/Q+ng7SLnzJy7jzZxUG6sLoupC4l
mE9SyhXOOOwjRdg3KMDi7HnDUahjQHFyQrcwfgJ5BI8YHBl7s8WfbuLSALYF2RTyX7ojK0ly9FfB
HK2TY7XwhDy0dXQohmt36oNgrIIzeG7pLmUGMRxxaYL874tWBoPBYDAYDAaDwWAwGAwGg8FgMBgM
BoPBYDAYDAaDwWAwGIwD4Td8TvZCAKAAAA==

--ELM936045757-19360-0_

--ELM936045757-19360-0_--

From bouncefilter Mon Aug 30 16:54:53 1999
Received: from remote.org (mail@visby.remote.org [212.227.14.25])
by hub.org (8.9.3/8.9.3) with SMTP id QAA13533
for <pgsql-hackers@postgresql.org>;
Mon, 30 Aug 1999 16:54:34 -0400 (EDT) (envelope-from sqrt@remote.org)
Received: from localhost by remote.org with local
id 11LYRj-0002fa-00; Mon, 30 Aug 1999 22:54:31 +0200
Message-ID: <19990830225430.A10255@remote.org>
Date: Mon, 30 Aug 1999 22:54:30 +0200
From: pgsql-hackers@mail.remote.org
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Quoting in stored procedures
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2i
Sender: Jochen Topf <sqrt@remote.org>

and why not something like:

CREATE FUNCTION first_word ( :x CHAR VARYING(1000) )
RETURNS CHAR VARYING(40)
LANGUAGE SQL
RETURN TRIM (SUBSTRING ((:X || ' ') FROM 1 FOR POSITION (' ' IN (:X || '')
)));

as described in SQL/PSM (SQL Persistent Stored Modules) (see "A Guide To The
SQL Standard" apendix E)
instead of re-invent the wheel. ;)

Because the SQL parser has to parse the stored procedure to find the end. In
postgres you can have embedded tcl and any arbitrary language, so it is quite
difficult to handle that properly.

jochen

From bouncefilter Mon Aug 30 17:21:53 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id QAA13570
for pgsql-hackers@postgresql.org; Mon, 30 Aug 1999 16:54:58 -0400 (EDT)
(envelope-from news)
Date: Mon, 30 Aug 1999 16:54:58 -0400 (EDT)
From: "Hub.Org News Admin" <news>
Message-Id: <199908302054.QAA13570@hub.org>
X-Authentication-Warning: hub.org: news set sender to <news> using -f
To: undisclosed-recipients:;

From bouncefilter Mon Aug 30 17:20:53 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 RAA18233
for <hackers@postgreSQL.org>; Mon, 30 Aug 1999 17:20:23 -0400 (EDT)
(envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max02-047.enterprise.net
[194.72.195.167])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id WAA19921;
Mon, 30 Aug 1999 22:20:12 +0100 (GMT/BST)
Received: from linda.lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian/GNU) with ESMTP id WAA01119;
Mon, 30 Aug 1999 22:19:57 +0100
Message-Id: <199908302119.WAA01119@linda.lfix.co.uk>
X-Mailer: exmh version 2.0.2 2/24/98 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: hackers@postgreSQL.org
cc: 43702@bugs.debian.org
Subject: Implications of multi-byte support in a distribution
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 30 Aug 1999 22:19:57 +0100
From: "Oliver Elphick" <olly@lfix.co.uk>

I have had a request to add multi-byte support to the Debian binary
packages of PostgreSQL.

Since I live in England, I have personally no need of this and therefore
have little understanding of the implications.

If I change the packages to use multi-byte support, (UNICODE (UTF-8) is
suggested as the default), will there be any detrimental effects on the
fairly large parts of the world that don't need it? Should I try to
provide two different packages, one with and one without MB support?

--
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
========================================
"For what shall it profit a man, if he shall gain the
whole world, and lose his own soul?" Mark 8:36

From bouncefilter Mon Aug 30 17:51:54 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id RAA18302
for pgsql-hackers@postgresql.org; Mon, 30 Aug 1999 17:20:59 -0400 (EDT)
(envelope-from news)
Date: Mon, 30 Aug 1999 17:20:59 -0400 (EDT)
From: "Hub.Org News Admin" <news>
Message-Id: <199908302120.RAA18302@hub.org>
X-Authentication-Warning: hub.org: news set sender to <news> using -f
To: undisclosed-recipients:;

From bouncefilter Mon Aug 30 18:03:55 1999
Received: from photox.jcmax.com (photox.jcmax.com [204.69.248.4])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA24459
for <hackers@postgresql.org>; Mon, 30 Aug 1999 18:03:02 -0400 (EDT)
(envelope-from cr@photox.jcmax.com)
Received: (from cr@localhost) by photox.jcmax.com (8.9.3/8.9.3) id SAA42454
for hackers@postgresql.org; Mon, 30 Aug 1999 18:03:01 -0400 (EDT)
(envelope-from cr)
Date: Mon, 30 Aug 1999 18:03:01 -0400 (EDT)
From: Cyrus Rahman <cr@photox.jcmax.com>
Message-Id: <199908302203.SAA42454@photox.jcmax.com>
To: hackers@postgresql.org
Subject: File descriptor leakage?

Has anyone seen a problem with postgresql-6.5.1 leaking file descriptors? I
am not sure what exact activity causes the problem, but e.g. using pgaccess
to inspect the database causes the following:

cr@photox% ps ax|grep postgres
425 ?? Ss 1:58.01 /usr/local/pgsql/bin/postmaster -i -S -o -F (postgres
78404 ?? I 0:00.96 /usr/local/pgsql/bin/postgres cr 127.0.0.1 cr idle

cr@photox% fstat -p 78404
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W
pgsql postgres 78404 root / 2 drwxr-xr-x 512 r
pgsql postgres 78404 wd /usr 389050 drwx------ 4096 r
pgsql postgres 78404 text /usr 334856 -r-xr-xr-x 1050936 r
pgsql postgres 78404 0 / 967 crw-rw-rw- null rw
pgsql postgres 78404 1 / 967 crw-rw-rw- null rw
pgsql postgres 78404 2 / 967 crw-rw-rw- null rw
pgsql postgres 78404 3 /usr 366283 -rw------- 245760 rw
pgsql postgres 78404 4 /usr 389846 -rw------- 24576 rw
pgsql postgres 78404 5* internet stream tcp ca0ba960
pgsql postgres 78404 6 /usr 389850 -rw------- 139264 rw
pgsql postgres 78404 7 /usr 389856 -rw------- 8192 rw
pgsql postgres 78404 8 /usr 389841 -rw------- 16384 rw
pgsql postgres 78404 9 /usr 389854 -rw------- 8192 rw
pgsql postgres 78404 10 /usr 389855 -rw------- 16384 rw
pgsql postgres 78404 11 /usr 389830 -rw------- 65536 rw
pgsql postgres 78404 12 /usr 389847 -rw------- 147456 rw
pgsql postgres 78404 13 /usr 389844 -rw------- 40960 rw
pgsql postgres 78404 14 /usr 389845 -rw------- 16384 rw
pgsql postgres 78404 15 /usr 366236 -rw------- 8192 rw
pgsql postgres 78404 16 /usr 366281 -rw------- 8192 rw
pgsql postgres 78404 17 /usr 389823 -rw------- 24576 rw
pgsql postgres 78404 18 /usr 389848 -rw------- 385024 rw
pgsql postgres 78404 19 /usr 389817 -rw------- 24576 rw
pgsql postgres 78404 20 /usr 389815 -rw------- 16384 rw
pgsql postgres 78404 21 /usr 389857 -rw------- 8192 rw
pgsql postgres 78404 22 /usr 389829 -rw------- 172032 rw
pgsql postgres 78404 23 /usr 389828 -rw------- 40960 rw
pgsql postgres 78404 24 /usr 389919 -rw------- 0 rw
pgsql postgres 78404 25 /usr 366280 -rw------- 8192 rw
pgsql postgres 78404 26 /usr 389821 -rw------- 32768 rw
pgsql postgres 78404 27 /usr 389827 -rw------- 139264 rw
pgsql postgres 78404 28 /usr 389826 -rw------- 57344 rw
pgsql postgres 78404 29 /usr 390476 -rw------- 8192 rw
pgsql postgres 78404 30 /usr 390488 -rw------- 8192 rw
pgsql postgres 78404 31 /usr 390176 -rw------- 8192 rw
pgsql postgres 78404 32 /usr 390547 -rw------- 8192 rw
pgsql postgres 78404 33 /usr 389913 -rw------- 8192 rw
pgsql postgres 78404 34 /usr 389929 -rw------- 8192 rw
pgsql postgres 78404 35 /usr 389853 -rw------- 16384 rw
pgsql postgres 78404 36 /usr 389852 -rw------- 16384 rw
pgsql postgres 78404 37 /usr 389819 -rw------- 8192 rw
pgsql postgres 78404 38 /usr 389818 -rw------- 16384 rw
pgsql postgres 78404 39 /usr 390217 -rw------- 8192 rw
pgsql postgres 78404 40 /usr 390360 -rw------- 8192 rw
pgsql postgres 78404 41 /usr 390361 -rw------- 16384 rw
pgsql postgres 78404 42 /usr 390379 -rw------- 32768 rw
pgsql postgres 78404 43 /usr 390218 -rw------- 16384 rw
pgsql postgres 78404 44 /usr 390234 -rw------- 16384 rw
pgsql postgres 78404 45 /usr 390255 -rw------- 16384 rw
pgsql postgres 78404 46 /usr 390276 -rw------- 16384 rw
pgsql postgres 78404 47 /usr 390297 -rw------- 32768 rw
pgsql postgres 78404 48 /usr 389678 -rw------- 32768 rw
pgsql postgres 78404 49 /usr 389823 -rw------- 24576 rw
pgsql postgres 78404 50 /usr 389856 -rw------- 8192 rw
pgsql postgres 78404 51 /usr 389841 -rw------- 16384 rw
pgsql postgres 78404 52 /usr 389854 -rw------- 8192 rw
pgsql postgres 78404 53 /usr 389855 -rw------- 16384 rw
pgsql postgres 78404 54 /usr 389830 -rw------- 65536 rw
pgsql postgres 78404 55 /usr 389848 -rw------- 385024 rw
pgsql postgres 78404 56 /usr 389815 -rw------- 16384 rw
pgsql postgres 78404 57 /usr 389857 -rw------- 8192 rw
pgsql postgres 78404 58 /usr 366281 -rw------- 8192 rw
pgsql postgres 78404 59 /usr 389828 -rw------- 40960 rw
pgsql postgres 78404 60 /usr 389929 -rw------- 8192 rw
pgsql postgres 78404 61 /usr 389853 -rw------- 16384 rw
pgsql postgres 78404 62 /usr 389852 -rw------- 16384 rw
pgsql postgres 78404 63 /usr 389819 -rw------- 8192 rw
pgsql postgres 78404 64 /usr 389818 -rw------- 16384 rw
pgsql postgres 78404 65 /usr 390360 -rw------- 8192 rw
pgsql postgres 78404 66 /usr 390361 -rw------- 16384 rw
pgsql postgres 78404 67 /usr 390379 -rw------- 32768 rw
pgsql postgres 78404 68 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 69 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 70 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 71 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 72 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 73 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 74 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 75 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 76 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 77 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 78 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 79 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 80 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 81 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 82 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 83 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 84 /usr 389832 -rw------- 0 rw
pgsql postgres 78404 85 /usr 389929 -rw------- 8192 rw
pgsql postgres 78404 86 /usr 389856 -rw------- 8192 rw
pgsql postgres 78404 87 /usr 389841 -rw------- 16384 rw
pgsql postgres 78404 88 /usr 389854 -rw------- 8192 rw
pgsql postgres 78404 89 /usr 389855 -rw------- 16384 rw
pgsql postgres 78404 90 /usr 389830 -rw------- 65536 rw
pgsql postgres 78404 91 /usr 389848 -rw------- 385024 rw
pgsql postgres 78404 92 /usr 389815 -rw------- 16384 rw
pgsql postgres 78404 93 /usr 366281 -rw------- 8192 rw
pgsql postgres 78404 94 /usr 389828 -rw------- 40960 rw
pgsql postgres 78404 95 /usr 389853 -rw------- 16384 rw
pgsql postgres 78404 96 /usr 389852 -rw------- 16384 rw
pgsql postgres 78404 97 /usr 389819 -rw------- 8192 rw
pgsql postgres 78404 98 /usr 389818 -rw------- 16384 rw
pgsql postgres 78404 99 /usr 390360 -rw------- 8192 rw
pgsql postgres 78404 100 /usr 390361 -rw------- 16384 rw
pgsql postgres 78404 101 /usr 390379 -rw------- 32768 rw
pgsql postgres 78404 102 /usr 389913 -rw------- 8192 rw
pgsql postgres 78404 103 /usr 389832 -rw------- 0 rw

cr@photox% foreach i (389855 389854 389848 389841 389830 390360)
? echo ${i}: `ls -i /usr/local/pgsql/data/base/cr | grep $i`
? echo ${i}: `fstat -p 78404 |grep $i | wc -l`
? end
389855: 389855 pg_amop
389855: 3
389854: 389854 pg_amproc
389854: 3
389848: 389848 pg_attribute_relid_attnam_index
389848: 3
389841: 389841 pg_index
389841: 3
389830: 389830 pg_operator
389830: 3
390360: 390360 users
390360: 3

What I see is that the backend opens many of the files associated with tables
(both user and system) many times. It is not so bad in this example with
pgaccess, but for long running processes I have backends with each table file
open dozens of times, consuming hundreds of file descriptors per hour of
run-time.

This is on FreeBSD 3.2-STABLE, using the 6.5.1 release of postgresql from the
ports collection.

Anyway, is it a known problem? Aside from being careful to not use a
particular copy of the backend too long, are there any fixes?

Thanks,

Cyrus Rahman

From bouncefilter Mon Aug 30 18:05:58 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id SAA24557
for pgsql-hackers@postgresql.org; Mon, 30 Aug 1999 18:04:01 -0400 (EDT)
(envelope-from news)
Date: Mon, 30 Aug 1999 18:04:01 -0400 (EDT)
From: "Hub.Org News Admin" <news>
Message-Id: <199908302204.SAA24557@hub.org>
X-Authentication-Warning: hub.org: news set sender to <news> using -f
To: undisclosed-recipients:;

From bouncefilter Mon Aug 30 20:03:55 1999
Received: from photox.jcmax.com (photox.jcmax.com [204.69.248.4])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA39150
for <pgsql-hackers@postgresql.org>;
Mon, 30 Aug 1999 20:03:18 -0400 (EDT)
(envelope-from cr@photox.jcmax.com)
Received: (from cr@localhost) by photox.jcmax.com (8.9.3/8.9.3) id UAA48008
for pgsql-hackers@postgresql.org; Mon, 30 Aug 1999 20:03:15 -0400 (EDT)
(envelope-from cr)
Date: Mon, 30 Aug 1999 20:03:15 -0400 (EDT)
From: Cyrus Rahman <cr@photox.jcmax.com>
Message-Id: <199908310003.UAA48008@photox.jcmax.com>
To: pgsql-hackers@postgresql.org
Subject: File descriptor leakage?

Has anyone seen a problem with postgresql-6.5.1 leaking file descriptors? I
am not sure what exact activity causes the problem, but e.g. using pgaccess
to inspect the database causes the following:

cr@photox% ps ax|grep postgres
425 ?? Ss 1:58.01 /usr/local/pgsql/bin/postmaster -i -S -o -F (postgres
78404 ?? I 0:00.96 /usr/local/pgsql/bin/postgres cr 127.0.0.1 cr idle

This is on FreeBSD 3.2-STABLE, using the 6.5.1 release of postgresql from the
ports collection.

Anyway, is it a known problem? Aside from being careful to not use a
particular instance of the backend too long, are there any fixes?

Thanks,

Cyrus Rahman

From bouncefilter Mon Aug 30 20:38:55 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id UAA39199
for pgsql-hackers@postgresql.org; Mon, 30 Aug 1999 20:04:00 -0400 (EDT)
(envelope-from news)
Date: Mon, 30 Aug 1999 20:04:00 -0400 (EDT)
From: "Hub.Org News Admin" <news>
Message-Id: <199908310004.UAA39199@hub.org>
X-Authentication-Warning: hub.org: news set sender to <news> using -f
To: undisclosed-recipients:;

From bouncefilter Mon Aug 30 21:51:56 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA53253
for <pgsql-hackers@postgreSQL.org>;
Mon, 30 Aug 1999 21:51:03 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA10230;
Mon, 30 Aug 1999 21:50:25 -0400 (EDT)
To: Cyrus Rahman <cr@photox.jcmax.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] File descriptor leakage?
In-reply-to: Your message of Mon, 30 Aug 1999 20:03:15 -0400 (EDT)
<199908310003.UAA48008@photox.jcmax.com>
Date: Mon, 30 Aug 1999 21:50:25 -0400
Message-ID: <10227.936064225@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Cyrus Rahman <cr@photox.jcmax.com> writes:

Has anyone seen a problem with postgresql-6.5.1 leaking file
descriptors?

That's interesting, I thought I'd fixed all the file-descriptor-leakage
problems. Guess not :-(

In addition to the files you list, there seem to be a whole bunch of
descriptors for 389832; can you find out what that is? (Check in
the top-level data directory as well as data/base/xxx.)

Can you generate a repeatable script that causes a particular file
to be opened more than once? This is going to be tough to track
down without a test case...

regards, tom lane

From bouncefilter Mon Aug 30 21:54:56 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA53447
for <pgsql-hackers@postgreSQL.org>;
Mon, 30 Aug 1999 21:54:01 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA10251
for <pgsql-hackers@postgreSQL.org>;
Mon, 30 Aug 1999 21:53:30 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Re: libpq drops error messages received just before backend crash
In-reply-to: Your message of Sun, 15 Aug 1999 22:56:30 -0400
<23527.934772190@sss.pgh.pa.us>
Date: Mon, 30 Aug 1999 21:53:29 -0400
Message-ID: <10249.936064409@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I wrote:

It turns out that this is a libpq deficiency: it's got the error
message, but because PQexec() was used, it's waiting around for
a 'Z' ReadyForQuery message before it hands the error message
back to the application. Since the backend crashes, of course
the 'Z' never comes ... and when libpq detects closure of the
connection, it wipes out the stored error message in its haste
to report
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
which is all that the user gets to see, unless he thinks to
look in the postmaster log. Boo hiss.

Although I forgot to mention it in the commit log entry, this problem
is fixed in the libpq changes I just committed to the current branch.

regards, tom lane

From bouncefilter Tue Aug 31 00:11:58 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 AAA74479
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 00:11:10 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id EAA13779;
Tue, 31 Aug 1999 04:09:38 GMT
Sender: lockhart@hub.org
Message-ID: <37CB5581.517CBD91@alumni.caltech.edu>
Date: Tue, 31 Aug 1999 04:09:37 +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: Brook Milligan <brook@biology.nmsu.edu>, Michael.Ansley@intec.co.za,
leon@udmnet.ru, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Postgres' lexer
References: <14978.935166666@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

But it'd be good to get an opinion from the other tgl first ;-).

Sadly, the former "tgl" ;)

Sorry, I was away on vacation. I've waded through ~300 mail messages
already, but have ~700 to go, so I apologize if I've missed some more
developments.

I added the <xm> exclusive state to accomodate the possibility of a
unary minus. The change was provoked by Vadim's addition of CREATE
SEQUENCE, which should allow negative numbers for some arguments. But
this just uncovered the tip of the general problem...

There are several cases which need to be handled (I'm doing this from
memory, so may miss a few):

o Positive and negative numbers as standalone arguments, with and
without spaces between the "-" and the digits.

o Positive and negative numbers as first arguments to binary
operators, with and without spaces at all possible places.

o Positive and negative numbers as second arguments to binary
operators, or as arguments to unary operators.

o Positive and negative numbers in the presence of operators
containing minus signs, including a trailing minus sign where
possible.

'taint easy to do it completely right. Perhaps trying to do less in
the scanner is the right thing to do, but istm that it may put
restrictions on the grammar which are not currently there. Not a good
trade for a longer query length...

- Thomas

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

From bouncefilter Tue Aug 31 00:46:59 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA81407
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 00:46:33 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id NAA04060; Tue, 31 Aug 1999 13:46:23 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>, "Cyrus Rahman" <cr@photox.jcmax.com>
Subject: RE: [HACKERS] File descriptor leakage?
Date: Tue, 31 Aug 1999 13:49:32 +0900
Message-ID: <002701bef36c$37985420$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: <10227.936064225@sss.pgh.pa.us>
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 Tom Lane
Sent: Tuesday, August 31, 1999 10:50 AM
To: Cyrus Rahman
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] File descriptor leakage?

Cyrus Rahman <cr@photox.jcmax.com> writes:

Has anyone seen a problem with postgresql-6.5.1 leaking file
descriptors?

That's interesting, I thought I'd fixed all the file-descriptor-leakage
problems. Guess not :-(

The following may be one of the cause.

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Vadim Mikheev
Sent: Monday, June 07, 1999 7:49 PM
To: Hiroshi Inoue
Cc: The Hermit Hacker; pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postgresql-v6.5beta2.tar.gz ...

[snip]

1. bug in cache invalidation code: when we invalidate relcache
we forget to free MdfdVec in md.c!

Vacuum invalidates a relation tuple in pg_class and concurrent
xactions invalidate corresponding relcache entry, but don't
free MdfdVec and so allocate new one for the same relation
more and more. Each MdfdVed requires own fd.c:Vfd entry -> below

2. fd.c:pg_nofile()->sysconf(_SC_OPEN_MAX) returns in FreeBSD
near total number of files that can be opened in system
(by _all_ users/procs). With total number of opened files
~ 2000 I can run your test with 10-20 simultaneous
xactions for very short time, -:)

Should we limit fd.c:no_files to ~ 256?
This is port-specific, of course...

I posted a patch about a month ago([HACKERS] double opens).
But yutaka tanida [yutaka@marin.or.jp] reported a bug caused
by the patch. I found it's because of calling smgrclose() after
smgrclose()/smgrunlink() for the same relation.

It seems my old patch has not been appiled yet.
Here is a new patch.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

*** utils/cache/relcache.c.orig	Mon Jul 26 12:45:15 1999
--- utils/cache/relcache.c	Mon Aug 30 15:37:10 1999
***************
*** 1259,1264 ****
--- 1259,1265 ----

oldcxt = MemoryContextSwitchTo((MemoryContext) CacheCxt);

+ smgrclose(DEFAULT_SMGR, relation);
RelationCacheDelete(relation);

  		FreeTupleDesc(relation->rd_att);
*** storage/smgr/md.c.orig	Mon Jul 26 12:45:09 1999
--- storage/smgr/md.c	Tue Aug 31 13:44:28 1999
***************
*** 190,195 ****
--- 190,197 ----

/* finally, clean out the mdfd vector */
fd = RelationGetFile(reln);
+ if (fd < 0)
+ return SM_SUCCESS;
Md_fdvec[fd].mdfd_flags = (uint16) 0;

  	oldcxt = MemoryContextSwitchTo(MdCxt);
***************
*** 211,216 ****
--- 213,219 ----
  	MemoryContextSwitchTo(oldcxt);

_fdvec_free(fd);
+ reln->rd_fd = -1;

  	return SM_SUCCESS;
  }
***************
*** 319,324 ****
--- 322,329 ----
  	MemoryContext oldcxt;

  	fd = RelationGetFile(reln);
+ 	if (fd < 0)
+ 		return SM_SUCCESS;

  	oldcxt = MemoryContextSwitchTo(MdCxt);
  #ifndef LET_OS_MANAGE_FILESIZE
***************
*** 370,375 ****
--- 375,381 ----
  	MemoryContextSwitchTo(oldcxt);

_fdvec_free(fd);
+ reln->rd_fd = -1;

  	return SM_SUCCESS;
  }
***************
*** 895,900 ****
--- 901,907 ----
  {

Assert(Md_Free < 0 || Md_fdvec[Md_Free].mdfd_flags == MDFD_FREE);
+ Assert(Md_fdvec[fdvec].mdfd_flags != MDFD_FREE);
Md_fdvec[fdvec].mdfd_nextFree = Md_Free;
Md_fdvec[fdvec].mdfd_flags = MDFD_FREE;
Md_Free = fdvec;

From bouncefilter Tue Aug 31 01:11:59 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 BAA84609
for <hackers@postgresql.org>; Tue, 31 Aug 1999 01:11:29 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id FAA13938;
Tue, 31 Aug 1999 05:11:06 GMT
Sender: lockhart@hub.org
Message-ID: <37CB63EA.376BF4E5@alumni.caltech.edu>
Date: Tue, 31 Aug 1999 05:11: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: Tom Lane <tgl@hub.org>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [COMMITTERS] pgsql/src/include/parser (parse_node.h parse_oper.h)
References: <199908232348.TAA44755@hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Modified Files:
parse_node.h parse_oper.h
Remove bogus code in oper_exact --- if it didn't find an exact
match then it tried for a self-commutative operator with the reversed input
data types. This is pretty silly; there could never be such an operator,
except maybe in binary-compatible-type scenarios, and we have oper_inexact
for that. Besides which, the oprsanity regress test would complain about
such an operator. Remove nonfunctional code and simplify routine calling
convention accordingly.

Ooh! That codes sounds familiar. What I was trying for was to cover
the case that, for example, (int4 < float4) was not implemented, but
that (float4 >= int4) was. If this is already handled elsewhere, or if
this goal is nonsensical, then cutting the defective code is the right
thing. But if the code just needed repairing, we should put it back in
and get it right next time...

- Thomas

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

From bouncefilter Tue Aug 31 02:48:00 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 CAA95279
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 02:47:08 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id GAA14030;
Tue, 31 Aug 1999 06:46:05 GMT
Sender: lockhart@hub.org
Message-ID: <37CB7A2C.E89A1653@alumni.caltech.edu>
Date: Tue, 31 Aug 1999 06:46:04 +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: Jernej Zajc <jernej@4u.net>
CC: Hannu Krosing <hannu@trust.ee>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] ANSI SQL compliance
References: <12194.935945289@sss.pgh.pa.us> <37C996DA.63E032CE@trust.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

is there any rough estimate of when Postgres ANSI SQL compliance
is planned to be implemented? Will it be in 6.6, 6.7, or later?

There isn't any master plan that says "we will have every single
SQL92 feature implemented by release N". (In fact, as far as I
can tell there's no master plan at all ;-).)

AFAIK there is no single dtatbase, commercial or free, that has
every single feature of SQL92 implemented.

Most commercial databases claim SQL92 compliance based on compliance
with the simplest, lowest level defined in the standard. We have many
features of the two higher levels, as well as stong compliance with
the lowest level. We also have significant extensions, some of which
now appearing in the SQL3 draft standard (and pioneered by Postgres).
We claim to be a "extended subset" of the SQL92 standard, which seems
accurate.

As was suggested earlier, you must be more specific about which
features you feel are missing. Some may be coming soon, some may be so
ill-conceived that we would be foolish to damage Postgres by
implementing them, and some may be reasonable to do but farther off in
time.

- Thomas

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

From bouncefilter Tue Aug 31 03:05:00 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 DAA01043
for <hackers@postgreSQL.org>; Tue, 31 Aug 1999 03:04:51 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id HAA14090;
Tue, 31 Aug 1999 07:04:26 GMT
Sender: lockhart@hub.org
Message-ID: <37CB7E7A.A65A45E0@alumni.caltech.edu>
Date: Tue, 31 Aug 1999 07:04:26 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Oliver Elphick <olly@lfix.co.uk>
CC: hackers@postgreSQL.org, 43702@bugs.debian.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
References: <199908302119.WAA01119@linda.lfix.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have had a request to add multi-byte support to the Debian binary
packages of PostgreSQL.
Since I live in England, I have personally no need of this and therefore
have little understanding of the implications.
If I change the packages to use multi-byte support, (UNICODE (UTF-8) is
suggested as the default), will there be any detrimental effects on the
fairly large parts of the world that don't need it? Should I try to
provide two different packages, one with and one without MB support?

Probably. The downside to having MB support is reduced performance and
perhaps functionality. If you don't need it, don't build it...

- Thomas

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

From bouncefilter Tue Aug 31 04:37:01 1999
Received: from emerald.netskate.ru (mail@emerald.netskate.ru [195.46.167.98])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA11520
for <hackers@postgresql.org>; Tue, 31 Aug 1999 04:36:04 -0400 (EDT)
(envelope-from phd@emerald.netskate.ru)
Received: from localhost [127.0.0.1] (phd)
by emerald.netskate.ru with esmtp (Exim 2.05 #1 (Debian))
id 11LjOf-0007Z7-00; Tue, 31 Aug 1999 12:36:05 +0400
Date: Tue, 31 Aug 1999 12:36:04 +0400 (MSD)
From: Oleg Broytmann <phd@emerald.netskate.ru>
Reply-To: phd2@earthling.net
To: Oliver Elphick <olly@lfix.co.uk>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
In-Reply-To: <199908302119.WAA01119@linda.lfix.co.uk>
Message-ID: <Pine.LNX.4.04.9908311227510.29049-100000@emerald.netskate.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 30 Aug 1999, Oliver Elphick wrote:

I have had a request to add multi-byte support to the Debian binary
packages of PostgreSQL.

Since I live in England, I have personally no need of this and therefore
have little understanding of the implications.

If I change the packages to use multi-byte support, (UNICODE (UTF-8) is

I consider Unicode as a compromise, and as such, it is the worst case. I
don't know anyone who need Unicode directly. Russian users need koi8 and
win1251, Chineese, Japaneese and other folks need their apropriate
encodings (BIG5 and all that).
Don't know what should be reasonable default; in any case installation
script should ask about user preference and run initdb -E with user
encoding to set default.

suggested as the default), will there be any detrimental effects on the
fairly large parts of the world that don't need it? Should I try to
provide two different packages, one with and one without MB support?

But of course. Many people do not want MB support out of distributive.
Suspicious sysadmin should reject such package, if (s)he do not understand
what/where/why MB - and it is right.
Suporting two different packages is hard, but support only MB-enabled
package will led to many demands "please provide smaller/better/faster
PostgreSQL package".

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.

From bouncefilter Tue Aug 31 04:31:01 1999
Received: from malgate.marin.or.jp (malgate.marin.or.jp [210.166.180.5])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA10908
for <pgsql-hackers@hub.org>; Tue, 31 Aug 1999 04:30:42 -0400 (EDT)
(envelope-from yutaka@marin.or.jp)
Received: from yutaka (210.250.219.98) by malgate.marin.or.jp
with SMTP (Eudora Internet Mail Server 1.3b1);
Tue, 31 Aug 1999 05:32:32 +0900
Date: Tue, 31 Aug 1999 17:38:59 +0900
From: yutaka tanida <yutaka@marin.or.jp>
To: pgsql-hackers@hub.org
Cc: inoue@tpf.co.jp
Subject: Re: IPC on win32 - additions for 6.5.2 and current trees
Message-Id: <37CB94A31ED.C8A2YUTAKA@malgate.marin.or.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.25.05

Hi,

Daniel Horak wrote:

Hi,

please add the file ipc.patch (patch for the cygipc library) into src/win32
directory and apply the patch for README.NT (readme.patch). I think it
should go into both the 6.5.2 and current trees.

I have no reaction from the author of the cygipc library yet, so it will be
better to include the patch into the sources of PostgreSQL

I propose more patch against cygipc.

Hiroshi Inoue (inoue@tpf.co.jp) found another backend freezing problem.
He also found semop() in cygipc can't decrement semaphore value
correctly (Only -1 is supported).

I create follwing patch fixes these issues.

I'm sorry for my poor English.

*** sem.c.orig_	Tue Aug 17 14:19:37 1999
--- sem.c	Tue Aug 31 16:59:49 1999
***************
*** 204,210 ****
      {
  	CloseHandle ( LHandle ) ;
      }
!     LHandle = CreateSemaphore(NULL, 0, 0x7FFFFFFF, LBuff) ;
      if( LHandle == NULL )
      {
  	printf( "Creation de Semaphore \"Sem\" impossible\n" ) ;
--- 204,210 ----
      {
  	CloseHandle ( LHandle ) ;
      }
!     LHandle = CreateSemaphore(NULL, 0, 1, LBuff) ;
      if( LHandle == NULL )
      {
  	printf( "Creation de Semaphore \"Sem\" impossible\n" ) ;
***************
*** 374,388 ****
  debug_printf("do_semop : return -EACCES\n");
  			CYGWIN32_IPCNT_RETURN (-EACCES) ;
  		    }
! 		    ReleaseSemaphore(LHandle, sop->sem_op, &LVal) ;
! 	    	    shareadrsem->current_nb[id].current_nb[sop->sem_num] +=
! 					sop->sem_op ;
  		    sem_deconnect() ;
  		} else {
  		    if( sop->sem_flg == IPC_NOWAIT )
  		    {
! 			LRet = WaitForSingleObject(LHandle, 0) ;
! 			if( LRet == WAIT_TIMEOUT )
  			{
  debug_printf("do_semop : return -EAGAIN\n");
  			    CYGWIN32_IPCNT_RETURN (-EAGAIN) ;
--- 374,387 ----
  debug_printf("do_semop : return -EACCES\n");
  			CYGWIN32_IPCNT_RETURN (-EACCES) ;
  		    }
!     	    shareadrsem->current_nb[id].current_nb[sop->sem_num] +=
! 				sop->sem_op ;
  		    sem_deconnect() ;
+ 		    ReleaseSemaphore(LHandle, 1 , &LVal) ;
  		} else {
  		    if( sop->sem_flg == IPC_NOWAIT )
  		    {
! 			if( sop->sem_op + shareadrsem->current_nb[id].current_nb[sop->sem_num] <0 )
  			{
  debug_printf("do_semop : return -EAGAIN\n");
  			    CYGWIN32_IPCNT_RETURN (-EAGAIN) ;
***************
*** 392,407 ****
  debug_printf("do_semop : return -EACCES\n");
  			    CYGWIN32_IPCNT_RETURN (-EACCES) ;
  			}
! 	    		shareadrsem->current_nb[id].current_nb[sop->sem_num] -= 1 ;
  			sem_deconnect() ;
  		    } else {
! 			LRet = WaitForSingleObject(LHandle, INFINITE) ;
  			if (sem_connect() == 0)
  			{
  debug_printf("do_semop : return -EACCES\n");
  			    CYGWIN32_IPCNT_RETURN (-EACCES) ;
  			}
! 			    shareadrsem->current_nb[id].current_nb[sop->sem_num] -= 1 ;
  			    sem_deconnect() ;
  		    }
  		}
--- 391,408 ----
  debug_printf("do_semop : return -EACCES\n");
  			    CYGWIN32_IPCNT_RETURN (-EACCES) ;
  			}
! 	    		shareadrsem->current_nb[id].current_nb[sop->sem_num] += sop->sem_op;
  			sem_deconnect() ;
  		    } else {
! 		    while(sop->sem_op + shareadrsem->current_nb[id].current_nb[sop->sem_num] <0)
! 				LRet = WaitForSingleObject(LHandle, INFINITE) ;
! 		    
  			if (sem_connect() == 0)
  			{
  debug_printf("do_semop : return -EACCES\n");
  			    CYGWIN32_IPCNT_RETURN (-EACCES) ;
  			}
! 			    shareadrsem->current_nb[id].current_nb[sop->sem_num] += sop->sem_op ;
  			    sem_deconnect() ;
  		    }
  		}
***************
*** 452,458 ****
  	char LBuff[100] ;
  	HANDLE LHandle ;
  	long LPrevious ;
- 	int LIndex;

  debug_printf("semctl : semid=%X semnum=%X cmd=0x%02X arg=%p\n",semid,semnum,cmd,arg);
  	if (semid < 0 || semnum < 0 || cmd < 0)
--- 453,458 ----
***************
*** 585,606 ****
  		if( LHandle != NULL )
  		{
  		    if( arg.val > shareadrsem->current_nb[id].current_nb[semnum] )
! 		    {
! 			ReleaseSemaphore(LHandle,
! 			arg.val-shareadrsem->current_nb[id].current_nb[semnum],
! 			&LPrevious) ;
! 		    }
! 		    else if (arg.val <
! 		             shareadrsem->current_nb[id].current_nb[semnum] )
! 		    {
! 			for( LIndex = arg.val;
! 			LIndex < shareadrsem->current_nb[id].current_nb[semnum];
! 			LIndex++ )
! 			{
! 			    WaitForSingleObject(LHandle, 0) ;
! 			}
! 		    }
!             	    shareadrsem->current_nb[id].current_nb[semnum] = arg.val ;
  		}
  debug_printf("semctl : SETVAL : return 0\n");
  		CYGWIN32_IPCNT_RETURN_DECONNECT (0);
--- 585,592 ----
  		if( LHandle != NULL )
  		{
  		    if( arg.val > shareadrsem->current_nb[id].current_nb[semnum] )
! 				ReleaseSemaphore(LHandle,1,&LPrevious) ;
!             shareadrsem->current_nb[id].current_nb[semnum] = arg.val ;
  		}
  debug_printf("semctl : SETVAL : return 0\n");
  		CYGWIN32_IPCNT_RETURN_DECONNECT (0);

--
Yutaka tanida / S34 Co., Ltd.
tanida@s34.co.jp (Office)
yutaka@marin.or.jp(Private, or if you *HATE* Microsoft Outlook)

From bouncefilter Tue Aug 31 05:31: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 FAA19649
for <hackers@postgreSQL.org>; Tue, 31 Aug 1999 05:30:58 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id SAA26181;
Tue, 31 Aug 1999 18:29:22 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id SAA29273;
Tue, 31 Aug 1999 18:29:22 +0900 (JST)
Message-Id: <199908310929.SAA29273@srapc451.sra.co.jp>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Oliver Elphick <olly@lfix.co.uk>, hackers@postgreSQL.org,
43702@bugs.debian.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Tue, 31 Aug 1999 07:04:26 GMT.
<37CB7E7A.A65A45E0@alumni.caltech.edu>
Date: Tue, 31 Aug 1999 18:29:21 +0900
Sender: t-ishii@srapc451.sra.co.jp

I have had a request to add multi-byte support to the Debian binary
packages of PostgreSQL.
Since I live in England, I have personally no need of this and therefore
have little understanding of the implications.
If I change the packages to use multi-byte support, (UNICODE (UTF-8) is
suggested as the default), will there be any detrimental effects on the
fairly large parts of the world that don't need it? Should I try to
provide two different packages, one with and one without MB support?

Probably. The downside to having MB support is reduced performance and
perhaps functionality. If you don't need it, don't build it...

Not really. I did the regression test with/without multi-byte enabled.

with MB: 2:53:92 elapsed
w/o MB: 2:52.92 elapsed

Perhaps the worst case for MB would be regex ops. If you do a lot of
regex queries, performance degration might not be neglectable.

Load module size:

with MB: 1208542
w/o MB: 1190925

(difference is 17KB)

Talking about the functionality, I don't see any missing feature with
MB comparing w/o MB. (there are some features only MB has. for
example, SET NAMES).
--
Tatsuo Ishii

From bouncefilter Tue Aug 31 08:14:04 1999
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA39192
for <hackers@postgresql.org>; Tue, 31 Aug 1999 08:10:52 -0400 (EDT)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id PAA10155;
Tue, 31 Aug 1999 15:56:35 +0400 (MSD)
Date: Tue, 31 Aug 1999 15:56:34 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Oliver Elphick <olly@lfix.co.uk>, hackers@postgresql.org,
43702@bugs.debian.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
In-Reply-To: <199908310929.SAA29273@srapc451.sra.co.jp>
Message-ID: <Pine.GSO.3.96.SK.990831155206.6807H-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 31 Aug 1999, Tatsuo Ishii wrote:

Date: Tue, 31 Aug 1999 18:29:21 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Cc: Oliver Elphick <olly@lfix.co.uk>, hackers@postgresql.org,
43702@bugs.debian.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution

I have had a request to add multi-byte support to the Debian binary
packages of PostgreSQL.
Since I live in England, I have personally no need of this and therefore
have little understanding of the implications.
If I change the packages to use multi-byte support, (UNICODE (UTF-8) is
suggested as the default), will there be any detrimental effects on the
fairly large parts of the world that don't need it? Should I try to
provide two different packages, one with and one without MB support?

Probably. The downside to having MB support is reduced performance and
perhaps functionality. If you don't need it, don't build it...

Not really. I did the regression test with/without multi-byte enabled.

with MB: 2:53:92 elapsed
w/o MB: 2:52.92 elapsed

Perhaps the worst case for MB would be regex ops. If you do a lot of
regex queries, performance degration might not be neglectable.

It should be. What would be nice is to have a column-specific
MB support. But I doubt if it's possible.

Load module size:

with MB: 1208542
w/o MB: 1190925

(difference is 17KB)

Talking about the functionality, I don't see any missing feature with
MB comparing w/o MB. (there are some features only MB has. for
example, SET NAMES).
--
Tatsuo Ishii

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

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

From bouncefilter Tue Aug 31 08:14:04 1999
Received: from fep09-svc.tin.it (mta09-acc.tin.it [212.216.176.40])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA39392
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 08:13:56 -0400 (EDT) (envelope-from rcorna@tin.it)
Received: from tin.it ([212.216.140.82]) by fep09-svc.tin.it
(InterMail v4.01.01.02 201-229-111-106) with ESMTP
id <19990831121323.YXVV435.fep09-svc@tin.it>
for <pgsql-hackers@postgreSQL.org>; Tue, 31 Aug 1999 14:13:23 +0200
Sender: root
Message-ID: <37CBC4FB.244FC7D7@tin.it>
Date: Tue, 31 Aug 1999 14:05:15 +0200
From: Roberto Cornacchia <rcorna@tin.it>
Organization: tin.it
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: optimizer pruning problem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Just a month ago, we posted a bug-report on the BUGS mailing list
concerning the optimizer plan enumeration in the 6.5.0 release.
We haven't seen any comment about it and the problem is still unfixed in
the last release, so we wish to have a feedback from someone of the
developers.
We also posted a patch in the PATCHES mailing list.
The details of the bug can be found in the posted report still available
in the archives of the mailing list, here we just briefly redescribe the
problem:
the problem is in the pruning algorithm (functions add_pathlist,
better_path in optimizer/util/pathnode.c): it appens sometimes (see the
report) that in the path list of a RelOptInfo are kept more than one
path with the same order insted of only the best one. This is not
dangerous for the correctness of the algorithm, but it badly affects the
performance since the growth (exponential in the join number) in the
enumeration space.
Best regards

Roberto Cornacchia (cornacch@cs.unibo.it)
Andrea Ghidini (ghidini@cs.unibo.it)

From bouncefilter Tue Aug 31 14:13:08 1999
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA11915
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 14:12:36 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U125.dialup.udm.net [192.168.53.125])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id XAA56355;
Tue, 31 Aug 1999 23:12:22 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37CBD8FE.8C89919F@udmnet.ru>
Date: Tue, 31 Aug 1999 18:30:38 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3-5 i686)
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Postgres' lexer
References: <14978.935166666@sss.pgh.pa.us>
<37CB5581.517CBD91@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oh, there isn't really much change. The minus is passed standalone
as it always was. The only thing is that currently in numbers with unary
minus it gets coerced not in lexer, but in parser in doNegate().
I wonder why that hasn't been done earlier - especially considering
that doNegate() existed long before my, hmm, fiddling.

To tell the truth, there is some ambiguity in various operators.
That ambiguity is stemming from Postgres's type-extension system.
Consider this: SELECT 3+-2; What would you expect from that? I
personally would expect the result of 1. But it produces an error,
because '+-' is treated as some user-defined operator, which is
not true. Such innocent expression as SELECT --2 puts Postgres in
daze - it (psql) waits for 'completion' of such query (it treats
symbols '--' as comment start :-) See? There are more pitfalls
beside minus coercing :-)

This all was done to clean up the code and 'straighten' the parser.
There was a performance breaker, officially called AFAIR 'variable
trailing context'.

Thomas Lockhart wrote:

There are several cases which need to be handled (I'm doing this from
memory, so may miss a few):

o Positive and negative numbers as standalone arguments, with and
without spaces between the "-" and the digits.

o Positive and negative numbers as first arguments to binary
operators, with and without spaces at all possible places.

o Positive and negative numbers as second arguments to binary
operators, or as arguments to unary operators.

o Positive and negative numbers in the presence of operators
containing minus signs, including a trailing minus sign where
possible.

'taint easy to do it completely right. Perhaps trying to do less in
the scanner is the right thing to do, but istm that it may put
restrictions on the grammar which are not currently there. Not a good
trade for a longer query length...

--
Leon.

From bouncefilter Tue Aug 31 09:38:04 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA56298
for <pgsql-hackers@postgresql.org>;
Tue, 31 Aug 1999 09:37:06 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA15166;
Tue, 31 Aug 1999 09:36:33 -0400 (EDT)
To: Roberto Cornacchia <rcorna@tin.it>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] optimizer pruning problem
In-reply-to: Your message of Tue, 31 Aug 1999 14:05:15 +0200
<37CBC4FB.244FC7D7@tin.it>
Date: Tue, 31 Aug 1999 09:36:32 -0400
Message-ID: <15164.936106592@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Roberto Cornacchia <rcorna@tin.it> writes:

Just a month ago, we posted a bug-report on the BUGS mailing list
concerning the optimizer plan enumeration in the 6.5.0 release.
We haven't seen any comment about it and the problem is still unfixed in
the last release, so we wish to have a feedback from someone of the
developers.

I believe I have taken care of this problem as part of the optimizer
overhaul I am doing for 6.6. I was not planning to back-patch any of
this work for 6.5.2, however --- too many changes, not yet enough
testing. If you pull down a current snapshot you should be able to
see what I have done with add_pathlist.

regards, tom lane

From bouncefilter Tue Aug 31 09:48:04 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA58427
for <hackers@postgreSQL.org>; Tue, 31 Aug 1999 09:48:03 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA15227;
Tue, 31 Aug 1999 09:46:55 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql/src/include/parser (parse_node.h
parse_oper.h)
In-reply-to: Your message of Tue, 31 Aug 1999 05:11:06 +0000
<37CB63EA.376BF4E5@alumni.caltech.edu>
Date: Tue, 31 Aug 1999 09:46:55 -0400
Message-ID: <15225.936107215@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Remove bogus code in oper_exact --- if it didn't find an exact
match then it tried for a self-commutative operator with the reversed input
data types. This is pretty silly;

Ooh! That codes sounds familiar. What I was trying for was to cover
the case that, for example, (int4 < float4) was not implemented, but
that (float4 >= int4) was. If this is already handled elsewhere, or if
this goal is nonsensical, then cutting the defective code is the right
thing. But if the code just needed repairing, we should put it back in
and get it right next time...

Well, what it was actually looking for was not a commuted operator but
the *same* operator name with the reversed data types; and then
demanding that this operator link to itself as its own commutator.
I don't believe such a case can ever arise in practice --- it certainly
does not now, since the opr_sanity regress test would complain if it
did.

I don't see any really good way for operator lookup to substitute
commutative operators, since it has only an operator name and not (yet)
any pg_operator entry to check the commutator link of. Surely you don't
want to hardwire in knowledge that, say, '<' and '>=' are likely to be
names of commutators.

In any case, failing to provide a full set of commutable comparison
operators will hobble the optimizer, so an implementor of a new data
type would be pretty foolish not to provide both operators. So I don't
think it's worth providing code in operator lookup to handle this
scenario.

regards, tom lane

From bouncefilter Tue Aug 31 09:53:05 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA59481
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 09:52:16 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA15260;
Tue, 31 Aug 1999 09:51:37 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org, "Cyrus Rahman" <cr@photox.jcmax.com>
Subject: Re: [HACKERS] File descriptor leakage?
In-reply-to: Your message of Tue, 31 Aug 1999 13:49:32 +0900
<002701bef36c$37985420$2801007e@cadzone.tpf.co.jp>
Date: Tue, 31 Aug 1999 09:51:37 -0400
Message-ID: <15258.936107497@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

I posted a patch about a month ago([HACKERS] double opens).
But yutaka tanida [yutaka@marin.or.jp] reported a bug caused
by the patch. I found it's because of calling smgrclose() after
smgrclose()/smgrunlink() for the same relation.
It seems my old patch has not been appiled yet.
Here is a new patch.

I think we ought to hold up 6.5.2 long enough to cram this patch in, but
I'm hesitant to stick it in the stable branch without some more testing.
Cyrus, can you try it and see if it fixes your problem?

regards, tom lane

From bouncefilter Tue Aug 31 10:01:05 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA61335
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 10:01:02 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA15314;
Tue, 31 Aug 1999 09:57:53 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Brook Milligan <brook@biology.nmsu.edu>, Michael.Ansley@intec.co.za,
leon@udmnet.ru, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Postgres' lexer
In-reply-to: Your message of Tue, 31 Aug 1999 04:09:37 +0000
<37CB5581.517CBD91@alumni.caltech.edu>
Date: Tue, 31 Aug 1999 09:57:53 -0400
Message-ID: <15312.936107873@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

I added the <xm> exclusive state to accomodate the possibility of a
unary minus. The change was provoked by Vadim's addition of CREATE
SEQUENCE, which should allow negative numbers for some arguments. But
this just uncovered the tip of the general problem...

It seems awfully hard and dangerous to try to identify unary minus in
the lexer. The grammar at least has enough knowledge to recognize that
a minus *is* unary and not binary. Looking into gram.y, I find that the
CREATE SEQUENCE productions handle collapsing unary minus all by
themselves! So in that particular case, there is still no need for the
lexer to do it. AFAICT in a quick look through gram.y, there are no
places where unary minus is recognized that gram.y won't try to collapse
it.

In short, I still think that the whole mess ought to come out of the
lexer...

regards, tom lane

From bouncefilter Tue Aug 31 10:09:05 1999
Received: from s-nath-exch2.nath-ctmp.co.za ([209.212.102.30])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA62676
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 10:08:17 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH2 with Internet Mail Service (5.5.2448.0)
id <RF19KLLN>; Tue, 31 Aug 1999 16:04:07 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C01A@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>, Thomas Lockhart
<lockhart@alumni.caltech.edu>
Cc: Brook Milligan <brook@biology.nmsu.edu>, leon@udmnet.ru,
pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Postgres' lexer
Date: Tue, 31 Aug 1999 16:04:06 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Leon took it out with a patch that he sent in about ten days ago. I did
some (very) basic testing, and it seemed to remove the problem of limiting
the token size, which is what I was after.

MikeA

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Tuesday, August 31, 1999 3:58 PM
To: Thomas Lockhart
Cc: Brook Milligan; Michael.Ansley@intec.co.za; leon@udmnet.ru;
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Postgres' lexer

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

I added the <xm> exclusive state to accomodate the possibility of a
unary minus. The change was provoked by Vadim's addition of CREATE
SEQUENCE, which should allow negative numbers for some

arguments. But

this just uncovered the tip of the general problem...

It seems awfully hard and dangerous to try to identify unary minus in
the lexer. The grammar at least has enough knowledge to
recognize that
a minus *is* unary and not binary. Looking into gram.y, I
find that the
CREATE SEQUENCE productions handle collapsing unary minus all by
themselves! So in that particular case, there is still no
need for the
lexer to do it. AFAICT in a quick look through gram.y, there are no
places where unary minus is recognized that gram.y won't try
to collapse
it.

In short, I still think that the whole mess ought to come out of the
lexer...

regards, tom lane

From bouncefilter Tue Aug 31 10:20:07 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA64873
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 10:19:13 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA15428;
Tue, 31 Aug 1999 10:14:51 -0400 (EDT)
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Brook Milligan <brook@biology.nmsu.edu>, leon@udmnet.ru,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Postgres' lexer
In-reply-to: Your message of Tue, 31 Aug 1999 16:04:06 +0200
<1BF7C7482189D211B03F00805F8527F748C01A@S-NATH-EXCH2>
Date: Tue, 31 Aug 1999 10:14:51 -0400
Message-ID: <15426.936108891@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Leon took it out with a patch that he sent in about ten days ago. I did
some (very) basic testing, and it seemed to remove the problem of limiting
the token size, which is what I was after.

Hi Mike,
I committed most of your long-query changes last night, along with
some work of my own, but ran out of steam before getting to psql.c.
Also I did not touch gram.y and scan.l because I was unsure that I
had the latest version of what you and Leon had done. Could you send
me the latest and greatest?

regards, tom lane

From bouncefilter Tue Aug 31 10:22:05 1999
Received: from s-nath-exch2.nath-ctmp.co.za ([209.212.102.30])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA65546
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 10:21:57 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH2 with Internet Mail Service (5.5.2448.0)
id <RF19KLL8>; Tue, 31 Aug 1999 16:17:54 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C01B@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>, Brook Milligan
<brook@biology.nmsu.edu>, leon@udmnet.ru, pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Postgres' lexer
Date: Tue, 31 Aug 1999 16:17:54 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

I'll send it to you first thing in the morning. I'm afraid I'm not
connected at home. I've got a good scan.l, although I haven't touched
gram.y.

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Tuesday, August 31, 1999 4:15 PM
To: Ansley, Michael
Cc: Thomas Lockhart; Brook Milligan; leon@udmnet.ru;
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Postgres' lexer

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

Leon took it out with a patch that he sent in about ten

days ago. I did

some (very) basic testing, and it seemed to remove the

problem of limiting

the token size, which is what I was after.

Hi Mike,
I committed most of your long-query changes last night, along with
some work of my own, but ran out of steam before getting to psql.c.
Also I did not touch gram.y and scan.l because I was unsure that I
had the latest version of what you and Leon had done. Could you send
me the latest and greatest?

regards, tom lane

From bouncefilter Tue Aug 31 10:39:06 1999
Received: from yogsothoth.scientificpublications.gr
(yogsothoth.ScientificPublications.gr [194.219.95.81])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA68568
for <pgsql-ports@postgresql.org>; Tue, 31 Aug 1999 10:38:55 -0400 (EDT)
(envelope-from theodore@eexi.gr)
Received: from eexi.gr (fungus.scientificpublications.gr [194.219.95.82]) by
yogsothoth.scientificpublications.gr with SMTP (Microsoft
Exchange Internet Mail Service Version 5.5.2232.9)
id R3ZA6C6P; Tue, 31 Aug 1999 17:37:12 +0300
Message-ID: <37CBE892.370ACD25@eexi.gr>
Date: Tue, 31 Aug 1999 17:37:06 +0300
From: "Theodore J. Soldatos" <theodore@eexi.gr>
Organization: Scientific Publications
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: el,en
MIME-Version: 1.0
To: pgsql-ports@postgresql.org
Subject: Postgres 6.5.1 on Slackware 4.0
Content-Type: multipart/mixed; boundary="------------63401082360FB0B2E4E866E1"

This is a multi-part message in MIME format.
--------------63401082360FB0B2E4E866E1
Content-Type: text/plain; charset=iso-8859-7
Content-Transfer-Encoding: 7bit

Hi,

I just compiled and installed Postgres 6.5.1 on Slackware 4.0 (kernel 2.2.6,
cpu: PIII@450) whithout changing anything on the code. The regression tests had
some strange failures, so i'm sending you the .out and .diff files.

Thanks for your efforts on Postgres,

--
Theodore=J.=Soldatos=_\_="There=is=always=a=bug=somewhere",=said==HAL=to=the==
= theodore@eexi.gr =_/_==Ultimate=Programmer,=and=turned=off=the=air=supply.=
= bafh@hellug.gr =_\_="Everybody=knows=the=war=is=over,====================
==== Scientific =====_/_==everybody=knows=the=good=guys=lost"===Leonard=Cohen=
= Publications Ltd. =_\_============ http://w4u.eexi.gr/~theodore ============
==== Finger: theodore@msfree.scientificpublications.gr or @aurora.eexi.gr ====
--------------63401082360FB0B2E4E866E1
Content-Type: text/plain; charset=iso-8859-7;
name="regress.out"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="regress.out"

=============== Notes... =================
postmaster must already be running for the regression tests to succeed.
The time zone is now set to PST8PDT explicitly by this regression test
client frontend. Please report any apparent problems to
ports@postgresql.org
See regress/README for more information.

=============== destroying old regression database... =================
ERROR: destroydb: database 'regression' does not exist
destroydb: database destroy failed on regression.
=============== creating new regression database... =================
=============== installing PL/pgSQL... =================
=============== running regression queries... =================
boolean .. ok
char .. ok
name .. ok
varchar .. ok
text .. ok
strings .. ok
int2 .. failed
int4 .. failed
int8 .. ok
oid .. ok
float4 .. ok
float8 .. ok
numerology .. ok
point .. ok
lseg .. ok
box .. ok
path .. ok
polygon .. ok
circle .. ok
geometry .. ok
timespan .. ok
datetime .. ok
reltime .. ok
abstime .. ok
tinterval .. ok
horology .. ok
inet .. ok
comments .. ok
oidjoins .. ok
type_sanity .. ok
opr_sanity .. ok
create_function_1 .. ok
create_type .. ok
create_table .. ok
create_function_2 .. ok
constraints .. ok
triggers .. ok
copy .. ok
create_misc .. ok
create_aggregate .. ok
create_operator .. ok
create_view .. ok
create_index .. ok
sanity_check .. ok
errors .. ok
select .. ok
select_into .. ok
select_distinct .. ok
select_distinct_on .. ok
select_implicit .. ok
select_having .. ok
subselect .. ok
union .. ok
case .. ok
join .. ok
aggregates .. ok
transactions .. ok
random .. failed
portals .. ok
misc .. ok
arrays .. ok
btree_index .. ok
hash_index .. ok
select_views .. ok
alter_table .. ok
portals_p2 .. ok
rules .. ok
limit .. ok
plpgsql .. ok
temp .. ok
numeric .. ok

--------------63401082360FB0B2E4E866E1
Content-Type: text/plain; charset=iso-8859-7;
name="regression.diffs"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="regression.diffs"

*** expected/int2.out	Thu Apr 15 05:15:35 1999
--- results/int2.out	Tue Aug 31 17:15:35 1999
***************
*** 7,13 ****
  QUERY: INSERT INTO INT2_TBL(f1) VALUES ('32767');
  QUERY: INSERT INTO INT2_TBL(f1) VALUES ('-32767');
  QUERY: INSERT INTO INT2_TBL(f1) VALUES ('100000');
! ERROR:  pg_atoi: error reading "100000": Numerical result out of range
  QUERY: INSERT INTO INT2_TBL(f1) VALUES ('asdf');
  ERROR:  pg_atoi: error in "asdf": can't parse "asdf"
  QUERY: SELECT '' AS five, INT2_TBL.*;
--- 7,13 ----
  QUERY: INSERT INTO INT2_TBL(f1) VALUES ('32767');
  QUERY: INSERT INTO INT2_TBL(f1) VALUES ('-32767');
  QUERY: INSERT INTO INT2_TBL(f1) VALUES ('100000');
! ERROR:  pg_atoi: error reading "100000": Math result not representable
  QUERY: INSERT INTO INT2_TBL(f1) VALUES ('asdf');
  ERROR:  pg_atoi: error in "asdf": can't parse "asdf"
  QUERY: SELECT '' AS five, INT2_TBL.*;

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

*** expected/int4.out	Thu Apr 15 05:15:36 1999
--- results/int4.out	Tue Aug 31 17:15:36 1999
***************
*** 7,13 ****
  QUERY: INSERT INTO INT4_TBL(f1) VALUES ('2147483647');
  QUERY: INSERT INTO INT4_TBL(f1) VALUES ('-2147483647');
  QUERY: INSERT INTO INT4_TBL(f1) VALUES ('1000000000000');
! ERROR:  pg_atoi: error reading "1000000000000": Numerical result out of range
  QUERY: INSERT INTO INT4_TBL(f1) VALUES ('asdf');
  ERROR:  pg_atoi: error in "asdf": can't parse "asdf"
  QUERY: SELECT '' AS five, INT4_TBL.*;
--- 7,13 ----
  QUERY: INSERT INTO INT4_TBL(f1) VALUES ('2147483647');
  QUERY: INSERT INTO INT4_TBL(f1) VALUES ('-2147483647');
  QUERY: INSERT INTO INT4_TBL(f1) VALUES ('1000000000000');
! ERROR:  pg_atoi: error reading "1000000000000": Math result not representable
  QUERY: INSERT INTO INT4_TBL(f1) VALUES ('asdf');
  ERROR:  pg_atoi: error in "asdf": can't parse "asdf"
  QUERY: SELECT '' AS five, INT4_TBL.*;

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

*** expected/random.out	Mon Aug 17 19:11:15 1998
--- results/random.out	Tue Aug 31 17:17:13 1999
***************
*** 19,23 ****
    WHERE random NOT BETWEEN 80 AND 120;
  random
  ------
! (0 rows)

--- 19,25 ----
    WHERE random NOT BETWEEN 80 AND 120;
  random
  ------
!    125
!    128
! (2 rows)

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

--------------63401082360FB0B2E4E866E1--

From bouncefilter Tue Aug 31 12:41:11 1999
Received: from fandango.cs.unitn.it (root@fandango.cs.unitn.it
[193.205.199.228]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA95917;
Tue, 31 Aug 1999 12:40:25 -0400 (EDT) (envelope-from dz@wizard.net)
Received: from nikita.wizard.net (root@ts-slip38.gelso.unitn.it
[193.205.200.38]) by fandango.cs.unitn.it (8.8.5/8.6.9) with
ESMTP id SAA28021; Tue, 31 Aug 1999 18:56:14 +0200
Received: (from dz@localhost)
by nikita.wizard.net (8.9.2+3.1W/8.9.3/Debian/GNU) id RAA21503;
Tue, 31 Aug 1999 17:01:44 +0200 (MEST)
From: Massimo Dal Zotto <dz@wizard.net>
Message-Id: <199908311501.RAA21503@nikita.wizard.net>
Subject: bug in array contrib
To: hackers@postgreSQL.org (PostgreSQL Hackers),
pgsql-patches@postgreSQL.org (Pgsql Patches),
maillist@candle.pha.pa.us (Bruce Momjian)
Date: Tue, 31 Aug 1999 17:01:43 +0200 (MEST)
X-UIDL: 12257892_192897.483
X-Mailer: ELM [version 2.4ME+ PL48 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

there is a bug in my array contrib. The varchar and bpchar function don't
work correctly. The following patch (for 6.5.1) fixes the problem.

*** contrib/array/array_iterator.c.orig	Sat Jun  5 21:09:35 1999
--- contrib/array/array_iterator.c	Tue Aug 31 11:22:44 1999
***************
*** 6,14 ****
   * elements of the array and the value and compute a result as
   * the logical OR or AND of the iteration results.
   *
!  * Copyright (c) 1997, Massimo Dal Zotto <dz@cs.unitn.it>
   * ported to postgreSQL 6.3.2,added oid_functions, 18.1.1999,
   * Tobias Gabele <gabele@wiz.uni-kassel.de>
   */

  #include <ctype.h>
--- 6,17 ----
   * elements of the array and the value and compute a result as
   * the logical OR or AND of the iteration results.
   *
!  * Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
   * ported to postgreSQL 6.3.2,added oid_functions, 18.1.1999,
   * Tobias Gabele <gabele@wiz.uni-kassel.de>
+  *
+  * This software is distributed under the GNU General Public License
+  * either version 2, or (at your option) any later version.
   */

  #include <ctype.h>
***************
*** 180,186 ****
  int32
  array_varchareq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 20,		/* varchar */
  						  (Oid) 1070,	/* varchareq */
  						  0,			/* logical or */
  						  array, (Datum) value);
--- 183,189 ----
  int32
  array_varchareq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 1043,	/* varchar */
  						  (Oid) 1070,	/* varchareq */
  						  0,			/* logical or */
  						  array, (Datum) value);
***************
*** 189,195 ****
  int32
  array_all_varchareq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 20,		/* varchar */
  						  (Oid) 1070,	/* varchareq */
  						  1,			/* logical and */
  						  array, (Datum) value);
--- 192,198 ----
  int32
  array_all_varchareq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 1043,	/* varchar */
  						  (Oid) 1070,	/* varchareq */
  						  1,			/* logical and */
  						  array, (Datum) value);
***************
*** 198,204 ****
  int32
  array_varcharregexeq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 20,		/* varchar */
  						  (Oid) 1254,	/* textregexeq */
  						  0,			/* logical or */
  						  array, (Datum) value);
--- 201,207 ----
  int32
  array_varcharregexeq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 1043,	/* varchar */
  						  (Oid) 1254,	/* textregexeq */
  						  0,			/* logical or */
  						  array, (Datum) value);
***************
*** 207,213 ****
  int32
  array_all_varcharregexeq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 20,		/* varchar */
  						  (Oid) 1254,	/* textregexeq */
  						  1,			/* logical and */
  						  array, (Datum) value);
--- 210,216 ----
  int32
  array_all_varcharregexeq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 1043,	/* varchar */
  						  (Oid) 1254,	/* textregexeq */
  						  1,			/* logical and */
  						  array, (Datum) value);
***************
*** 221,227 ****
  int32
  array_bpchareq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 20,		/* bpchar */
  						  (Oid) 1048,	/* bpchareq */
  						  0,			/* logical or */
  						  array, (Datum) value);
--- 224,230 ----
  int32
  array_bpchareq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 1042,	/* bpchar */
  						  (Oid) 1048,	/* bpchareq */
  						  0,			/* logical or */
  						  array, (Datum) value);
***************
*** 230,236 ****
  int32
  array_all_bpchareq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 20,		/* bpchar */
  						  (Oid) 1048,	/* bpchareq */
  						  1,			/* logical and */
  						  array, (Datum) value);
--- 233,239 ----
  int32
  array_all_bpchareq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 1042,	/* bpchar */
  						  (Oid) 1048,	/* bpchareq */
  						  1,			/* logical and */
  						  array, (Datum) value);
***************
*** 239,245 ****
  int32
  array_bpcharregexeq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 20,		/* bpchar */
  						  (Oid) 1254,	/* textregexeq */
  						  0,			/* logical or */
  						  array, (Datum) value);
--- 242,248 ----
  int32
  array_bpcharregexeq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 1042,	/* bpchar */
  						  (Oid) 1254,	/* textregexeq */
  						  0,			/* logical or */
  						  array, (Datum) value);
***************
*** 248,254 ****
  int32
  array_all_bpcharregexeq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 20,		/* bpchar */
  						  (Oid) 1254,	/* textregexeq */
  						  1,			/* logical and */
  						  array, (Datum) value);
--- 251,257 ----
  int32
  array_all_bpcharregexeq(ArrayType *array, char *value)
  {
! 	return array_iterator((Oid) 1042,	/* bpchar */
  						  (Oid) 1254,	/* textregexeq */
  						  1,			/* logical and */
  						  array, (Datum) value);

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

From bouncefilter Tue Aug 31 11:13:13 1999
Received: from photox.jcmax.com (photox.jcmax.com [204.69.248.4])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA80769
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 11:12:59 -0400 (EDT)
(envelope-from cr@photox.jcmax.com)
Received: (from cr@localhost) by photox.jcmax.com (8.9.3/8.9.3) id LAA92968;
Tue, 31 Aug 1999 11:12:54 -0400 (EDT) (envelope-from cr)
Date: Tue, 31 Aug 1999 11:12:54 -0400 (EDT)
From: Cyrus Rahman <cr@photox.jcmax.com>
Message-Id: <199908311512.LAA92968@photox.jcmax.com>
To: Inoue@tpf.co.jp, tgl@sss.pgh.pa.us
Subject: Re: [HACKERS] File descriptor leakage?
Cc: pgsql-hackers@postgreSQL.org

I think we ought to hold up 6.5.2 long enough to cram this patch in, but
I'm hesitant to stick it in the stable branch without some more testing.
Cyrus, can you try it and see if it fixes your problem?

Ok, I can't actually try the patch for another week or so, since my
development machine has temporarily become a production machine, but thanks to
Hiroshi Inoue's patch I was able to figure out how to demonstrate the problem
in an easily reproducable manner that anyone can test.

As you can see, a connection open through a vacuum does end up duplicating
its open file descriptors. Here's a psql session demonstrating the problem:

cr@photox% psql -d template1
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.2, compiled by cc ]

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 * from pg_user;
usename|usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd |valuntil
-------+--------+-----------+--------+--------+---------+--------+----------------------------
pgsql | 70|t |t |t |t |********|Sat Jan 31 01:00:00 2037 EST
cr | 71|t |t |t |t |********|
paxis | 72|f |t |t |t |********|
(3 rows)

template1=>
Suspended

cr@photox% ps ax|grep postgres
425 ?? Ss 2:37.25 /usr/local/pgsql/bin/postmaster -i -S -o -F (postgres
90608 ?? S 0:00.06 /usr/local/pgsql/bin/postgres cr localhost template1

cr@photox% fstat -p 90608
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W
pgsql postgres 90608 root / 2 drwxr-xr-x 512 r
pgsql postgres 90608 wd /usr 366233 drwx------ 1536 r
pgsql postgres 90608 text /usr 334856 -r-xr-xr-x 1050936 r
pgsql postgres 90608 0 / 967 crw-rw-rw- null rw
pgsql postgres 90608 1 / 967 crw-rw-rw- null rw
pgsql postgres 90608 2 / 967 crw-rw-rw- null rw
pgsql postgres 90608 3 /usr 365266 -rw------- 1712 r
pgsql postgres 90608 4 /usr 366283 -rw------- 262144 rw
pgsql postgres 90608 5* local stream ca3f3b80 <-> ca3f3cc0
pgsql postgres 90608 6 /usr 366236 -rw------- 8192 rw
pgsql postgres 90608 7 /usr 366239 -rw------- 8192 rw
pgsql postgres 90608 8 /usr 366269 -rw------- 16384 rw
pgsql postgres 90608 9 /usr 366238 -rw------- 49152 rw
pgsql postgres 90608 10 /usr 366259 -rw------- 32768 rw
pgsql postgres 90608 11 /usr 366281 -rw------- 8192 rw
pgsql postgres 90608 12 /usr 366235 -rw------- 172032 rw
pgsql postgres 90608 13 /usr 366246 -rw------- 8192 rw
pgsql postgres 90608 14 /usr 366242 -rw------- 8192 rw
pgsql postgres 90608 15 /usr 366249 -rw------- 8192 rw
pgsql postgres 90608 16 /usr 366247 -rw------- 16384 rw
pgsql postgres 90608 17 /usr 366244 -rw------- 65536 rw
pgsql postgres 90608 18 /usr 366262 -rw------- 139264 rw
pgsql postgres 90608 19 /usr 366237 -rw------- 16384 rw
pgsql postgres 90608 20 /usr 366265 -rw------- 16384 rw
pgsql postgres 90608 21 /usr 366261 -rw------- 40960 rw
pgsql postgres 90608 22 /usr 366254 -rw------- 24576 rw
pgsql postgres 90608 23 /usr 366292 -rw------- 0 rw
pgsql postgres 90608 24 /usr 366258 -rw------- 65536 rw
pgsql postgres 90608 25 /usr 366267 -rw------- 16384 rw

cr@photox% psql -d template1 -c vacuum
VACUUM

cr@photox% !fstat
fstat -p 90608
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W
pgsql postgres 90608 root / 2 drwxr-xr-x 512 r
pgsql postgres 90608 wd /usr 366233 drwx------ 1536 r
pgsql postgres 90608 text /usr 334856 -r-xr-xr-x 1050936 r
pgsql postgres 90608 0 / 967 crw-rw-rw- null rw
pgsql postgres 90608 1 / 967 crw-rw-rw- null rw
pgsql postgres 90608 2 / 967 crw-rw-rw- null rw
pgsql postgres 90608 3 /usr 365266 -rw------- 1712 r
pgsql postgres 90608 4 /usr 366283 -rw------- 262144 rw
pgsql postgres 90608 5* local stream ca3f3b80 <-> ca3f3cc0
pgsql postgres 90608 6 /usr 366236 -rw------- 8192 rw
pgsql postgres 90608 7 /usr 366239 -rw------- 8192 rw
pgsql postgres 90608 8 /usr 366269 -rw------- 16384 rw
pgsql postgres 90608 9 /usr 366238 -rw------- 49152 rw
pgsql postgres 90608 10 /usr 366259 -rw------- 32768 rw
pgsql postgres 90608 11 /usr 366281 -rw------- 8192 rw
pgsql postgres 90608 12 /usr 366235 -rw------- 172032 rw
pgsql postgres 90608 13 /usr 366246 -rw------- 8192 rw
pgsql postgres 90608 14 /usr 366242 -rw------- 8192 rw
pgsql postgres 90608 15 /usr 366249 -rw------- 8192 rw
pgsql postgres 90608 16 /usr 366247 -rw------- 16384 rw
pgsql postgres 90608 17 /usr 366244 -rw------- 65536 rw
pgsql postgres 90608 18 /usr 366262 -rw------- 139264 rw
pgsql postgres 90608 19 /usr 366237 -rw------- 16384 rw
pgsql postgres 90608 20 /usr 366265 -rw------- 16384 rw
pgsql postgres 90608 21 /usr 366261 -rw------- 40960 rw
pgsql postgres 90608 22 /usr 366254 -rw------- 24576 rw
pgsql postgres 90608 23 /usr 366292 -rw------- 0 rw
pgsql postgres 90608 24 /usr 366258 -rw------- 65536 rw
pgsql postgres 90608 25 /usr 366267 -rw------- 16384 rw

cr@photox% fg
psql -d template1
select * from pg_user;
usename|usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd |valuntil
-------+--------+-----------+--------+--------+---------+--------+----------------------------
pgsql | 70|t |t |t |t |********|Sat Jan 31 01:00:00 2037 EST
cr | 71|t |t |t |t |********|
paxis | 72|f |t |t |t |********|
(3 rows)

template1=>
Suspended

cr@photox% ls -iR /usr/local/pgsql/data/ | egrep '292|258|281'
366281 pg_shadow
366258 pg_attribute_relid_attnam_index
366292 pg_user

From bouncefilter Tue Aug 31 11:24:06 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA82575
for <pgsql-hackers@postgresql.org>;
Tue, 31 Aug 1999 11:23:22 -0400 (EDT) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id MAA33169;
Tue, 31 Aug 1999 12:22:31 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 31 Aug 1999 12:22:31 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, pgsql-hackers@postgresql.org,
Cyrus Rahman <cr@photox.jcmax.com>
Subject: Re: [HACKERS] File descriptor leakage?
In-Reply-To: <15258.936107497@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9908311221320.8660-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 31 Aug 1999, Tom Lane wrote:

I think we ought to hold up 6.5.2 long enough to cram this patch in, but

Let me know when you are ready then...the only one that I want to keep to
a relatively fixed date on (or as close to one as possible) are the minor
releases (6.5, 6.6, etc)...the minor-minor releases I have no problems
with shifting around as is required...

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

From bouncefilter Tue Aug 31 11:24:07 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 LAA82649
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 11:24:03 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA14940;
Tue, 31 Aug 1999 15:22:44 GMT
Sender: lockhart@hub.org
Message-ID: <37CBF343.73A813DE@alumni.caltech.edu>
Date: Tue, 31 Aug 1999 15:22:43 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Brook Milligan <brook@biology.nmsu.edu>, Michael.Ansley@intec.co.za,
leon@udmnet.ru, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Postgres' lexer
References: <15312.936107873@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I added the <xm> exclusive state to accomodate the possibility of a
unary minus. The change was provoked by Vadim's addition of CREATE
SEQUENCE, which should allow negative numbers for some arguments. But
this just uncovered the tip of the general problem...

It seems awfully hard and dangerous to try to identify unary minus in
the lexer. The grammar at least has enough knowledge to recognize that
a minus *is* unary and not binary. Looking into gram.y, I find that the
CREATE SEQUENCE productions handle collapsing unary minus all by
themselves! So in that particular case, there is still no need for the
lexer to do it. AFAICT in a quick look through gram.y, there are no
places where unary minus is recognized that gram.y won't try to collapse
it.
In short, I still think that the whole mess ought to come out of the
lexer...

My recollection of the whole point is that, as you mention, *you can't
identify a unary minus in the lexer*. So the minus sign is kept
distinct, to be reconciled later as either a unary minus *or* an
operator *or* whatever. The problem was that before, things like (-2)
and (- 2) were handled differently just because the spacing was
different.

Anyway, I'll look at the defacto changes; perhaps they are just fine
but I'm worried that we've reverted the behavior...

- Thomas

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

From bouncefilter Tue Aug 31 11:51:06 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA87478
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 11:50:12 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA15904;
Tue, 31 Aug 1999 11:49:33 -0400 (EDT)
To: Cyrus Rahman <cr@photox.jcmax.com>
cc: Inoue@tpf.co.jp, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] File descriptor leakage?
In-reply-to: Your message of Tue, 31 Aug 1999 11:12:54 -0400 (EDT)
<199908311512.LAA92968@photox.jcmax.com>
Date: Tue, 31 Aug 1999 11:49:32 -0400
Message-ID: <15902.936114572@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Cyrus Rahman <cr@photox.jcmax.com> writes:

As you can see, a connection open through a vacuum does end up duplicating
its open file descriptors.

Indeed, phrased in that fashion it's easy to duplicate the problem.

Interestingly, this isn't a big problem on platforms where there is
a relatively low limit on number of open files per process. A backend
will run its open file count up to the limit and then stay there
(wasting a few more virtual-file-descriptor array slots per vacuum
cycle, but this is such a small memory leak you'd likely never notice).
But on systems that let a process have thousands of kernel file
descriptors, there will be no recycling of kernel descriptors as the
number of virtual descriptors increases.

What's the consensus, hackers? Do we risk sticking Hiroshi's patch into
6.5.2, or not? It should definitely go into current, but I'm worried
about putting it into the stable branch right before a release...
Vadim, does it look right to you?

regards, tom lane

From bouncefilter Tue Aug 31 12:23:07 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 MAA92467
for <pgsql-hackers@postgresql.org>;
Tue, 31 Aug 1999 12:22:28 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id AAA29942;
Wed, 1 Sep 1999 00:18:30 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37CC0053.CCB458F5@krs.ru>
Date: Wed, 01 Sep 1999 00:18:27 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Cyrus Rahman <cr@photox.jcmax.com>, Inoue@tpf.co.jp,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] File descriptor leakage?
References: <15902.936114572@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Interestingly, this isn't a big problem on platforms where there is

^^^^^^^^^^^^^^^^^^^^^^^^

a relatively low limit on number of open files per process. A backend

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

will run its open file count up to the limit and then stay there
(wasting a few more virtual-file-descriptor array slots per vacuum
cycle, but this is such a small memory leak you'd likely never notice).
But on systems that let a process have thousands of kernel file
descriptors, there will be no recycling of kernel descriptors as the
number of virtual descriptors increases.

What's the consensus, hackers? Do we risk sticking Hiroshi's patch into
6.5.2, or not? It should definitely go into current, but I'm worried
about putting it into the stable branch right before a release...
Vadim, does it look right to you?

Sorry, I have no time to look in it. But there is another solution:

From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Vadim Mikheev
Sent: Monday, June 07, 1999 7:49 PM
To: Hiroshi Inoue
Cc: The Hermit Hacker; pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] postgresql-v6.5beta2.tar.gz ...

[snip]

2. fd.c:pg_nofile()->sysconf(_SC_OPEN_MAX) returns in FreeBSD
near total number of files that can be opened in system
(by _all_ users/procs). With total number of opened files
~ 2000 I can run your test with 10-20 simultaneous
xactions for very short time, -:)

Should we limit fd.c:no_files to ~ 256?

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is port-specific, of course...

No risk at all...

Vadim

From bouncefilter Tue Aug 31 12:51:07 1999
Received: from nsi.edu (amethea.nsi.edu [198.133.185.9])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA98277
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 12:50:37 -0400 (EDT) (envelope-from reina@nsi.edu)
Received: from nsi.edu (o21.nsi.edu [204.128.156.216])
by nsi.edu (8.9.1/8.9.1) with ESMTP id JAA19007
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 09:50:35 -0700 (PDT)
Sender: reina@nsi.edu
Message-ID: <37CC0A71.916943DD@nsi.edu>
Date: Tue, 31 Aug 1999 10:01:38 -0700
From: "G. Anthony Reina" <reina@nsi.edu>
Organization: The Neurosciences Institute
X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: ERROR: Unable to locate type oid 718 in catalog
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anyone run into this error before:

ERROR: Unable to locate type oid 718 in catalog

This occurred when I tried to 'vacuum verbose analyze' my database. The
last time it occurred, I had to re-build the database to get rid of the
error message. Perhaps the pg_catalog is getting corrupted somehow? I'm
not quite sure what it means. The vacuum doesn't finish but rather craps
out after the error. There is no core being generated.

I'm using Postgres 6.5.1 on RH Linux 6.0 (i686).

Thanks.
-Tony

From bouncefilter Tue Aug 31 13:53:08 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 NAA08178
for <hackers@postgreSQL.org>; Tue, 31 Aug 1999 13:52:20 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id NAA16156;
Tue, 31 Aug 1999 13:51:11 -0400 (EDT)
To: Massimo Dal Zotto <dz@wizard.net>
cc: hackers@postgreSQL.org (PostgreSQL Hackers),
scrappy@hub.org (The Hermit Hacker),
maillist@candle.pha.pa.us (Bruce Momjian)
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-reply-to: Your message of Mon, 30 Aug 1999 22:42:37 +0200 (MEST)
<199908302042.WAA19560@nikita.wizard.net>
Date: Tue, 31 Aug 1999 13:51:11 -0400
Message-ID: <16154.936121871@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Massimo Dal Zotto <dz@wizard.net> writes:

May I ask that the patches I submitted two months ago for 6.5.0 are applied
at least to 6.5.2?
Here is the 6.5.1 version of my patches.

I don't much care for QueryLimit (we got rid of that for a reason!)
nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe
enough... but are we in the business of adding features to 6.5.*,
even little ones? Maybe it should only go in current.

regards, tom lane

From bouncefilter Tue Aug 31 14:34:08 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 OAA18376
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 14:33:23 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id OAA16232;
Tue, 31 Aug 1999 14:08:11 -0400 (EDT)
To: "G. Anthony Reina" <reina@nsi.edu>
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to locate type oid 718 in catalog
In-reply-to: Your message of Tue, 31 Aug 1999 10:01:38 -0700
<37CC0A71.916943DD@nsi.edu>
Date: Tue, 31 Aug 1999 14:08:11 -0400
Message-ID: <16230.936122891@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"G. Anthony Reina" <reina@nsi.edu> writes:

Anyone run into this error before:
ERROR: Unable to locate type oid 718 in catalog
This occurred when I tried to 'vacuum verbose analyze' my database.

A quick glimpse says that the only occurrences of that error text are
in parse_type.c, which is not code that I'd think would get called from
vacuum. Odd.

If you do "select * from pg_type where oid = 718;" you should get

If you don't then indeed pg_type is corrupted.

regards, tom lane

From bouncefilter Tue Aug 31 14:28:08 1999
Received: from correo.rtva.es ([150.214.94.37])
by hub.org (8.9.3/8.9.3) with SMTP id OAA15939
for <pgsql-hackers@postgresql.org>;
Tue, 31 Aug 1999 14:27:07 -0400 (EDT)
(envelope-from fjcuberos@rtva.es)
From: fjcuberos@rtva.es
Received: by correo.rtva.es(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id
412567DE.006A83F0 ; Tue, 31 Aug 1999 20:23:25 +0100
X-Lotus-FromDomain: CANAL-SUR@INTERNET
To: pgsql-hackers@postgresql.org
Message-ID: <C12567DE.00659813.00@correo.rtva.es>
Date: Tue, 31 Aug 1999 20:30:00 +0200
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

From bouncefilter Tue Aug 31 15:04:08 1999
Received: from nsi.edu (amethea.nsi.edu [198.133.185.9])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA24600
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 15:03:37 -0400 (EDT) (envelope-from reina@nsi.edu)
Received: from nsi.edu (o21.nsi.edu [204.128.156.216])
by nsi.edu (8.9.1/8.9.1) with ESMTP id LAA23041;
Tue, 31 Aug 1999 11:59:49 -0700 (PDT)
Sender: reina@nsi.edu
Message-ID: <37CC28BC.FA3D9BEC@nsi.edu>
Date: Tue, 31 Aug 1999 12:10:52 -0700
From: "G. Anthony Reina" <reina@nsi.edu>
Organization: The Neurosciences Institute
X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to locate type oid 718 in catalog
References: <16230.936122891@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

A quick glimpse says that the only occurrences of that error text are
in parse_type.c, which is not code that I'd think would get called from
vacuum. Odd.

If you do "select * from pg_type where oid = 718;" you should get

typname|typowner|typlen|typprtlen|typbyval|typtype|typisdefined|typdelim|typrelid|typelem|typinput |typoutput |typreceive|typsend |typalign|typdefault
-------+--------+------+---------+--------+-------+------------+--------+--------+-------+---------+----------+----------+----------+--------+----------
circle | 256| 24| 47|f |b |t |, | 0| 0|circle_in|circle_out|circle_in |circle_out|d |
(1 row)

If you don't then indeed pg_type is corrupted.

regards, tom lane

Okay, I found out why I am getting this error. My partner is building a table which he is calling 'circle'. Of course, circle is a pg_type in the
PostgreSQL. So he DROP TYPE'd circle from the database (we don't need that type anyway). For some reason, the database seems to not mind this until I do
the vacuum analyze.

Any suggestions on a workaround? We'd really prefer to use 'circle' as a tablename and don't need it as a pg_type.
-Tony

From bouncefilter Tue Aug 31 15:51:09 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA31810
for <hackers@postgreSQL.org>; Tue, 31 Aug 1999 15:51:07 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA35596;
Tue, 31 Aug 1999 16:51:01 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 31 Aug 1999 16:51:01 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Massimo Dal Zotto <dz@wizard.net>,
PostgreSQL Hackers <hackers@postgreSQL.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <16154.936121871@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9908311649010.8660-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 31 Aug 1999, Tom Lane wrote:

Massimo Dal Zotto <dz@wizard.net> writes:

May I ask that the patches I submitted two months ago for 6.5.0 are applied
at least to 6.5.2?
Here is the 6.5.1 version of my patches.

I don't much care for QueryLimit (we got rid of that for a reason!)
nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe
enough... but are we in the business of adding features to 6.5.*,
even little ones? Maybe it should only go in current.

6.5.x is supposed to be *only* fixes, no new features...but I'm curious as
to why these never got into v6.5.0 in the first place...

Massimo?

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

From bouncefilter Tue Aug 31 15:53: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 PAA32064
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 15:52:43 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id PAA16417;
Tue, 31 Aug 1999 15:51:39 -0400 (EDT)
To: "G. Anthony Reina" <reina@nsi.edu>
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to locate type oid 718 in catalog
In-reply-to: Your message of Tue, 31 Aug 1999 12:10:52 -0700
<37CC28BC.FA3D9BEC@nsi.edu>
Date: Tue, 31 Aug 1999 15:51:39 -0400
Message-ID: <16415.936129099@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"G. Anthony Reina" <reina@nsi.edu> writes:

Okay, I found out why I am getting this error. My partner is building
a table which he is calling 'circle'. Of course, circle is a pg_type
in the PostgreSQL. So he DROP TYPE'd circle from the database (we
don't need that type anyway). For some reason, the database seems to
not mind this until I do the vacuum analyze.

Is it possible that you've got tables lying around that have ordinary-
circle-type fields in them? Vacuum analyze would notice the lack of
type data, but I'm not sure a plain vacuum would.

In any case, it'd be wise to flush everything in pg_operator and pg_proc
that has circle as an argument or result type. (Does DROP TYPE do that
for you? I bet not...) There might be other system tables that have
references to circle, too.

regards, tom lane

From bouncefilter Tue Aug 31 16:10:09 1999
Received: from nsi.edu (amethea.nsi.edu [198.133.185.9])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA35670
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 16:09:35 -0400 (EDT) (envelope-from reina@nsi.edu)
Received: from nsi.edu (o21.nsi.edu [204.128.156.216])
by nsi.edu (8.9.1/8.9.1) with ESMTP id NAA24981;
Tue, 31 Aug 1999 13:09:31 -0700 (PDT)
Sender: reina@nsi.edu
Message-ID: <37CC3913.77F76504@nsi.edu>
Date: Tue, 31 Aug 1999 13:20:35 -0700
From: "G. Anthony Reina" <reina@nsi.edu>
Organization: The Neurosciences Institute
X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to locate type oid 718 in catalog
References: <16415.936129099@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Is it possible that you've got tables lying around that have ordinary-
circle-type fields in them?

No. No tables at all use the type circle.

In any case, it'd be wise to flush everything in pg_operator and pg_proc
that has circle as an argument or result type. (Does DROP TYPE do that
for you? I bet not...) There might be other system tables that have
references to circle, too.

I'm not sure what you mean by flush pg_operator and pg_proc. What would the
command be?

Thanks.
-Tony

From bouncefilter Tue Aug 31 16:50:17 1999
Received: from fandango.cs.unitn.it (root@fandango.cs.unitn.it
[193.205.199.228]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA42048
for <hackers@postgreSQL.org>; Tue, 31 Aug 1999 16:49:16 -0400 (EDT)
(envelope-from dz@wizard.net)
Received: from nikita.wizard.net (root@ts-slip38.gelso.unitn.it
[193.205.200.38]) by fandango.cs.unitn.it (8.8.5/8.6.9) with
ESMTP id XAA30431; Tue, 31 Aug 1999 23:05:40 +0200
Received: (from dz@localhost)
by nikita.wizard.net (8.9.2+3.1W/8.9.3/Debian/GNU) id WAA23541;
Tue, 31 Aug 1999 22:36:42 +0200 (MEST)
From: Massimo Dal Zotto <dz@wizard.net>
Message-Id: <199908312036.WAA23541@nikita.wizard.net>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <16154.936121871@sss.pgh.pa.us> from Tom Lane at "Aug 31,
1999 1:51:11 pm"
To: hackers@postgreSQL.org (PostgreSQL Hackers)
Date: Tue, 31 Aug 1999 22:36:41 +0200 (MEST)
Cc: tgl@sss.pgh.pa.us (Tom Lane)
X-UIDL: 12257892_192897.483
X-Mailer: ELM [version 2.4ME+ PL48 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Massimo Dal Zotto <dz@wizard.net> writes:

May I ask that the patches I submitted two months ago for 6.5.0 are applied
at least to 6.5.2?
Here is the 6.5.1 version of my patches.

I don't much care for QueryLimit (we got rid of that for a reason!)
nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe
enough... but are we in the business of adding features to 6.5.*,
even little ones? Maybe it should only go in current.

The QueryLimit has been reintroduced because it can be used to set a global
default limit for all queries instead of hacking manually some hundred
queries. I admit that the LIMIT...OFFSET is a cleaner way to do it, but
having the possibility to specify a global default doesn't hurt. The default
can always be overriden with an explicit LIMIT on a single query.
The patch uses the same mechanism of the LIMIT clause, so it's safe. It is
only a different way to set the limit value.

The FREE_TUPLE_MEMORY is a temporary fix to avoid huge memory growth in
some common situations, until the memory management is rewritten in a
better way. Being a little conditional code in a very few places of the
sources it can be safely applied and left disabled. Those few people who
need the feature, like me, can enable it at their own risk. I admit that
this is a kludge but the alternative is in some cases a machine with some
gigabyte of memory.

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

From bouncefilter Tue Aug 31 16:50:14 1999
Received: from fandango.cs.unitn.it (root@fandango.cs.unitn.it
[193.205.199.228]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA42049
for <hackers@postgreSQL.org>; Tue, 31 Aug 1999 16:49:16 -0400 (EDT)
(envelope-from dz@wizard.net)
Received: from nikita.wizard.net (root@ts-slip38.gelso.unitn.it
[193.205.200.38]) by fandango.cs.unitn.it (8.8.5/8.6.9) with
ESMTP id XAA30428; Tue, 31 Aug 1999 23:05:39 +0200
Received: (from dz@localhost)
by nikita.wizard.net (8.9.2+3.1W/8.9.3/Debian/GNU) id WAA23661;
Tue, 31 Aug 1999 22:43:54 +0200 (MEST)
From: Massimo Dal Zotto <dz@wizard.net>
Message-Id: <199908312043.WAA23661@nikita.wizard.net>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <Pine.BSF.4.10.9908311649010.8660-100000@thelab.hub.org> from The
Hermit Hacker at "Aug 31, 1999 4:51: 1 pm"
To: hackers@postgreSQL.org (PostgreSQL Hackers)
Date: Tue, 31 Aug 1999 22:43:53 +0200 (MEST)
Cc: scrappy@hub.org (The Hermit Hacker),
maillist@candle.pha.pa.us (Bruce Momjian)
X-UIDL: 12257892_192897.483
X-Mailer: ELM [version 2.4ME+ PL48 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 31 Aug 1999, Tom Lane wrote:

Massimo Dal Zotto <dz@wizard.net> writes:

May I ask that the patches I submitted two months ago for 6.5.0 are applied
at least to 6.5.2?
Here is the 6.5.1 version of my patches.

I don't much care for QueryLimit (we got rid of that for a reason!)
nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe
enough... but are we in the business of adding features to 6.5.*,
even little ones? Maybe it should only go in current.

6.5.x is supposed to be *only* fixes, no new features...but I'm curious as
to why these never got into v6.5.0 in the first place...

Because they were submitted a few days before the realease date. Bruce told
me they would go in 6.5.1 but apparently he has forgot them. I hope to see
them in 6.5.2.

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

From bouncefilter Tue Aug 31 17:49:10 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA50159
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 17:48:01 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA16664;
Tue, 31 Aug 1999 17:46:29 -0400 (EDT)
To: "G. Anthony Reina" <reina@nsi.edu>
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to locate type oid 718 in catalog
In-reply-to: Your message of Tue, 31 Aug 1999 13:20:35 -0700
<37CC3913.77F76504@nsi.edu>
Date: Tue, 31 Aug 1999 17:46:29 -0400
Message-ID: <16662.936135989@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"G. Anthony Reina" <reina@nsi.edu> writes:

Tom Lane wrote:

In any case, it'd be wise to flush everything in pg_operator and pg_proc
that has circle as an argument or result type. (Does DROP TYPE do that
for you? I bet not...) There might be other system tables that have
references to circle, too.

I'm not sure what you mean by flush pg_operator and pg_proc. What would the
command be?

I meant drop all the operators and functions that use circle data.

You could run the oidjoins regression test script to find out which ones
those are ... it should complain about all system table entries that
refer to OID 718. (If you are mistaken that you have no tables using
circles, you'd find that out, too.)

regards, tom lane

From bouncefilter Tue Aug 31 17:52:11 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 RAA50672
for <hackers@postgresql.org>; Tue, 31 Aug 1999 17:51:45 -0400 (EDT)
(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 11Lvod-0005TS-0C; Tue, 31 Aug 1999 21:51:43 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id WAA18452; Tue, 31 Aug 1999 22:51:35 +0100 (BST)
Message-Id: <199908312151.WAA18452@mtcc.demon.co.uk>
Date: Tue, 31 Aug 1999 22:51:35 +0100 (BST)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: CVS Broken?
To: hackers@postgresql.org, scrappy@hub.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: VgFxz/aoqxa++UjhH9LESw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

Hi All,

Call CVS update I'm getting:-

mtcc:[/export/home/emkxp01/pgsql](39)% cvs update
Fatal error, aborting.
: no such user

"truss"ing the progess I can see:-

send(3, " B E G I N A U T H R".., 19, 0) = 19
send(3, " / u s r / l o c a l / c".., 18, 0) = 18
send(3, "\n", 1, 0) = 1
send(3, " a n o n c v s", 7, 0) = 7
send(3, "\n", 1, 0) = 1
send(3, " A : 0 Z , I d Z", 9, 0) = 9
send(3, "\n", 1, 0) = 1
send(3, " E N D A U T H R E Q".., 17, 0) = 17
recv(3, " I", 1, 0) = 1
recv(3, " ", 1, 0) = 1
recv(3, " L", 1, 0) = 1
recv(3, " O", 1, 0) = 1
recv(3, " V", 1, 0) = 1
recv(3, " E", 1, 0) = 1
recv(3, " ", 1, 0) = 1
recv(3, " Y", 1, 0) = 1
recv(3, " O", 1, 0) = 1
recv(3, " U", 1, 0) = 1
recv(3, "\n", 1, 0) = 1
fcntl(3, F_SETFD, 0x00000001) = 0
fcntl(3, F_SETFD, 0x00000001) = 0
fcntl(3, F_SETFD, 0x00000001) = 0
dup(3) = 5

Keith.

From bouncefilter Tue Aug 31 17:54:10 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA50933
for <hackers@postgreSQL.org>; Tue, 31 Aug 1999 17:53:57 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA16681;
Tue, 31 Aug 1999 17:52:51 -0400 (EDT)
To: Massimo Dal Zotto <dz@wizard.net>
cc: hackers@postgreSQL.org (PostgreSQL Hackers)
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-reply-to: Your message of Tue, 31 Aug 1999 22:36:41 +0200 (MEST)
<199908312036.WAA23541@nikita.wizard.net>
Date: Tue, 31 Aug 1999 17:52:50 -0400
Message-ID: <16679.936136370@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Massimo Dal Zotto <dz@wizard.net> writes:

I don't much care for QueryLimit (we got rid of that for a reason!)

The QueryLimit has been reintroduced because it can be used to set a global
default limit for all queries instead of hacking manually some hundred
queries. I admit that the LIMIT...OFFSET is a cleaner way to do it, but
having the possibility to specify a global default doesn't hurt.

Yes it does: it creates the possibility of breaking (returning
incomplete answers to) queries inside rules, triggers, procedures, etc.
In the worst case it could be used by an unprivileged user to subvert
security checks built into a database by means of rules.

I think this "feature" is far too dangerous to put into the general
distribution.

What would be reasonably safe is a limit that applies *only* to data
being returned to the interactive user, but that would be a different
mechanism than the LIMIT clause; I'm not sure where it would need to
be implemented.

regards, tom lane

From bouncefilter Tue Aug 31 18:07:10 1999
Received: from nsi.edu (amethea.nsi.edu [198.133.185.9])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA53196
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 18:06:17 -0400 (EDT) (envelope-from reina@nsi.edu)
Received: from nsi.edu (o21.nsi.edu [204.128.156.216])
by nsi.edu (8.9.1/8.9.1) with ESMTP id PAA28995;
Tue, 31 Aug 1999 15:02:29 -0700 (PDT)
Sender: reina@nsi.edu
Message-ID: <37CC538E.5D3763C@nsi.edu>
Date: Tue, 31 Aug 1999 15:13:34 -0700
From: "G. Anthony Reina" <reina@nsi.edu>
Organization: The Neurosciences Institute
X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to locate type oid 718 in catalog
References: <16662.936135989@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

I meant drop all the operators and functions that use circle data.

You could run the oidjoins regression test script to find out which ones
those are ... it should complain about all system table entries that
refer to OID 718. (If you are mistaken that you have no tables using
circles, you'd find that out, too.)

regards, tom lane

So I think you are saying that although none of my tables have the circle type,
there are inherent Postgres functions and
operators which use circle. By running the regression test, I could find out
which functions and operators these are and just drop them. Is the vacuum
crapping out then because it is trying to vacuum one of these functions and
finding that OID 718 doesn't exist?

Thanks.
-Tony

From bouncefilter Tue Aug 31 18:19:11 1999
Received: from nsi.edu (amethea.nsi.edu [198.133.185.9])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA54949
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 18:18:57 -0400 (EDT) (envelope-from reina@nsi.edu)
Received: from nsi.edu (o21.nsi.edu [204.128.156.216])
by nsi.edu (8.9.1/8.9.1) with ESMTP id PAA29596;
Tue, 31 Aug 1999 15:15:00 -0700 (PDT)
Sender: reina@nsi.edu
Message-ID: <37CC567D.C330E5DC@nsi.edu>
Date: Tue, 31 Aug 1999 15:26:05 -0700
From: "G. Anthony Reina" <reina@nsi.edu>
Organization: The Neurosciences Institute
X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: OID 718 and Circle
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Okay, I finally convinced my partner that making a table named 'circle'
and dropping the type 'circle' to compensate is just a bad idea. We're
going to rename the table 'circles' and restore the 'circle' type. Could
you give me the psql command line to restore the circle type?

Thanks.
-Tony

From bouncefilter Tue Aug 31 18:57:11 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA59618
for <hackers@postgreSQL.org>; Tue, 31 Aug 1999 18:57:00 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id TAA36774;
Tue, 31 Aug 1999 19:57:11 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 31 Aug 1999 19:57:11 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
cc: hackers@postgreSQL.org
Subject: Re: CVS Broken?
In-Reply-To: <199908312151.WAA18452@mtcc.demon.co.uk>
Message-ID: <Pine.BSF.4.10.9908311956540.4130-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Damn, I wish FreeBSD would up their CVS ... fixed now...

On Tue, 31 Aug 1999, Keith Parks wrote:

Hi All,

Call CVS update I'm getting:-

mtcc:[/export/home/emkxp01/pgsql](39)% cvs update
Fatal error, aborting.
: no such user

"truss"ing the progess I can see:-

send(3, " B E G I N A U T H R".., 19, 0) = 19
send(3, " / u s r / l o c a l / c".., 18, 0) = 18
send(3, "\n", 1, 0) = 1
send(3, " a n o n c v s", 7, 0) = 7
send(3, "\n", 1, 0) = 1
send(3, " A : 0 Z , I d Z", 9, 0) = 9
send(3, "\n", 1, 0) = 1
send(3, " E N D A U T H R E Q".., 17, 0) = 17
recv(3, " I", 1, 0) = 1
recv(3, " ", 1, 0) = 1
recv(3, " L", 1, 0) = 1
recv(3, " O", 1, 0) = 1
recv(3, " V", 1, 0) = 1
recv(3, " E", 1, 0) = 1
recv(3, " ", 1, 0) = 1
recv(3, " Y", 1, 0) = 1
recv(3, " O", 1, 0) = 1
recv(3, " U", 1, 0) = 1
recv(3, "\n", 1, 0) = 1
fcntl(3, F_SETFD, 0x00000001) = 0
fcntl(3, F_SETFD, 0x00000001) = 0
fcntl(3, F_SETFD, 0x00000001) = 0
dup(3) = 5

Keith.

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

From bouncefilter Tue Aug 31 21:35: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 VAA78430
for <pgsql-hackers@postgresql.org>;
Tue, 31 Aug 1999 21:34:34 -0400 (EDT) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id KAA04442; Wed, 01 Sep 1999 10:33:32 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Vadim Mikheev" <vadim@krs.ru>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Cyrus Rahman" <cr@photox.jcmax.com>, <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] File descriptor leakage?
Date: Wed, 1 Sep 1999 10:36:42 +0900
Message-ID: <000401bef41a$71da1fc0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <37CC0053.CCB458F5@krs.ru>
Importance: Normal

-----Original Message-----
From: root@sunpine.krs.ru [mailto:root@sunpine.krs.ru]On Behalf Of Vadim
Mikheev
Sent: Wednesday, September 01, 1999 1:18 AM
To: Tom Lane
Cc: Cyrus Rahman; Inoue@tpf.co.jp; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] File descriptor leakage?

Tom Lane wrote:

Interestingly, this isn't a big problem on platforms where there is

^^^^^^^^^^^^^^^^^^^^^^^^

a relatively low limit on number of open files per process. A backend

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

will run its open file count up to the limit and then stay there

It's not a small problem on platforms such as cygwin, OS2 where we
couldn't unlink open files. We have to close useless file descriptors
ASAP there.

6.5.2-release should be stable as possible.
So I don't object to the riskless way as Vadim mentioned.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Aug 31 21:52:13 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 VAA80522
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 21:51:36 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id BAA15811;
Wed, 1 Sep 1999 01:51:02 GMT
Sender: lockhart@hub.org
Message-ID: <37CC8686.DC01B90D@alumni.caltech.edu>
Date: Wed, 01 Sep 1999 01:51:02 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "G. Anthony Reina" <reina@nsi.edu>
CC: Tom Lane <tgl@sss.pgh.pa.us>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to locate type oid 718 in catalog
References: <16662.936135989@sss.pgh.pa.us> <37CC538E.5D3763C@nsi.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I meant drop all the operators and functions that use circle data.

So I think you are saying that although none of my tables have the circle type,
there are inherent Postgres functions and
operators which use circle. By running the regression test, I could find out
which functions and operators these are and just drop them. Is the vacuum
crapping out then because it is trying to vacuum one of these functions and
finding that OID 718 doesn't exist?

Aren't the built-in types cached at compile time? Even if not, I'd
*really* suggest using a different name for your table. Even "Circle"
(including the double-quotes and mixed case) would work, and would
keep you from having to drop built-in types.

- Thomas

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

From bouncefilter Tue Aug 31 22:20:13 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 WAA83986
for <pgsql-hackers@postgreSQL.org>;
Tue, 31 Aug 1999 22:20:05 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id CAA15876;
Wed, 1 Sep 1999 02:19:33 GMT
Sender: lockhart@hub.org
Message-ID: <37CC8D35.F3B9880A@alumni.caltech.edu>
Date: Wed, 01 Sep 1999 02:19:33 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Leon <leon@udmnet.ru>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Postgres' lexer
References: <14978.935166666@sss.pgh.pa.us>
<37CB5581.517CBD91@alumni.caltech.edu>
<37CBD8FE.8C89919F@udmnet.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oh, there isn't really much change. The minus is passed standalone
as it always was. The only thing is that currently in numbers with unary
minus it gets coerced not in lexer, but in parser in doNegate().
I wonder why that hasn't been done earlier - especially considering
that doNegate() existed long before my, hmm, fiddling.

For good reasons. See below :(

To tell the truth, there is some ambiguity in various operators.
That ambiguity is stemming from Postgres's type-extension system.

There is the possibility for ambiguity. But it is our responsibility
to minimize that ambiguity and to make a predictable system, in the
presence of Postgres' unique and valuable features such as type
extension. imho this is more important than, for example, allowing
infinite-length queries.

Consider this: SELECT 3+-2; What would you expect from that? I
personally would expect the result of 1. But it produces an error,
because '+-' is treated as some user-defined operator, which is
not true.

That is part of my concern here. The current behavior is what you say
you would expect! Your patches change that behavor!!

postgres=> select 3+-2;
?column?
--------
1
(1 row)

Such innocent expression as SELECT --2 puts Postgres in
daze - it (psql) waits for 'completion' of such query (it treats
symbols '--' as comment start :-) See? There are more pitfalls
beside minus coercing :-)

There are some well-defined features of SQL92 which we try hard to
support; the comment convention is one of them. That is a special case
and shouldn't confuse the issue here; we'll need a different test case
to make the point for me...

This all was done to clean up the code and 'straighten' the parser.
There was a performance breaker, officially called AFAIR 'variable
trailing context'.

Sorry, what is the performance penalty for that feature, and how do we
measure that against breakage of expected, predictable behavior?
Please quantify.

So far, I'm not a fan of the proposed change; we're giving up behavior
that impacts Postgres' unique type extension features for an
arbitrarily large query buffer (as opposed to a generously large query
buffer, which can be accomplished just by changing the fixed size).

- Thomas

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

From bouncefilter Tue Aug 31 22:52:39 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 WAA87764
for <hackers@postgresql.org>; Tue, 31 Aug 1999 22:52:22 -0400 (EDT)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id LAA10037;
Wed, 1 Sep 1999 11:30:44 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id LAA23513;
Wed, 1 Sep 1999 11:30:44 +0900 (JST)
Message-Id: <199909010230.LAA23513@srapc451.sra.co.jp>
To: Oleg Bartunov <oleg@sai.msu.su>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>,
Thomas Lockhart <lockhart@alumni.caltech.edu>,
Oliver Elphick <olly@lfix.co.uk>, hackers@postgresql.org,
43702@bugs.debian.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Tue, 31 Aug 1999 15:56:34 +0400.
<Pine.GSO.3.96.SK.990831155206.6807H-100000@ra>
Date: Wed, 01 Sep 1999 11:30:44 +0900
Sender: t-ishii@srapc451.sra.co.jp

Perhaps the worst case for MB would be regex ops. If you do a lot of
regex queries, performance degration might not be neglectable.

It should be. What would be nice is to have a column-specific
MB support. But I doubt if it's possible.

That shouldn't be too difficult, if we have an encoding infomation
with each text column or literal. Maybe now is the time to introuce
NCHAR?

BTW, it is interesting that people does not hesitate to enable
with-locale option even if they only use ASCII. I guess the
performance degration by enabling locale is not too small.
--
Tatsuo Ishii

From bouncefilter Tue Aug 31 22:56:39 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 WAA88314
for <hackers@postgresql.org>; Tue, 31 Aug 1999 22:56:36 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id CAA15960;
Wed, 1 Sep 1999 02:55:48 GMT
Sender: lockhart@hub.org
Message-ID: <37CC95B4.4501F393@alumni.caltech.edu>
Date: Wed, 01 Sep 1999 02:55:48 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: t-ishii@sra.co.jp
CC: Oleg Bartunov <oleg@sai.msu.su>, Oliver Elphick <olly@lfix.co.uk>,
hackers@postgresql.org, 43702@bugs.debian.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
References: <199909010230.LAA23513@srapc451.sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

That shouldn't be too difficult, if we have an encoding infomation
with each text column or literal. Maybe now is the time to introuce
NCHAR?

I've been waiting for a go-ahead from folks who would use it. imho the
way to do it is to use Postgres' type system to implement it, rather
than, for example, encoding "type" information into each string. We
can also define a "default encoding" for each database as a new column
in pg_database...

BTW, it is interesting that people does not hesitate to enable
with-locale option even if they only use ASCII. I guess the
performance degration by enabling locale is not too small.

Red Hat built their RPMs with locale enabled, and there is a
significant performance hit. Implementing NCHAR would be a better
solution, since the user can choose whether to use SQL_TEXT or the
locale-specific character set at run time...

- Thomas

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

From bouncefilter Wed Sep 1 01:54:35 1999
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA16409
for <hackers@postgresql.org>; Wed, 1 Sep 1999 01:53:26 -0400 (EDT)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id JAA02046;
Wed, 1 Sep 1999 09:49:00 +0400 (MSD)
Date: Wed, 1 Sep 1999 09:48:59 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: t-ishii@sra.co.jp, Oliver Elphick <olly@lfix.co.uk>,
hackers@postgresql.org, 43702@bugs.debian.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
In-Reply-To: <37CC95B4.4501F393@alumni.caltech.edu>
Message-ID: <Pine.GSO.3.96.SK.990901094016.6807N-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 1 Sep 1999, Thomas Lockhart wrote:

Date: Wed, 01 Sep 1999 02:55:48 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
To: t-ishii@sra.co.jp
Cc: Oleg Bartunov <oleg@sai.msu.su>, Oliver Elphick <olly@lfix.co.uk>,
hackers@postgresql.org, 43702@bugs.debian.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution

That shouldn't be too difficult, if we have an encoding infomation
with each text column or literal. Maybe now is the time to introuce
NCHAR?

Yes, postgres after 6.5 and especially recent win becomes very popular
and additional performance hit would be very in time. Does implementing
of NCHAR only could solve all problem with text, varchar etc ?

I've been waiting for a go-ahead from folks who would use it. imho the
way to do it is to use Postgres' type system to implement it, rather
than, for example, encoding "type" information into each string. We
can also define a "default encoding" for each database as a new column
in pg_database...

go-ahead, Tom :-) I would use it.

BTW, it is interesting that people does not hesitate to enable
with-locale option even if they only use ASCII. I guess the
performance degration by enabling locale is not too small.

Red Hat built their RPMs with locale enabled, and there is a
significant performance hit. Implementing NCHAR would be a better
solution, since the user can choose whether to use SQL_TEXT or the
locale-specific character set at run time...

- Thomas

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

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

From bouncefilter Wed Sep 1 02:09:40 1999
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA18375
for <hackers@postgresql.org>; Wed, 1 Sep 1999 02:09:24 -0400 (EDT)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id KAA02475
for <hackers@postgresql.org>; Wed, 1 Sep 1999 10:09:20 +0400 (MSD)
Date: Wed, 1 Sep 1999 10:09:19 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: hackers@postgresql.org
Subject: Changes for 6.5.2 ?
Message-ID: <Pine.GSO.3.96.SK.990901100426.6807O-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Is there Changes list for 6.5.2 ? I checked REL6_5 tree and didn't
find it. It seems that Vadim's patch for nbtinsert.c (row-reuse)
still didn't applied.
This patch prevents index file to grow indefinitely and I consider it
as a bug fix. It's not complete, index file still grow but with much
less factor.

Regards,

Oleg

From bouncefilter Wed Sep 1 03:35:36 1999
Received: from kirk.nads.de ([212.222.8.123])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA32238
for <pgsql-hackers@postgresql.org>; Wed, 1 Sep 1999 03:34:56 -0400 (EDT)
(envelope-from klute@heike-e1.nads.de)
Received: from heike.nads.de (heike-e1.nads.de [212.222.8.116])
by kirk.nads.de (8.9.3/8.9.3) with SMTP id JAA09138
for <pgsql-hackers@postgresql.org>;
Wed, 1 Sep 1999 09:35:59 +0200 (MET DST)
Message-Id: <199909010735.JAA09138@kirk.nads.de>
Received: from heike.nads.de ([127.0.0.1]) by heike.nads.de (Lotus SMTP MTA
v4.6.3 (733.2 10-16-1998)) with SMTP id C12567DF.0029B4B3;
Wed, 1 Sep 1999 09:35:32 +0200
X-Mailer: exmh version 2.0.2 2/24/98
To: pgsql-hackers@postgresql.org
Subject: Yacc output faulty ("current")
Reply-To: Rainer Klute <klute@nads.de>
Organization: NADS GmbH, Germany
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: Wed, 01 Sep 1999 09:35:32 +0200
From: Rainer Klute <klute@nads.de>

Hi,

when trying to compile the "current" sources under Solaris 2.5.1,
the yacc-generated C source in interfaces/ecpg/preproc/preproc.c
seems to be faulty:

gcc -I../../../include -I../../../backend -I/usr/local/tcltk-8.0p2/include -Wall -Wmissing-prototypes -I../include -DMAJOR_VERSION=2 -DMINOR_VERSION=6 -DPATCHLEVEL=2 -DINCLUDE_PATH=\"/usr/local/pgsql-develop/include\" -c preproc.c
/usr/ccs/bin/yaccpar: In function `yyparse':
/usr/ccs/bin/yaccpar:275: warning: implicit declaration of function `yylex'
preproc.y:3822: parse error before `}'
/usr/ccs/bin/yaccpar:375: warning: label `yyerrlab' defined but not used
/usr/ccs/bin/yaccpar:165: warning: label `yynewstate' defined but not used
gmake[3]: *** [preproc.o] Error 1
gmake[3]: Leaving directory `/share/syswork2/sw/PostgreSQL/CURRENT/pgsql/src/interfaces/ecpg/preproc'

Running preproc.y through Bison (under Linux) helped, but this is
of course no adequate solution.

Best regards
Rainer Klute

Dipl.-Inform. Tel.: +49 211 9330260
Rainer Klute Fax: +49 211 9330293
NADS GmbH
Hildebrandtstr. 4e <http://www.nads.de/>
D-40215 D��sseldorf <http://www.pixelboxx.de/>

From bouncefilter Wed Sep 1 04:22:37 1999
Received: from s-nath-exch2.nath-ctmp.co.za ([209.212.102.30])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA37928
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Sep 1999 04:22:19 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH2 with Internet Mail Service (5.5.2448.0)
id <RF19KLYM>; Wed, 1 Sep 1999 10:18:18 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C01C@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Thomas Lockhart'" <lockhart@alumni.caltech.edu>, Leon <leon@udmnet.ru>
Cc: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Postgres' lexer
Date: Wed, 1 Sep 1999 10:18:14 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

There is the possibility for ambiguity. But it is our responsibility
to minimize that ambiguity and to make a predictable system, in the
presence of Postgres' unique and valuable features such as type
extension. imho this is more important than, for example, allowing
infinite-length queries.

I agree that predictability is more important than the limit on the query
length, but I think that they can coexist. I'm not aware of what the unary
minus recognition in the scanner is about, and why it's important, but if it
is important, then perhaps we can look at implementing it in such a way that
no vltc is created. This should be possible. After conversation with Vern
(Paxson, author of flex), it appears that we can, under normal conditions,
use a start condition to allow the same token to be identified. This
removes the vltc, which in turn, means that we don't limit the length of the
token. Also, vltcs are major performance degraders.

BTW, Thomas, it's not the query length that is limited by this unary minus
issue, but the token length. The reason I see this as important is because
it means that, once row size is independent of block size, people will try
to insert large text fields. A large text field is a single token.
So, at the moment, it's not really an issue, but I was hoping to get it out
the way before the row size issue was tackled, so that when that was
complete, everything just worked ;-)

Sorry, what is the performance penalty for that feature, and
how do we measure that against breakage of expected, predictable

behavior?

Please quantify.

So far, I'm not a fan of the proposed change; we're giving up behavior
that impacts Postgres' unique type extension features for an
arbitrarily large query buffer (as opposed to a generously large query
buffer, which can be accomplished just by changing the fixed size).

Like I say, I think we can do both (and remove the performance penalty of
the vltc), if we do it right. Thomas, can you send me enough info about the
unary minus token (basic explanation, gotchas, anything else I should know),
and I'll have a look at using a start condition to implement it.

MikeA

From bouncefilter Wed Sep 1 06:50:39 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 GAA56720
for <pgsql-hackers@postgresql.org>; Wed, 1 Sep 1999 06:49:46 -0400 (EDT)
(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 3.3) with ESMTP id MAA16698
for <pgsql-hackers@postgresql.org>; Wed, 1 Sep 1999 12:49:44 +0200 (MDT)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 11M9fT-00063p-00; Wed, 1 Sep 1999 12:39:11 +0000
Message-ID: <37CD03AA.BC08CD19@sferacarta.com>
Date: Wed, 01 Sep 1999 12:44:58 +0200
From: =?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.5 [it] (Win95; I)
X-Accept-Language: it
MIME-Version: 1.0
To: hackers <pgsql-hackers@postgresql.org>
Subject: SELECT BUG
Content-Type: multipart/alternative;
boundary="------------C112CA0BA639802A51E43A1C"

--------------C112CA0BA639802A51E43A1C
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

I think I found some bugs in SELECT...
I have two tables MASTER1 and DETAIL1 both of them with only one field
CODE
of data type VARCHAR but MASTER1.CODE is 11 char long and DETAIL1.CODE
16 char l

hygea=> \d master1
Table = master1
+----------------------------------+----------------------------------+-------+

| Field | Type |
Length|
+----------------------------------+----------------------------------+-------+

| code | varchar()
| 11 |
+----------------------------------+----------------------------------+-------+

hygea=> \d detail1
Table = detail1
+----------------------------------+----------------------------------+-------+

| Field | Type |
Length|
+----------------------------------+----------------------------------+-------+

| code | varchar()
| 16 |
+----------------------------------+----------------------------------+-------+

--I have the following test data into these tables:

hygea=> select * from master1;
code
-----------
a
a1
a13
(3 rows)

hygea=> select * from detail1;
code
----------------
a13
a13
a1
(3 rows)

--if I try to join these two tables I have the following (nothing):

hygea=> select m.*, d.* from master1 m, detail1 d where m.code=d.code;
code|code
----+----
(0 rows)
--and now trying with TRIM function... it works!

hygea=> select m.*, d.* from master1 m, detail1 d where
trim(m.code)=trim(d.code
code |code
-----------+----------------
a13 |a13
a13 |a13
a1 |a1
(3 rows)

--and last another variation using aliases: (note that I forgot to
change
-- MASTER1 with m and DETAIL1 with d:
hygea=> select master1.*, detail1.* from master1 m, detail1 d where
trim(m.code)
code |code
-----------+----------------
a |a13
a1 |a13
a13 |a13
a |a13
a1 |a13
a13 |a13
a |a1
a1 |a1
a13 |a1
a |a13
a1 |a13
a13 |a13
a |a13
a1 |a13
a13 |a13
a |a1
a1 |a1
a13 |a1
a |a13
a1 |a13
a13 |a13
a |a13
a1 |a13
a13 |a13
a |a1
a1 |a1
a13 |a1
(27 rows)

Any ideas?

Jos��

--------------C112CA0BA639802A51E43A1C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>I think I found some bugs in SELECT...</tt>
 <tt>I have two tables MASTER1 and DETAIL1 both of them with only one
field CODE</tt>
 <tt>of data type VARCHAR but MASTER1.CODE is 11 char long and DETAIL1.CODE
16 char l</tt><tt></tt>
<tt>hygea=> \d master1</tt>
 <tt>Table    = master1</tt>
 <tt>+----------------------------------+----------------------------------+-------+</tt>
 <tt>|             
Field              
|             
Type               
| Length|</tt>
 <tt>+----------------------------------+----------------------------------+-------+</tt>
 <tt>| code                            
| varchar()                       
|    11 |</tt>
 <tt>+----------------------------------+----------------------------------+-------+</tt><tt></tt>
<tt>hygea=> \d detail1</tt>
 <tt>Table    = detail1</tt>
 <tt>+----------------------------------+----------------------------------+-------+</tt>
 <tt>|             
Field              
|             
Type               
| Length|</tt>
 <tt>+----------------------------------+----------------------------------+-------+</tt>
 <tt>| code                            
| varchar()                       
|    16 |</tt>
 <tt>+----------------------------------+----------------------------------+-------+</tt><tt></tt>
<tt>--I have the following test data into these tables:</tt><tt></tt>
<tt>hygea=> select * from master1;</tt>
 <tt>code</tt>
 <tt>-----------</tt>
 <tt>a</tt>
 <tt>a1</tt>
 <tt>a13</tt>
 <tt>(3 rows)</tt><tt></tt>
<tt>hygea=> select * from detail1;</tt>
 <tt>code</tt>
 <tt>----------------</tt>
 <tt>a13</tt>
 <tt>a13</tt>
 <tt>a1</tt>
 <tt>(3 rows)</tt><tt></tt>
<tt>--if I try to join these two tables I have the following (nothing):</tt><tt></tt>
<tt>hygea=> select m.*, d.* from master1 m, detail1 d where m.code=d.code;</tt>
 <tt>code|code</tt>
 <tt>----+----</tt>
 <tt>(0 rows)</tt>
 <tt>--and now trying with TRIM function... it works!</tt><tt></tt>
<tt>hygea=> select m.*, d.* from master1 m, detail1 d where trim(m.code)=trim(d.code</tt>
 <tt>code       |code</tt>
 <tt>-----------+----------------</tt>
 <tt>a13        |a13</tt>
 <tt>a13        |a13</tt>
 <tt>a1         |a1</tt>
 <tt>(3 rows)</tt><tt></tt>
<tt>--and last another variation using aliases: (note that I forgot
to change</tt>
 <tt>-- MASTER1 with m and DETAIL1 with d:</tt>
 <tt>hygea=> select master1.*, detail1.* from master1 m, detail1 d where
trim(m.code)</tt>
 <tt>code       |code</tt>
 <tt>-----------+----------------</tt>
 <tt>a          |a13</tt>
 <tt>a1         |a13</tt>
 <tt>a13        |a13</tt>
 <tt>a          |a13</tt>
 <tt>a1         |a13</tt>
 <tt>a13        |a13</tt>
 <tt>a          |a1</tt>
 <tt>a1         |a1</tt>
 <tt>a13        |a1</tt>
 <tt>a          |a13</tt>
 <tt>a1         |a13</tt>
 <tt>a13        |a13</tt>
 <tt>a          |a13</tt>
 <tt>a1         |a13</tt>
 <tt>a13        |a13</tt>
 <tt>a          |a1</tt>
 <tt>a1         |a1</tt>
 <tt>a13        |a1</tt>
 <tt>a          |a13</tt>
 <tt>a1         |a13</tt>
 <tt>a13        |a13</tt>
 <tt>a          |a13</tt>
 <tt>a1         |a13</tt>
 <tt>a13        |a13</tt>
 <tt>a          |a1</tt>
 <tt>a1         |a1</tt>
 <tt>a13        |a1</tt>
 <tt>(27 rows)</tt><tt></tt>
Any ideas?
José
  </html>

--------------C112CA0BA639802A51E43A1C--

From bouncefilter Wed Sep 1 07:13:39 1999
Received: from pdm.pvt.net (qmailr@pdm.pvt.net [194.149.103.204])
by hub.org (8.9.3/8.9.3) with SMTP id HAA59649
for <hackers@postgreSQL.org>; Wed, 1 Sep 1999 07:12:57 -0400 (EDT)
(envelope-from pdm@pvt.net)
Received: (qmail 13127 invoked by uid 1000); 1 Sep 1999 11:12:49 -0000
Sender: pdm@pdm.pvt.net
From: Milan Zamazal <mz@pdm.pvt.net>
To: hackers@postgreSQL.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
References: <199909010230.LAA23513@srapc451.sra.co.jp>
<37CC95B4.4501F393@alumni.caltech.edu>
X-Face: #G'i>Q>~:^*=!qpsXTU;
iEZ8xcAz+u~Vq0(a6!3ebS/2|\r{9&asz&Qp]~)uF,N"4,jS
T&F>.|='gO6:N<FD-e0EI5.+#BblSdQ!$7ZC'3m/6m4edq-E&nU+R%<!V&MXqR<W5RIISsd?Q6]Ig]
V4|Y_QsT/c$EX1WqSYQizlNDh,krFL=uX6OQU?N[wW(8'3[cMK$w
Date: 01 Sep 1999 13:12:49 +0200
In-Reply-To: Thomas Lockhart's message of "Wed, 01 Sep 1999 02:55:48 +0000"
Message-ID: <87hfle51hq.fsf@pdm.pvt.net>
Lines: 17
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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

That shouldn't be too difficult, if we have an encoding
infomation with each text column or literal. Maybe now is the
time to introuce NCHAR?

TL> I've been waiting for a go-ahead from folks who would use
TL> it. imho the way to do it is to use Postgres' type system to
TL> implement it, rather than, for example, encoding "type"
TL> information into each string. We can also define a "default
TL> encoding" for each database as a new column in pg_database...

What about sorting? Would it be possible to solve it in similar way?
If I'm not mistaken, there is currently no good way to use two different
kinds of sorting for one postmaster instance?

Milan Zamazal

From bouncefilter Wed Sep 1 07:18:39 1999
Received: from pdm.pvt.net (qmailr@pdm.pvt.net [194.149.103.204])
by hub.org (8.9.3/8.9.3) with SMTP id HAA60206
for <hackers@postgreSQL.org>; Wed, 1 Sep 1999 07:17:48 -0400 (EDT)
(envelope-from pdm@pvt.net)
Received: (qmail 13158 invoked by uid 1000); 1 Sep 1999 11:17:45 -0000
Sender: pdm@pdm.pvt.net
Original-Sender: pdm@debian.cz
From: Milan Zamazal <pdm@debian.cz>
To: hackers@postgreSQL.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
References: <199909010230.LAA23513@srapc451.sra.co.jp>
<37CC95B4.4501F393@alumni.caltech.edu>
X-Face: #G'i>Q>~:^*=!qpsXTU;
iEZ8xcAz+u~Vq0(a6!3ebS/2|\r{9&asz&Qp]~)uF,N"4,jS
T&F>.|='gO6:N<FD-e0EI5.+#BblSdQ!$7ZC'3m/6m4edq-E&nU+R%<!V&MXqR<W5RIISsd?Q6]Ig]
V4|Y_QsT/c$EX1WqSYQizlNDh,krFL=uX6OQU?N[wW(8'3[cMK$w
In-Reply-To: Thomas Lockhart's message of "Wed, 01 Sep 1999 02:55:48 +0000"
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
Date: 01 Sep 1999 13:17:45 +0200
Message-ID: <87emgi519i.fsf@pdm.pvt.net>
Lines: 17
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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

That shouldn't be too difficult, if we have an encoding
infomation with each text column or literal. Maybe now is the
time to introuce NCHAR?

What about sorting? Would it be possible to solve it in similar way?
If I'm not mistaken, there is currently no good way to use two different
kinds of sorting for one postmaster instance?

Milan Zamazal

From bouncefilter Wed Sep 1 13:19:43 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id HAA61562
for pgsql-hackers@postgresql.org; Wed, 1 Sep 1999 07:29:55 -0400 (EDT)
(envelope-from news)
Date: Wed, 1 Sep 1999 07:29:55 -0400 (EDT)
From: "Hub.Org News Admin" <news>
Message-Id: <199909011129.HAA61562@hub.org>
X-Authentication-Warning: hub.org: news set sender to <news> using -f
To: undisclosed-recipients:;

From bouncefilter Wed Sep 1 07:47:39 1999
Received: from gauss.deltav.hu (gauss.deltav.hu [194.9.64.225])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA63631
for <pgsql-hackers@postgresql.org>; Wed, 1 Sep 1999 07:47:35 -0400 (EDT)
(envelope-from blazso@deltav.hu)
Received: from deltav.hu (141.dial04.deltav.hu [194.9.65.141])
by gauss.deltav.hu (Netscape Messaging Server 3.6) with ESMTP
id AAA621F for <pgsql-hackers@postgresql.org>;
Wed, 1 Sep 1999 13:50:46 +0200
Message-ID: <37CD12A5.D70FAC39@deltav.hu>
Date: Wed, 01 Sep 1999 13:48:53 +0200
From: Peter Blazso <blazso@deltav.hu>
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: need help for array appending & deleting
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

Unless it exists, I'd like to implement code for the array manipulations
above for Postgresql. and I need some help for it. I have already run
through the sources concerned but I need to be pointed to the right
direction on where to start and what kind of functions I should use. I'd
also like to have a bit more detailed info on array structure (or at
least where I can find a good doc. I've been looking for it in
'array.h', 'arrayutils.c' and 'arrayfuncs.c').

Thanks so much, in advance,
Peter Blazso

From bouncefilter Wed Sep 1 09:25: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 JAA75161
for <pgsql-hackers@postgresql.org>; Wed, 1 Sep 1999 09:24:50 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA17515;
Wed, 1 Sep 1999 09:23:32 -0400 (EDT)
To: "G. Anthony Reina" <reina@nsi.edu>
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] ERROR: Unable to locate type oid 718 in catalog
In-reply-to: Your message of Tue, 31 Aug 1999 15:13:34 -0700
<37CC538E.5D3763C@nsi.edu>
Date: Wed, 01 Sep 1999 09:23:32 -0400
Message-ID: <17513.936192212@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"G. Anthony Reina" <reina@nsi.edu> writes:

So I think you are saying that although none of my tables have the
circle type, there are inherent Postgres functions and operators which
use circle. By running the regression test, I could find out which
functions and operators these are and just drop them.

Right.

Is the vacuum
crapping out then because it is trying to vacuum one of these
functions and finding that OID 718 doesn't exist?

Vacuum doesn't vacuum functions (AFAIK). It does, however, use the type
information about columns of tables that it's vacuuming --- at least it
does in vacuum analyze mode, not sure about plain vacuum. That's why
I'm suspicious that you have somewhere a forgotten table that has a
column of circle type...

regards, tom lane

From bouncefilter Wed Sep 1 09:27: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 JAA75572
for <pgsql-hackers@postgresql.org>; Wed, 1 Sep 1999 09:27:31 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA17542;
Wed, 1 Sep 1999 09:26:29 -0400 (EDT)
To: "G. Anthony Reina" <reina@nsi.edu>
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] OID 718 and Circle
In-reply-to: Your message of Tue, 31 Aug 1999 15:26:05 -0700
<37CC567D.C330E5DC@nsi.edu>
Date: Wed, 01 Sep 1999 09:26:28 -0400
Message-ID: <17540.936192388@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"G. Anthony Reina" <reina@nsi.edu> writes:

Okay, I finally convinced my partner that making a table named 'circle'
and dropping the type 'circle' to compensate is just a bad idea. We're
going to rename the table 'circles' and restore the 'circle' type. Could
you give me the psql command line to restore the circle type?

I think you gotta rebuild the database --- if you just do a new CREATE
TYPE for circle, it won't have the right OID...

You might be able to do a COPY WITH OIDS out of template1's pg_type,
edit it down to just the line for OID 718, and then COPY WITH OIDS
to your own database's pg_type. Not sure if that will work though.

regards, tom lane

From bouncefilter Wed Sep 1 09:31: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 JAA76250
for <pgsql-hackers@postgresql.org>; Wed, 1 Sep 1999 09:31:15 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA17574;
Wed, 1 Sep 1999 09:30:38 -0400 (EDT)
To: =?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com>
cc: hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] SELECT BUG
In-reply-to: Your message of Wed, 01 Sep 1999 12:44:58 +0200
<37CD03AA.BC08CD19@sferacarta.com>
Date: Wed, 01 Sep 1999 09:30:38 -0400
Message-ID: <17572.936192638@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

=?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com> writes:

--I have the following test data into these tables:

hygea=> select * from master1;
code
-----------
a
a1
a13
(3 rows)

hygea=> select * from detail1;
code
----------------
a13
a13
a1
(3 rows)

--if I try to join these two tables I have the following (nothing):

hygea=> select m.*, d.* from master1 m, detail1 d where m.code=d.code;
code|code
----+----
(0 rows)
--and now trying with TRIM function... it works!

hygea=> select m.*, d.* from master1 m, detail1 d where
trim(m.code)=trim(d.code
code |code
-----------+----------------
a13 |a13
a13 |a13
a1 |a1
(3 rows)

Looks to me like you have differing numbers of trailing spaces in the
entries in each table. If so, this is not a bug.

regards, tom lane

From bouncefilter Wed Sep 1 09: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 JAA78075
for <pgsql-hackers@postgresql.org>; Wed, 1 Sep 1999 09:42:23 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA17673;
Wed, 1 Sep 1999 09:41:14 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Vadim Mikheev" <vadim@krs.ru>, "Cyrus Rahman" <cr@photox.jcmax.com>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] File descriptor leakage?
In-reply-to: Your message of Wed, 1 Sep 1999 10:36:42 +0900
<000401bef41a$71da1fc0$2801007e@cadzone.tpf.co.jp>
Date: Wed, 01 Sep 1999 09:41:14 -0400
Message-ID: <17671.936193274@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Tom Lane wrote:

Interestingly, this isn't a big problem on platforms where there is
a relatively low limit on number of open files per process.

It's not a small problem on platforms such as cygwin, OS2 where we
couldn't unlink open files.

Ah, right, good ol' microsoft strikes again...

We have to close useless file descriptors ASAP there.
6.5.2-release should be stable as possible.
So I don't object to the riskless way as Vadim mentioned.

Well, Vadim's "riskless solution" does NOT solve the problem you mention
above, AFAICT. Reducing the number of kernel file descriptors won't
magically cause forgotten descriptors for a table you want to delete
to not be there --- it just shortens the interval where you'll have a
problem, by shortening the interval before the descriptors get recycled.
If you reduce the number of descriptors enough to make the problem
unlikely to occur, you'll be taking a big performance hit.

So we need a proper fix to ensure the relation code doesn't forget about
open descriptors.

I will try to take a look at Hiroshi's patch this evening, and will
commit it to both branches if I can't find anything wrong with it...

regards, tom lane

From bouncefilter Wed Sep 1 09:57:44 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA80420
for <pgsql-hackers@postgresql.org>; Wed, 1 Sep 1999 09:57:41 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA17695;
Wed, 1 Sep 1999 09:55:15 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Leon <leon@udmnet.ru>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Postgres' lexer
In-reply-to: Your message of Wed, 01 Sep 1999 02:19:33 +0000
<37CC8D35.F3B9880A@alumni.caltech.edu>
Date: Wed, 01 Sep 1999 09:55:14 -0400
Message-ID: <17693.936194114@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Consider this: SELECT 3+-2; What would you expect from that? I
personally would expect the result of 1. But it produces an error,
because '+-' is treated as some user-defined operator, which is
not true.

That is part of my concern here. The current behavior is what you say
you would expect! Your patches change that behavor!!

postgres=> select 3+-2;
?column?
--------
1
(1 row)

OTOH, with current sources:

regression=> select 3+- 2;
ERROR: Unable to identify an operator '+-' for types 'int4' and 'int4'
You will have to retype this query using an explicit cast

regression=> select f1+-f1 from int4_tbl;
ERROR: Unable to identify an operator '+-' for types 'int4' and 'int4'
You will have to retype this query using an explicit cast

To my mind, without spaces this construction *is* ambiguous, and frankly
I'd have expected the second interpretation ('+-' is a single operator
name). Almost every computer language in the world uses "greedy"
tokenization where the next token is the longest series of characters
that can validly be a token. I don't regard the above behavior as
predictable, natural, nor obvious. In fact, I'd say it's a bug that
"3+-2" and "3+-x" are not lexed in the same way.

However, aside from arguing about whether the current behavior is good
or bad, these examples seem to indicate that it doesn't take an infinite
amount of lookahead to reproduce the behavior. It looks to me like we
could preserve the current behavior by parsing a '-' as a separate token
if it *immediately* precedes a digit, and otherwise allowing it to be
folded into the preceding operator. That could presumably be done
without VLTC.

regards, tom lane

From bouncefilter Wed Sep 1 10:00:41 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA80988
for <hackers@postgresql.org>; Wed, 1 Sep 1999 10:00:29 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA17711;
Wed, 1 Sep 1999 09:58:33 -0400 (EDT)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] Changes for 6.5.2 ?
In-reply-to: Your message of Wed, 1 Sep 1999 10:09:19 +0400 (MSD)
<Pine.GSO.3.96.SK.990901100426.6807O-100000@ra>
Date: Wed, 01 Sep 1999 09:58:33 -0400
Message-ID: <17709.936194313@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Oleg Bartunov <oleg@sai.msu.su> writes:

Is there Changes list for 6.5.2 ? I checked REL6_5 tree and didn't
find it. It seems that Vadim's patch for nbtinsert.c (row-reuse)
still didn't applied.

I think it fell through the cracks --- IIRC, Vadim didn't have REL6_5
installed locally so he asked for someone else to apply that patch
to the stable branch. Bruce usually handles that kind of thing but
he's been gone for the last few days. I'll see about sticking it in
this evening, unless someone objects or beats me to it.

regards, tom lane

From bouncefilter Wed Sep 1 10:06:41 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA81905
for <pgsql-hackers@postgresql.org>; Wed, 1 Sep 1999 10:06:36 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA17740;
Wed, 1 Sep 1999 10:05:22 -0400 (EDT)
To: Peter Blazso <blazso@deltav.hu>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] need help for array appending & deleting
In-reply-to: Your message of Wed, 01 Sep 1999 13:48:53 +0200
<37CD12A5.D70FAC39@deltav.hu>
Date: Wed, 01 Sep 1999 10:05:22 -0400
Message-ID: <17738.936194722@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Blazso <blazso@deltav.hu> writes:

Unless it exists, I'd like to implement code for the array manipulations
above for Postgresql. and I need some help for it. I have already run
through the sources concerned but I need to be pointed to the right
direction on where to start and what kind of functions I should use. I'd
also like to have a bit more detailed info on array structure (or at
least where I can find a good doc. I've been looking for it in
'array.h', 'arrayutils.c' and 'arrayfuncs.c').

What's in the code is all there is :-(. Please consider improving the
documentation once you have studied the code enough to understand what's
going on.

I recall having looked at that stuff recently, and IIRC the general
structure of an array inside the backend is

Overall length word (required for any VARLENA type)
a couple words of fixed overhead
dimension info array (1 entry per dimension)
array elements, in sequence

I don't recall the sequence that's used (row or column major). Also,
I think the array elements are aligned on INTALIGN boundaries, which
is pretty bogus --- arrays of doubles would fail on a lot of hardware.
The code should either use MAXALIGN always, or better use the specific
alignment needed for the array element type (as indicated by the pg_type
data).

BTW, please be sure you are working with current sources and not REL6_5
branch. I've already fixed a bunch of parser/optimizer problems with
arrays; you shouldn't have to reinvent those changes.

regards, tom lane

From bouncefilter Wed Sep 1 10:14:41 1999
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA83130
for <hackers@postgresql.org>; Wed, 1 Sep 1999 10:14:26 -0400 (EDT)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id SAA12155;
Wed, 1 Sep 1999 18:13:16 +0400 (MSD)
Date: Wed, 1 Sep 1999 18:13:15 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] Changes for 6.5.2 ?
In-Reply-To: <17709.936194313@sss.pgh.pa.us>
Message-ID: <Pine.GSO.3.96.SK.990901180859.8507A-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 1 Sep 1999, Tom Lane wrote:

Date: Wed, 01 Sep 1999 09:58:33 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Oleg Bartunov <oleg@sai.msu.su>
Cc: hackers@postgresql.org
Subject: Re: [HACKERS] Changes for 6.5.2 ?

Oleg Bartunov <oleg@sai.msu.su> writes:

Is there Changes list for 6.5.2 ? I checked REL6_5 tree and didn't
find it. It seems that Vadim's patch for nbtinsert.c (row-reuse)
still didn't applied.

I think it fell through the cracks --- IIRC, Vadim didn't have REL6_5
installed locally so he asked for someone else to apply that patch
to the stable branch. Bruce usually handles that kind of thing but
he's been gone for the last few days. I'll see about sticking it in
this evening, unless someone objects or beats me to it.

OK, Understand, I just worried about not to forget this patch :-)
I've tested this patch under quite intensive updates and it seems
works fine - I have cron task to vacuum updated table. index file
truncated but still grow.

Oleg

regards, tom lane

From bouncefilter Wed Sep 1 10:35:42 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 KAA86482
for <pgsql-hackers@postgresql.org>; Wed, 1 Sep 1999 10:35:13 -0400 (EDT)
(envelope-from petermount@it.maidstone.gov.uk)
Received: from maidstonebc.demon.co.uk ([158.152.139.246]
helo=gatekeeper.maidstone.gov.uk)
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11MBTj-0002Yo-0K; Wed, 1 Sep 1999 14:35:11 +0000
Received: from exchange1.nt.maidstone.gov.uk (exchange1.nt.maidstone.gov.uk
[172.16.0.150])
by gatekeeper.maidstone.gov.uk (8.8.4/8.8.4) with ESMTP
id OAA23651; Wed, 1 Sep 1999 14:35:18 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <RXPXBYA6>; Wed, 1 Sep 1999 15:33:56 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E540@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>, Peter Blazso <blazso@deltav.hu>
Cc: pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] need help for array appending & deleting
Date: Wed, 1 Sep 1999 15:33:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain

Also (coming late into this conversation), Array support in the JDBC2
driver is on the cards for 6.6.

Peter

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

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 01 September 1999 15:05
To: Peter Blazso
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] need help for array appending & deleting

Peter Blazso <blazso@deltav.hu> writes:

Unless it exists, I'd like to implement code for the array

manipulations

above for Postgresql. and I need some help for it. I have already run
through the sources concerned but I need to be pointed to the right
direction on where to start and what kind of functions I should use.

I'd

also like to have a bit more detailed info on array structure (or at
least where I can find a good doc. I've been looking for it in
'array.h', 'arrayutils.c' and 'arrayfuncs.c').

What's in the code is all there is :-(. Please consider improving the
documentation once you have studied the code enough to understand what's
going on.

I recall having looked at that stuff recently, and IIRC the general
structure of an array inside the backend is

Overall length word (required for any VARLENA type)
a couple words of fixed overhead
dimension info array (1 entry per dimension)
array elements, in sequence

BTW, please be sure you are working with current sources and not REL6_5
branch. I've already fixed a bunch of parser/optimizer problems with
arrays; you shouldn't have to reinvent those changes.

regards, tom lane

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

From bouncefilter Wed Sep 1 10:43:41 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA87484
for <hackers@postgresql.org>; Wed, 1 Sep 1999 10:43:06 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id LAA42549;
Wed, 1 Sep 1999 11:41:57 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 1 Sep 1999 11:41:56 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgresql.org
Subject: Re: [HACKERS] Changes for 6.5.2 ?
In-Reply-To: <17709.936194313@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9909011141440.8660-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Erk...point me at it or send it to me and I can get at it now even...

On Wed, 1 Sep 1999, Tom Lane wrote:

Oleg Bartunov <oleg@sai.msu.su> writes:

Is there Changes list for 6.5.2 ? I checked REL6_5 tree and didn't
find it. It seems that Vadim's patch for nbtinsert.c (row-reuse)
still didn't applied.

I think it fell through the cracks --- IIRC, Vadim didn't have REL6_5
installed locally so he asked for someone else to apply that patch
to the stable branch. Bruce usually handles that kind of thing but
he's been gone for the last few days. I'll see about sticking it in
this evening, unless someone objects or beats me to it.

regards, tom lane

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

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

From bouncefilter Wed Sep 1 10:48:41 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA88476
for <hackers@postgresql.org>; Wed, 1 Sep 1999 10:48:40 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA18067;
Wed, 1 Sep 1999 10:46:58 -0400 (EDT)
To: The Hermit Hacker <scrappy@hub.org>
cc: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgresql.org
Subject: Re: [HACKERS] Changes for 6.5.2 ?
In-reply-to: Your message of Wed, 1 Sep 1999 11:41:56 -0300 (ADT)
<Pine.BSF.4.10.9909011141440.8660-100000@thelab.hub.org>
Date: Wed, 01 Sep 1999 10:46:58 -0400
Message-ID: <18065.936197218@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

The Hermit Hacker <scrappy@hub.org> writes:

Erk...point me at it or send it to me and I can get at it now even...

I don't have a copy of the patch handy either --- look at Vadim's
postings in pghackers for the last few weeks.

Actually it looks like you could just commit the current nbtinsert.c
into REL6_5, but I haven't tried it... not sure if the patch included
changes in any other file...

regards, tom lane

From bouncefilter Thu Sep 2 02:40:27 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 CAA26533
for <pgsql-hackers@postgresql.org>; Thu, 2 Sep 1999 02:40:17 -0400 (EDT)
(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 3.3) with ESMTP id IAA05331;
Thu, 2 Sep 1999 08:40:11 +0200 (MDT)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 11MEw2-0006R4-00; Wed, 1 Sep 1999 18:16:38 +0000
Message-ID: <37CD52C2.6A894BF4@sferacarta.com>
Date: Wed, 01 Sep 1999 18:22:27 +0200
From: =?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.5 [it] (Win95; I)
X-Accept-Language: it
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] SELECT BUG
References: <17572.936192638@sss.pgh.pa.us>
Content-Type: multipart/alternative;
boundary="------------BA238FC75232CCA0F7F7DB36"

--------------BA238FC75232CCA0F7F7DB36
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

You mean that "a1 " is not equal to "a1 " ?
but PostgreSQL has a different behavior in the following example:

hygea=> select code,len(code) as len_of_code,code1, len(code1) as
len_of_code1
from master1 where code = code1;

code |len_of_code|code1 |len_of_code1
----------+-----------+------------+------------
a1 | 10|a1 | 15
(1 row)

in this case the test code = code1 is true even if these fields have
different number of trailling spaces.

Therefore if the above test is OK there's a bug on:

select m.*, d.* from master1 m, detail1 d where m.code=d.code;

Jos��

Tom Lane ha scritto:

=?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com> writes:

--I have the following test data into these tables:

hygea=> select * from master1;
code
-----------
a
a1
a13
(3 rows)

hygea=> select * from detail1;
code
----------------
a13
a13
a1
(3 rows)

--if I try to join these two tables I have the following (nothing):

hygea=> select m.*, d.* from master1 m, detail1 d where m.code=d.code;
code|code
----+----
(0 rows)
--and now trying with TRIM function... it works!

hygea=> select m.*, d.* from master1 m, detail1 d where
trim(m.code)=trim(d.code
code |code
-----------+----------------
a13 |a13
a13 |a13
a1 |a1
(3 rows)

Looks to me like you have differing numbers of trailing spaces in the
entries in each table. If so, this is not a bug.

regards, tom lane

--------------BA238FC75232CCA0F7F7DB36
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>You mean that "a1 " is not equal to "a1     
" ?</tt>
 <tt>but PostgreSQL has a different behavior in the following example:</tt><tt></tt>
<tt>hygea=> select code,len(code) as len_of_code,code1, len(code1) as
len_of_code1</tt>
 <tt>from master1 where code = code1;</tt><tt></tt>
<tt>code      |len_of_code|code1      
|len_of_code1</tt>
 <tt>----------+-----------+------------+------------</tt>
 <tt>a1        |        
10|a1          |         
15</tt>
 <tt>(1 row)</tt>
 <tt></tt> <tt></tt>
<tt>in this case the test code = code1 is true even if these fields
have</tt>
 <tt>different number of trailling spaces.</tt><tt></tt>
<tt>Therefore if the above test is OK there's a bug on:</tt><tt></tt>
<tt>        select m.*, d.* from
master1 m, detail1 d where m.code=d.code;</tt>
 <tt></tt> <tt></tt>
<tt>José</tt>
 <tt></tt> <tt></tt>
<tt>Tom Lane ha scritto:</tt>
<blockquote TYPE=CITE><tt>=?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com>
writes:</tt>
 <tt>> --I have the following test data into these tables:</tt><tt></tt>
<tt>> hygea=> select * from master1;</tt>
 <tt>> code</tt>
 <tt>> -----------</tt>
 <tt>> a</tt>
 <tt>> a1</tt>
 <tt>> a13</tt>
 <tt>> (3 rows)</tt><tt></tt>
<tt>> hygea=> select * from detail1;</tt>
 <tt>> code</tt>
 <tt>> ----------------</tt>
 <tt>> a13</tt>
 <tt>> a13</tt>
 <tt>> a1</tt>
 <tt>> (3 rows)</tt><tt></tt>
<tt>> --if I try to join these two tables I have the following (nothing):</tt><tt></tt>
<tt>> hygea=> select m.*, d.* from master1 m, detail1 d where m.code=d.code;</tt>
 <tt>> code|code</tt>
 <tt>> ----+----</tt>
 <tt>> (0 rows)</tt>
 <tt>> --and now trying with TRIM function... it works!</tt><tt></tt>
<tt>> hygea=> select m.*, d.* from master1 m, detail1 d where</tt>
 <tt>> trim(m.code)=trim(d.code</tt>
 <tt>> code       |code</tt>
 <tt>> -----------+----------------</tt>
 <tt>> a13        |a13</tt>
 <tt>> a13        |a13</tt>
 <tt>> a1         |a1</tt>
 <tt>> (3 rows)</tt><tt></tt>
<tt>Looks to me like you have differing numbers of trailing spaces in
the</tt>
 <tt>entries in each table.  If so, this is not a bug.</tt><tt></tt>
<tt>                       
regards, tom lane</tt></blockquote>
</html>

--------------BA238FC75232CCA0F7F7DB36--

From bouncefilter Wed Sep 1 12:33:43 1999
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA03023
for <hackers@postgreSQL.org>; Wed, 1 Sep 1999 12:28:05 -0400 (EDT)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id UAA14936;
Wed, 1 Sep 1999 20:27:45 +0400 (MSD)
Date: Wed, 1 Sep 1999 20:27:45 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
Reply-To: Oleg Bartunov <oleg@sai.msu.su>
To: hackers@postgreSQL.org
cc: scrappy@hub.org
Subject: [PATCHES] patch for 6.5.X tree (fwd)
Message-ID: <Pine.GSO.3.96.SK.990901202525.8507B-200000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY=------------13748F452672F8D0944999E8
Content-ID: <Pine.GSO.3.96.SK.990901202525.8507C@ra>

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

--------------13748F452672F8D0944999E8
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: <Pine.GSO.3.96.SK.990901202525.8507D@ra>

This is a lost Vadim's patch for 6.5X tree

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

---------- Forwarded message ----------
Date: Mon, 09 Aug 1999 09:43:29 +0800
From: Vadim Mikheev <vadim@krs.ru>
To: patches@postgreSQL.org
Subject: [PATCHES] patch for 6.5.X tree

Sorry, I haven't 6.5.X tree on my host - could someone
apply patch below? TIA.
This is to re-use space on index pages freed by vacuum.

Vadim

--------------13748F452672F8D0944999E8
Content-Type: TEXT/PLAIN; CHARSET=us-ascii; NAME=DF
Content-ID: <Pine.GSO.3.96.SK.990901202525.8507E@ra>
Content-Description:

*** nbtinsert.c.orig	Fri Aug  6 22:04:40 1999
--- nbtinsert.c	Fri Aug  6 22:10:40 1999
***************
*** 392,408 ****
  		bool		is_root = lpageop->btpo_flags & BTP_ROOT;

  		/*
! 		 * If we have to split leaf page in the chain of duplicates by new
! 		 * duplicate then we try to look at our right sibling first.
  		 */
  		if ((lpageop->btpo_flags & BTP_CHAIN) &&
  			(lpageop->btpo_flags & BTP_LEAF) && keys_equal)
  		{
- 			bool		use_left = true;
- 
  			rbuf = _bt_getbuf(rel, lpageop->btpo_next, BT_WRITE);
  			rpage = BufferGetPage(rbuf);
  			rpageop = (BTPageOpaque) PageGetSpecialPointer(rpage);
  			if (!P_RIGHTMOST(rpageop))	/* non-rightmost page */
  			{					/* If we have the same hikey here then
  								 * it's yet another page in chain. */
--- 392,409 ----
  		bool		is_root = lpageop->btpo_flags & BTP_ROOT;

  		/*
! 		 * Instead of splitting leaf page in the chain of duplicates 
! 		 * by new duplicate, insert it into some right page.
  		 */
  		if ((lpageop->btpo_flags & BTP_CHAIN) &&
  			(lpageop->btpo_flags & BTP_LEAF) && keys_equal)
  		{
  			rbuf = _bt_getbuf(rel, lpageop->btpo_next, BT_WRITE);
  			rpage = BufferGetPage(rbuf);
  			rpageop = (BTPageOpaque) PageGetSpecialPointer(rpage);
+ 			/* 
+ 			 * some checks 
+ 			 */
  			if (!P_RIGHTMOST(rpageop))	/* non-rightmost page */
  			{					/* If we have the same hikey here then
  								 * it's yet another page in chain. */
***************
*** 418,449 ****
  									 BTGreaterStrategyNumber))
  					elog(FATAL, "btree: hikey is out of order");
  				else if (rpageop->btpo_flags & BTP_CHAIN)
- 
  					/*
  					 * If hikey > scankey then it's last page in chain and
  					 * BTP_CHAIN must be OFF
  					 */
  					elog(FATAL, "btree: lost last page in the chain of duplicates");
- 
- 				/* if there is room here then we use this page. */
- 				if (PageGetFreeSpace(rpage) > itemsz)
- 					use_left = false;
  			}
  			else
  /* rightmost page */
  			{
  				Assert(!(rpageop->btpo_flags & BTP_CHAIN));
- 				/* if there is room here then we use this page. */
- 				if (PageGetFreeSpace(rpage) > itemsz)
- 					use_left = false;
  			}
! 			if (!use_left)		/* insert on the right page */
! 			{
! 				_bt_relbuf(rel, buf, BT_WRITE);
! 				return (_bt_insertonpg(rel, rbuf, stack, keysz,
! 									   scankey, btitem, afteritem));
! 			}
! 			_bt_relbuf(rel, rbuf, BT_WRITE);
  		}

  		/*
--- 419,438 ----
  									 BTGreaterStrategyNumber))
  					elog(FATAL, "btree: hikey is out of order");
  				else if (rpageop->btpo_flags & BTP_CHAIN)
  					/*
  					 * If hikey > scankey then it's last page in chain and
  					 * BTP_CHAIN must be OFF
  					 */
  					elog(FATAL, "btree: lost last page in the chain of duplicates");
  			}
  			else
  /* rightmost page */
  			{
  				Assert(!(rpageop->btpo_flags & BTP_CHAIN));
  			}
! 			_bt_relbuf(rel, buf, BT_WRITE);
! 			return (_bt_insertonpg(rel, rbuf, stack, keysz,
! 								   scankey, btitem, afteritem));
  		}

--------------13748F452672F8D0944999E8--

From bouncefilter Wed Sep 1 12:48:43 1999
Received: from nsi.edu (amethea.nsi.edu [198.133.185.9])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA06218
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Sep 1999 12:48:35 -0400 (EDT)
(envelope-from reina@nsi.edu)
Received: from nsi.edu (o21.nsi.edu [204.128.156.216])
by nsi.edu (8.9.1/8.9.1) with ESMTP id JAA10738;
Wed, 1 Sep 1999 09:44:42 -0700 (PDT)
Sender: reina@nsi.edu
Message-ID: <37CD5A9C.691458B5@nsi.edu>
Date: Wed, 01 Sep 1999 09:55:56 -0700
From: "G. Anthony Reina" <reina@nsi.edu>
Organization: The Neurosciences Institute
X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] ERROR: Unable to locate type oid 718 in catalog
References: <17513.936192212@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Vacuum doesn't vacuum functions (AFAIK). It does, however, use the type
information about columns of tables that it's vacuuming --- at least it
does in vacuum analyze mode, not sure about plain vacuum. That's why
I'm suspicious that you have somewhere a forgotten table that has a
column of circle type...

Nope. I'm absolutely, positively, 100% sure that no table uses the type
'circle'. However, we're going to name the table 'circles' instead and
re-build the database by dumping, destroying, re-creating, and dumping back
in. IT just makes the most sense.

Thanks for the help.
-Tony

From bouncefilter Wed Sep 1 13:53:44 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA14273
for <hackers@postgreSQL.org>; Wed, 1 Sep 1999 13:53:03 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id OAA44094;
Wed, 1 Sep 1999 14:52:56 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 1 Sep 1999 14:52:55 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Oleg Bartunov <oleg@sai.msu.su>
cc: hackers@postgreSQL.org
Subject: Re: [PATCHES] patch for 6.5.X tree (fwd)
In-Reply-To: <Pine.GSO.3.96.SK.990901202525.8507B-200000@ra>
Message-ID: <Pine.BSF.4.10.9909011452420.8660-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Okay, I'm going by the fact that Vadim approved this, and am applying it
right now...

On Wed, 1 Sep 1999, Oleg Bartunov wrote:

This is a lost Vadim's patch for 6.5X tree

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

---------- Forwarded message ----------
Date: Mon, 09 Aug 1999 09:43:29 +0800
From: Vadim Mikheev <vadim@krs.ru>
To: patches@postgreSQL.org
Subject: [PATCHES] patch for 6.5.X tree

Sorry, I haven't 6.5.X tree on my host - could someone
apply patch below? TIA.
This is to re-use space on index pages freed by vacuum.

Vadim

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

From bouncefilter Wed Sep 1 15:23:45 1999
Received: from druid.net (root@druid.net [216.126.72.98])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA26139
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Sep 1999 15:23:06 -0400 (EDT)
(envelope-from darcy@druid.net)
Received: from localhost (1197 bytes) by druid.net
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <darcy>) (ident <darcy> using unix)
id <m11MFyL-0000bFC@druid.net>
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Sep 1999 15:23:05 -0400 (EDT)
(Smail-3.2.0.104 1998-Nov-20 #4 built 1999-Apr-13)
Message-Id: <m11MFyL-0000bFC@druid.net>
Subject: Funny mail
To: pgsql-hackers@postgreSQL.org
Date: Wed, 1 Sep 1999 15:23:05 -0400 (EDT)
From: "D'Arcy" "J.M." Cain <darcy@druid.net>
X-Mailer: ELM [version 2.4ME+ PL50 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Anyone looking into where these are coming from? They seem to be coming
from the news server on hub for some reason.

----- Forwarded message from Hub.Org News Admin -----

From bouncefilter Wed Sep 1 16:07:45 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA30873
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Sep 1999 16:07:02 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA45151;
Wed, 1 Sep 1999 17:06:51 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 1 Sep 1999 17:06:51 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: "D'Arcy J.M. Cain" <darcy@druid.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Funny mail
In-Reply-To: <m11MFyL-0000bFC@druid.net>
Message-ID: <Pine.BSF.4.10.9909011706160.8660-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I thought I had fixed it the other day too *sigh* Am diving back into
it...

On Wed, 1 Sep 1999, D'Arcy J.M. Cain wrote:

Anyone looking into where these are coming from? They seem to be coming
from the news server on hub for some reason.

----- Forwarded message from Hub.Org News Admin -----

From hub.org!owner-pgsql-hackers Wed Sep 1 13:27:26 1999

Date: Wed, 1 Sep 1999 07:29:55 -0400 (EDT)
From: "Hub.Org News Admin" <news@hub.org>
Message-Id: <199909011129.HAA61562@hub.org>
X-Authentication-Warning: hub.org: news set sender to <news> using -f
To: undisclosed-recipients:;
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk

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

----- End of forwarded message from Hub.Org News Admin -----
-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
************

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

From bouncefilter Wed Sep 1 16:13:45 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA31558
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Sep 1999 16:13:38 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA45201;
Wed, 1 Sep 1999 17:13:47 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 1 Sep 1999 17:13:47 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: "D'Arcy J.M. Cain" <darcy@druid.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Funny mail
In-Reply-To: <m11MFyL-0000bFC@druid.net>
Message-ID: <Pine.BSF.4.10.9909011712460.8660-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Found it..."bug" in the install for INN where it doesn't update anyting in
the site directory, even scripts that aren't "site specific"...news2mail
(the old one) wasn't calling 'sm' to get the article, so was jus tsending
out blanks...

This should be fixed...

On Wed, 1 Sep 1999, D'Arcy J.M. Cain wrote:

Anyone looking into where these are coming from? They seem to be coming
from the news server on hub for some reason.

----- Forwarded message from Hub.Org News Admin -----

From hub.org!owner-pgsql-hackers Wed Sep 1 13:27:26 1999

Date: Wed, 1 Sep 1999 07:29:55 -0400 (EDT)
From: "Hub.Org News Admin" <news@hub.org>
Message-Id: <199909011129.HAA61562@hub.org>
X-Authentication-Warning: hub.org: news set sender to <news> using -f
To: undisclosed-recipients:;
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk

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

----- End of forwarded message from Hub.Org News Admin -----
-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
************

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